企业官网建设流程全解析

1. 先搞清楚：wire 和 reg 到底在描述什么

很多刚接触 Verilog 的朋友，一开始就被 wire 和 reg 这两个关键字搞得晕头转向。网上的教程要么讲得太浅，只说"wire 是线，reg 是寄存器"，要么直接甩一堆语法规则让人硬背。结果就是：写代码的时候还是不知道该怎么选，编译报错了也不知道为什么。

先给一个最朴素的理解：wire 描述的是物理连线，reg 描述的是存储单元——但这句话只对了一半。因为在实际工程里，reg 综合出来不一定是寄存器，它也可能是纯组合逻辑。这一点如果不搞清楚，后面全是坑。

我个人的经验是，要把 wire 和 reg 的区别从四个维度去看：

• 语义层面：wire 代表结构性的连接关系，reg 代表过程性的赋值行为。
• 赋值方式：wire 用 assign 连续赋值，reg 在 always/initial 块里用过程赋值。
• 硬件映射：wire 映射为导线，reg 映射为寄存器或组合逻辑（取决于你怎么写）。
• 端口方向：input 只能是 wire，output 可以是 wire 也可以是 reg，inout 只能是 wire。

这篇内容不绕弯子，直接把这些讲透，并且结合我实际写代码踩过的坑，给你一套"什么时候用谁"的判断方法。不管你是在学数电基础、准备秋招，还是已经在写 RTL 做项目，这篇都能帮你少走弯路。

2. 从赋值方式看本质区别

2.1 连续赋值 assign：只有 wire 能接住

先看这段代码，很多教材第一个例子就是这么写的：

wire a, b, c; assign c = a & b;

assign 是连续赋值语句，它的含义是：右边表达式的结果，持续不断地驱动左边信号。只要 a 或 b 发生变化，c 就会立刻更新。这种"持续驱动"的语义，本质上描述的就是一根导线——一端接着与门的输出，另一端接到目标端口。

如果这时候你把 c 声明成 reg：

reg c; assign c = a & b; // 编译报错

综合工具会直接报错。因为 reg 表达的是"过程赋值"——必须在 always 或 initial 块内部被赋值。这是语法层面的硬性限制，没有任何例外。

我见过不少人在这里卡住，其实道理很简单：assign 语句就像一根实体的电线，电线两端的类型自然应该是线网类型（wire），而 reg 是一个变量容器，它的赋值应该发生在"某个过程"里，而不是"一直被驱动"。

2.2 过程赋值 always/initial：reg 的专属地盘

与 assign 对应的，是 always 和 initial 块。块内被赋值的信号，声明为 reg 类型。

reg q; always @(posedge clk or negedge rst_n) begin if (!rst_n) q <= 1'b0; else q <= d; end

这种写法描述的是一个 D 触发器：时钟上升沿到来时，q 采样 d 的值。q 必须声明为 reg，因为它的赋值是有条件的、由时钟事件触发的，而不是像 assign 那样无时无刻在被驱动。

这里有一个非常关键但初学者容易忽略的点：always 块里的 reg 不一定会被综合成寄存器。如果你在 always 块里写的是纯组合逻辑，reg 综合出来就是一堆门电路，而不是触发器。

reg y; always @(*) begin if (sel) y = a; else y = b; end

上面这个 always 块里用的是阻塞赋值=，没有时钟边沿触发，敏感列表是@(*)，综合出来的就是组合逻辑的多路选择器，y 在硬件上只是一根经过选择器后的连线。但因为写法上用了过程赋值，语法上就必须声明成 reg。这就是 Verilog 语法和硬件结构之间的一个"脱节"——很多初学者在这里精神分裂：明明综合出来是线，为什么要我写 reg？

记住这个结论：reg 是语法层面的变量类型，不是硬件层面的寄存器类型。凡是放在 always/initial 块里被赋值的信号，都要用 reg；凡是放在 assign 语句里被驱动的信号，都要用 wire。这是语法规则，先遵守，再理解硬件映射。

2.3 阻塞赋值与非阻塞赋值的连带影响

既然说到了 always 块，就不得不提阻塞赋值=和非阻塞赋值<=。因为很多人在纠结 wire/reg 的同时，也在纠结这两个符号。它们之间有强关联：

• 写组合逻辑的 always 块，用阻塞赋值=，reg 综合成组合逻辑。
• 写时序逻辑的 always 块，用非阻塞赋值<=，reg 综合成触发器。

如果乱用，仿真结果和实际电路行为会不一致。比如在时序逻辑里用阻塞赋值：

reg q1, q2; always @(posedge clk) begin q1 = d; // 阻塞赋值 q2 = q1; // 两个信号在同一时刻更新 end

这种写法在仿真时 q2 会直接拿到 d 的新值，看起来像是一拍完成。但实际综合出来的电路里，q1 和 q2 是两个串联的触发器，q2 应该滞后 q1 一拍。仿真和硬件行为不一致，这就是典型的"仿真通过，上板翻车"。

所以我的建议是：写时序逻辑一律用非阻塞<=，写组合逻辑一律用阻塞=。这不是教条，是无数前人用惨痛教训换来的经验。把它当成铁律来执行，能帮你避开一大类诡异 bug。

3. 驱动源与数据类型：一个容易被忽视的分水岭

3.1 端口方向决定类型选择

写模块的时候，端口声明是个高频场景。很多面试题也会在这里挖坑。

module test( input clk, input rst_n, input a, output b, output reg c );

input 端口对应的是外部信号驱动进来，内部只能读取它，不能对它赋值。所以 input 只能声明为 wire。你在模块内部如果要根据 a 的值做判断，直接拿a来用就行，不需要也不允许在 always 块里给它赋值。

output 端口比较灵活。如果输出是纯组合逻辑驱动的，比如直接把输入经过 assign 输出，那 output 端口默认就是 wire 类型：

module test( input a, input b, output c ); assign c = a & b; endmodule

但如果输出是在 always 块里赋值，那端口必须写成 output reg：

module test( input clk, input rst_n, input d, output reg q ); always @(posedge clk or negedge rst_n) begin if (!rst_n) q <= 1'b0; else q <= d; end endmodule

inout 端口就一个字：只能用 wire。因为双向端口必须支持多驱动源切换（高阻态时让外部驱动），这种特性只有 wire 能表达。你不可能用 reg 实现三态输出——不对，准确地说，三态门的控制逻辑里会有 reg，但真正的 inout 引脚本身必须是 wire。实际工程中，I2C 的 sda、DS18B20 的数据线，这些双向端口全部用 inout wire，然后配合三态缓冲器来做方向控制。

这里给一个端口选择速查表：

3.2 多驱动源问题：wire 的"线或"能力与 reg 的排他性

wire 本质上是一根导线，它天然允许多个驱动源。比如两个模块的输出同时驱动同一根 wire，在 Verilog 里可以通过线或（wire 的拉取关系）来合并。最典型的就是三态缓冲器阵列挂在同一根数据总线上——多个设备共享一根总线，谁使能谁驱动，不使能的输出高阻 z。

而 reg 不行。reg 代表的是一个变量，它只能有一个赋值来源。你不可能在多个 always 块里对同一个 reg 赋值——不是语法报错，就是综合出多驱动冲突。

reg q; always @(posedge clk) q <= a; always @(posedge clk) q <= b; // 非法：多驱动

这种写法在 Vivado 或 Quartus 里综合必然报错，因为一个 reg 在硬件上不可能同时被两个触发器驱动。

实际工程里，多驱动冲突最常见的坑出现在"写 RAM/寄存器的时候定义了多个写口"。比如一个双端口 RAM，你本意是端口 A 和端口 B 分别写不同的地址，结果一不小心在写代码时让两个 always 块同时驱动了同一个 reg 信号，综合工具直接给你爆一片红色错误。排查起来还挺费劲的，因为那一大片报错信息里，真正的根因往往藏得比较深。

我的排查经验是：一旦综合报告里出现 multiple drivers 之类的关键词，先回到代码里搜索所有对同一个 reg 的赋值语句，看是不是有多个 always 块在写。如果是，要么合并成一个 always 块（用 case 区分条件），要么拆分信号。这一步做完，问题瞬间消失。

3.3 什么时候用 wire：连线和组合逻辑的输出

只看语法规则可能还是不够直观，我用实际场景给你梳理一遍，什么情况下就无脑用 wire：

1. 模块间端口连接：例化子模块时，子模块的 input 端口在父模块里对应的连接信号，如果是信号源那边输出过来的，用 wire 就够了。

2. assign 连续赋值的信号：只要你的逻辑是assign c = a & b;这种风格，c 必须声明为 wire。

3. 组合逻辑的中间信号：比如一个复杂组合逻辑的中间结果，你会连着写好几条 assign，中间那些信号都是 wire。

4. 三态缓冲器的输出：inout 引脚内部连接的三态门输出，必须是 wire。

5. 多个模块共享的总线：数据总线、地址总线这类多驱动线，必须用 wire 配合三态门实现。

这里有个补充经验：模块例化时，如果子模块的 output 端口没有在父模块里声明成 wire，有些人会图省事不写声明，直接用。但更严谨的写法是主动声明，因为这样别人看代码的时候一眼就知道哪些是连线、哪些是触发器输出，代码可读性完全不一样。对于团队协作项目，这种细节很重要。

3.4 什么时候用 reg：时序逻辑和过程赋值的场景

再看 reg 的使用场景，同样是无脑套用的清单：

1. always 块里被赋值的所有信号：不管这个 always 块描述的是时序逻辑还是组合逻辑，信号都得是 reg。

2. 寄存器和触发器输出：计数器、移位寄存器、状态机的状态变量、FIFO 的读写指针——这些在 always 块里被时钟边沿更新的信号，全部用 reg。

3. 组合逻辑但用过程赋值描述的场景：比如组合 always 块里的中间变量，声明为 reg 是语法需要。

4. initial 块里赋值的信号：主要用在 testbench 仿真里，比如激励信号的定义，都声明为 reg。

5. IP 核或复杂模块的输出端口：只要输出是在模块内部通过 always 块产生的，端口就得是 output reg。

这里我要强调一个高频踩坑点：变量定义位置和宽度。在声明 reg 的时候，一定要把位宽写清楚。比如reg [7:0] data_r;和reg data_r;是完全不同的东西——前者是 8 位寄存器，后者是 1 位。很多时候模块功能不对，从头查下来发现是声明时位宽没写对，低级但致命。

还有一个更隐蔽的坑：reg [7:0] data_r;在 always 块里被赋值为data_r <= data_in;，如果 data_in 只有 4 位，那高 4 位会被自动补 0 还是保持原来的值？答案是取决于上下文。如果是非阻塞赋值，高 4 位会在赋值时被 0 填充（因为右侧表达式不足 8 位时会补零）。如果你本意是高 4 位保持不变，那就得写成data_r[3:0] <= data_in;。这种细节在实际工程里特别容易翻车。

4. 必须掌握的一个高级主题：wire 和 reg 跟仿真模型的关系

4.1 仿真中的 wire 和 reg：初始状态差异

如果你用过 Icarus Verilog 或者 Modelsim 做仿真，会发现 wire 和 reg 在仿真器里的初始值行为不一样。

wire 在仿真开始时的默认值是 z（高阻），因为一根没有被驱动的线，自然就是悬浮状态。而 reg 的默认值是 x（未知），因为它是一个没有被赋值的变量。

这个差异在写 testbench 的时候有实际影响。比如你写一个简单的与门仿真：

wire c; assign c = a & b; initial begin a = 0; b = 1; end

仿真刚开始那一瞬间，a 和 b 需要从 x 变成 0/1，c 才能从 x 变成 0。如果 initial 块还没来得及执行，c 就是 x。这个"初始 x"在波形图里看起来像一个 bug，但其实是正常现象。

对于 reg 类型，如果你在 initial 块里给 rst_n 赋值之前，它保持 x 状态，这就有可能让时序逻辑进入不确定状态。所以工程上有一个规范：测试激励里的控制信号，第一条 initial 语句就要把初值赋好，尤其是复位信号，绝对不能让它在仿真开始阶段悬空为 x。

reg clk; reg rst_n; initial begin clk = 0; rst_n = 0; #100 rst_n = 1; end

这种写法就是标准的 testbench 开头模板。如果把 rst_n 赋值的顺序搞反了，或者漏了初值，仿真波形一出来就是一堆红叉叉（x），排查起来让人头大。

4.2 为什么集成逻辑分析仪抓信号时只有 wire 能看到

实际调试 FPGA 的时候，大家都会用 Vivado 的 ILA 或者 Quartus 的 SignalTap 来抓内部信号。你会发现一个现象：ILA 的探针列表里能看到 wire 信号，但很多 reg 信号看不到——或者要看的话得做额外设置。

原因是这样的：综合工具在优化电路时，会把一些纯组合逻辑的 wire 信号吸收进 LUT 内部，或者把一些 reg 信号重命名/合并到其他寄存器里。特别是那些只在一个 always 块内部出现、从来没有连接到输出端口的 reg，很可能在综合后就被优化没了。

我记得有一次调一个状态机，状态变量是 reg，但在 ILA 里死活看不到它的值。后来发现是我定义状态编码时用了localparam加reg [1:0] state;，综合工具把 state 信号优化到了 LUT 的寄存器里，没有暴露到可观测的节点上。

解决办法有几种：一是用(* mark_debug = "true" *)属性强制保留信号；二是在信号声明时加上(* keep = "true" *)，防止被综合工具优化掉。这两个属性在 Vivado 里都很常用，Quartus 里对应的写法也类似。如果抓不到你要看的 reg，先考虑是不是信号被优化了。

这个经验其实反过来印证了一个道理：你在 RTL 代码里写的 reg，到了真实硬件上不一定还叫这个名字，甚至不一定存在。理解这一点，对 wire 和 reg 的本质理解会更深入一层。

5. 工程中最常见的 wire/reg 错误与排查方法

5.1 典型错误一：在 always 块里给 wire 赋值

这个错误新手必犯，错误提示也五花八门。最常见的报错是：

Error (10028): Can't resolve multiple constant drivers for net "xxx"

或者 Quartus 报：

error: object "xxx" on left-hand side of assignment must have a variable data type

原因很简单：always 块里赋值左侧必须是 reg 类型，如果是 wire，语法分析直接就拒绝。

解决办法也简单：把 always 块里赋值的信号声明改成 reg。但要注意，如果这个信号同时又被 assign 驱动了，那就不能简单改类型，要先想清楚——这个信号到底是组合逻辑还是时序逻辑的输出？如果是组合逻辑，可以考虑把它挪到 assign 里；如果是时序逻辑，那就不应该有 assign 驱动它。

我自己在带新人的时候，最常说的话就是："你先告诉我，这个信号是模块输出的寄存器，还是模块内部的连线？如果是寄存器，就在 always 块里赋值，声明成 reg；如果是连线，就放到 assign 里，声明成 wire。想清楚再动手。"

5.2 典型错误二：端口类型不匹配

模块例化时，端口类型不匹配的问题非常隐蔽。尤其是当子模块的 output 端口是 reg，父模块里连接这个端口的信号却声明成了 reg——这不是不能连，而是要看父模块里这个信号是不是被多个源驱动。

更常见的是这种情况：子模块的 output 是 wire 类型，父模块里把它连到了一个 reg 信号上。在某些编译器里，这可能会报 warning，但在另一些里可能直接报 error。不同工具对端口连接类型的容忍度不一样，这就很让人抓狂。

我的做法是：例化模块之前，先把子模块端口类型看清楚，然后在父模块里对应的连接信号用 wire 声明。因为端口连接本质上就是"拿一根线把两个模块的引脚焊在一起"，线就是 wire。如果子模块的输出在父模块里需要作为触发器使用，那就应该先在父模块里加一个 reg 信号，用 always 块把 wire 采进来，而不是直接把 reg 信号连到子模块输出上。

// 正确示范 wire child_out; reg child_out_r; child u_child( .out(child_out) ); always @(posedge clk or negedge rst_n) begin if (!rst_n) child_out_r <= 1'b0; else child_out_r <= child_out; end

这种模式的本质是：一个信号如果既需要作为导线被例化模块驱动，又需要被寄存器采样，那就拆成两个信号——一个 wire 一个 reg——再用 always 块把它们关联起来。这是 RTL 设计里最常见的信号处理模式，一定要练熟。

5.3 典型错误三：reg 被综合成锁存器

还有一种错误不在编译阶段报错，而是在综合后的资源报告里才能看到：你没打算生成锁存器，但综合工具给你综合出来了。

这种情况通常发生在组合 always 块的 if/else 分支不完整的时候：

reg y; always @(*) begin if (sel) y = a; // 缺少 else 分支 end

当 sel 为 0 时，y 保持原来的值，这在硬件上需要一个锁存器来保持。但如果你本意是一个二选一多路器，那这就是 bug——因为多路器在所有条件下都应该有确定的输出。

排查锁存器的方法有两个：一是看综合报告里有没有 latch 相关提示；二是写代码时自觉检查每个组合 always 块是否有完整的 if/else 或 case 默认分支。我在写代码的时候有个习惯：组合逻辑的 always 块，开头先把输出赋一个默认值，再写条件分支。比如：

reg y; always @(*) begin y = b; // 默认值 if (sel) y = a; end

这样写，不管 sel 是什么值，y 都有确定的输出，综合工具就不会生成锁存器。这个习惯帮我避免了很多次锁存器翻车。

5.4 一段排查实录：FIFO 读指针"莫名跳变"

近期在调一个异步 FIFO 的读侧逻辑时，遇到一个现象：读指针在仿真波形里偶尔会跳变两个值——不是每次读都会跳，而是很随机地偶尔跳一次。代码里读指针的更新逻辑是标准的：

reg [4:0] rd_ptr; wire [4:0] rd_ptr_next = rd_ptr + 1'b1; always @(posedge rd_clk or negedge rst_n) begin if (!rst_n) rd_ptr <= 5'd0; else if (rd_en) rd_ptr <= rd_ptr_next; end

rd_ptr 是 reg，rd_ptr_next 是 wire。表面看问题不大，但再往下查就发现问题出在连接关系上：rd_en 信号是从写侧跨时钟域同步过来的指针比较结果，在某一个时钟周期出现了亚稳态，导致 rd_en 在一个周期里被采到两次有效脉冲。这种情况下 rd_ptr 自然就跳了两个值。

这个问题的根因不是 wire/reg 选型错误，但排查过程让我又一次意识到：把 wire 和 reg 的类型理解透，是解决这类信号连接问题的前提。当你看到 rd_ptr_next 是一个 wire、rd_ptr 是一个 reg，你就能立刻理解——rd_ptr_next 只是组合逻辑的中间结果，真正的状态在 rd_ptr 里。如果 rd_ptr 跳变，要么是组合逻辑有问题，要么是驱动它的使能信号有问题。分清了 data type 的职责，定位问题的思路就清晰了。

5.5 常见错误速查表

下面这个表是我这些年总结出来的高频错误，每次 review 代码都会对照检查一遍：

这些坑我在不同项目里都踩过，有些还踩过不止一次。尤其是多驱动源和锁存器这两个，几乎每个初学者都会碰上一次。

6. 实操示例：一个组合逻辑状态模块的完整选型过程

前面讲了这么多原则，可能还是有人觉得抽象。这里用一个具体的例子，从零开始走一遍选型过程。假设要写一个"出租车计价器"的跳表模块，功能是：根据里程信号，每 100 米跳一次表，跳过之后把金额累加。

分析一下需要哪些信号：

• 时钟和复位：clk、rst_n，都是 input wire。
• 里程脉冲：mile_pulse，input wire，来一个脉冲代表 100 米。
• 当前金额：fare，output reg，因为需要累加，必定是时序逻辑。
• 跳表信号：fare_inc，内部 wire，表示"金额要加 1"，由 mile_pulse 经过边沿检测产生。

module taxi_fare( input clk, input rst_n, input mile_pulse, output reg [15:0] fare ); wire pulse_edge; reg pulse_dly; // 边沿检测：把 mile_pulse 打一拍，再通过组合逻辑检测上升沿 always @(posedge clk or negedge rst_n) begin if (!rst_n) pulse_dly <= 1'b0; else pulse_dly <= mile_pulse; end assign pulse_edge = mile_pulse & ~pulse_dly; // 金额累加：每检测到一次脉冲，加 1 always @(posedge clk or negedge rst_n) begin if (!rst_n) fare <= 16'd0; else if (pulse_edge) fare <= fare + 1'b1; end endmodule

来复盘一下每个信号的类型选择理由：

• clk、rst_n、mile_pulse 是模块的输入端口，只能 wire。
• pulse_dly 是打拍寄存器，在 always 块里赋值，必须 reg。
• pulse_edge 是组合逻辑信号，由 assign 驱动，必须 wire。
• fare 是输出端口加累加寄存器，在 always 块里赋值，必须 output reg。

如果当初把 pulse_edge 错写成 reg，那就要么把脉冲检测改写成一个组合 always 块，要么在那里报错。如果错写成 wire anyway 那没问题，但把 fare 写成 wire，那整个累加逻辑就废了——wire 不能在 always 块里被赋值。

这个例子的关键就是：先想清楚信号是"被时钟驱动的寄存器"还是"由组合逻辑算出来的连线"，再决定它的类型。想清楚了，选型就是自然而然的事情。

7. 实际工程中的几个实用建议

7.1 命名规范配合类型声明

我写代码的时候有一个习惯：信号命名里直接体现类型语义。比如：

• _n结尾的是低有效信号（rst_n）
• _r结尾的是打拍后的寄存器版本（pulse_dly_r）
• _w结尾的是组合逻辑信号（data_w）
• _d结尾的是延迟一拍的数据（data_d）

这样做的好处是，别人看代码时从名字就能猜出大概类型，减少沟通成本。虽然 Verilog 没有强制要求，但团队协作时这种隐式规范非常值钱。

7.2 声明位置和代码风格

我个人的习惯是：端口信号在模块头部集中声明，内部信号在有需要的地方就近声明。这样既保持了代码整洁，又不至于把信号列表拖得太长。

module example( input clk, input rst_n, input [7:0] data_in, output reg [7:0] data_out ); // 内部信号 wire [7:0] data_in_d; reg [7:0] data_in_r;

这种风格在做的项目里被团队沿用，代码 review 速度快了很多，因为信号的类型一目了然。

7.3 初学阶段怎么练习

如果你是刚入门，我建议按这个顺序练习：

1. 先把 assign 语句练熟，所有组合逻辑都用 assign + wire 实现。
2. 再写简单的 always 块时序逻辑（计数器、分频器），用 reg。
3. 然后写带组合 always 块的代码，感受 reg 被综合成组合逻辑的情况。
4. 最后把 wire/reg 和阻塞/非阻塞赋值放到一起综合考虑。

这个顺序的好处是，每一步的规则边界都很清晰：第一步只接触 wire，第二步只接触 reg，第三步才开始遇到"reg 但其实是组合逻辑"的概念，第四步就是把所有规则融会贯通。我用这个顺序带过不少人，进度比直接看语法书快很多。

8. 关于 wire 和 reg 再深挖一层

8.1 wire 和 net 类型家族

wire 只是 Verilog 里线网类型（net type）的一种。net 类型还包括 wand、wor、tri、supply0、supply1 等。其中 tri 在实际工程里和三态逻辑强相关，wand/wor 用于开漏/开集电极场景，但日常 RTL 设计里最常用的还是 wire。

如果你在代码里看到别人用了tri而不是wire，不用惊讶，两者在很多工具里行为几乎一致。tri 更强调"三态驱动"的语义，但综合结果和 wire 没有本质区别。这里不建议初学者一开始就纠结这些变体，先把 wire 用熟，后面遇到了再查就行。

8.2 reg 和 integer、real 的关系

Verilog 里 reg 并不是唯一的变量类型。integer、real、time 也是变量类型，它们也可以在 always 块里被赋值。但实际综合时，integer 通常会被当作寄存器组来处理，real 只用于仿真，不可综合。

这里给初学者一个建议：RTL 设计里能用 reg 就用 reg，尽量不要混用 integer 和 real。虽然语法上允许，但综合工具对这些类型的支持程度不一，用了之后可能引入不必要的麻烦。面试时如果你能说出 integer 在综合时会占用多少资源，面试官会高看你一眼——一个 32 位的 integer，综合出来就是 32 个寄存器。

8.3 SystemVerilog 里的 logic 类型

如果你已经进阶到 SystemVerilog，会发现多了一个logic类型。logic 可以同时兼容 wire 和 reg 的功能——既能被 assign 驱动，也能在 always 块里赋值。看起来很方便，对吧？但其实它也有坑：logic 不允许有多个驱动源。它本质上是一个"变量类型"，而不是"线网类型"，所以多驱动场景下（比如三态总线）仍然必须用 wire。

所以即使你用 SystemVerilog，明确知道 wire 和 reg 的区别依然是基本功。logic 只是一个类型推断的便利工具，不能替代对底层硬件语义的理解。面试官问 wire 和 reg 的区别，可不是为了确认你背过语法书，而是要看你有没有建立"代码描述硬件"的心智模型。

9. 最后聊几句心得体会

关于 wire 和 reg，我见过太多人死记硬背规则，结果一写代码还是错。我想说的其实就一句话：选 wire 还是 reg，本质上是在回答一个问题——你写的这段代码，描述的是"线"还是"变量"？线就是物理连接，只有被驱动的结果，没有记忆能力；变量是过程赋值的容器，它存在于某个 always 块的作用域里。

顺着这个思路，你再看那些规则就都能推出来：

• 连续 assign 驱动的是线 → wire
• always 块过程赋值的是变量 → reg
• 端口 input 只能是线 → wire
• output 取决于内部怎么驱动它
• inout 必须是线 → wire

我刚开始写 RTL 的时候也犯过把 reg 当寄存器的经典错误，后来写了一个计数器模块，发现 reg 也能综合成组合逻辑，才真正理解了两者的语法和硬件映射关系。从那以后，我写代码的顺序就变成了：先想清楚信号在硬件里是什么，再动手敲代码。这一步想通了，wire 和 reg 就不再是问题。

最后再给一个小技巧。如果你在写代码的时候不确定某个信号该用 wire 还是 reg，可以这样问自己：这个信号有没有可能被多个 always 块同时赋值？如果有，它必须被拆分成 wire 来综合——因为在 Verilog 的语法框架里，只有 wire 能和多个驱动源共存。如果它只在一个 always 块或者一个 assign 语句里出现，那按赋值方式选类型就行。这个判断法在大多数场景下都能帮你快速做出正确决定。

Verilog 的学习就是这样，很多概念单看语法是死的，放到实际项目里就活起来了。wire 和 reg 只是起点，后面还有状态机、FIFO 跨时钟域、时序收敛这些大山等着翻。但基础打牢了，后面每一步都会顺畅很多。