写 Verilog 写到能独立跑通一个 UART 收发、I2C 读写 EEPROM 或者 FIFO 验证的时候基本都会撞上同一个困惑同一段逻辑在三个地方重复出现了要不要抽出来抽出来该用 task 还是 function这两者在语法上长得像孪生兄弟用起来却一个能延时、一个不能返回值一个有多个、一个只有一个很多新手就是在复制粘贴能跑、一封装就报错的循环里来回打转。我把 verilog 中 task 和 function 的用法、写法、边界条件和踩坑点一次性讲透目标是让你看完之后能直接判断这段代码该写成 task 还是 function而不是靠一次次编译报错去试。这篇内容适合三类人看正在学 verilog 语法、对 task/function 只停留在背概念阶段的入门者写过一些小工程、但代码里全是复制粘贴、想重构的初中级工程师以及写 testbench 时被 static 变量坑过、仿真结果对不上波形的人。全文的代码都在 Icarus Verilog 和主流商业仿真器上验证过写法能综合的部分我也标注了哪些工具支持、哪些只能仿真用。判据、参数、边界值我都会给出来不玩你自己体会那一套。1. 先搞懂 task 和 function 的定位差异1.1 从一个真实的复制粘贴场景说起假设你在写一个 UART 收发模块的验证环境发送一个字节的时序是拉低 tx 一个波特周期当起始位然后从 bit0 到 bit7 依次把数据位打到 tx 上每个位保持一个波特周期最后拉高一个周期作为停止位。这段时序你在三个地方要用单字节发送、多字节字符串发送、以及带校验的发送。最省事的做法就是把这段代码复制三遍改改变量名。问题马上就来了。第一改一处漏一处某天你把停止位从 1 个周期改成 2 个周期只改了两个地方仿真波形上就出现了偶发的帧错误。第二代码体积膨胀一个 testbench 文件从 300 行长到 2000 行。第三调试的时候你要同时盯三份几乎一样的代码定位问题的时间成倍增加。把这段逻辑抽成一个可复用的单元就是 task 和 function 存在的意义。它们本质上都是过程封装——给一段代码起个名字需要的时候按名字调用。区别在于封装的能力边界function 是纯计算的封装task 是带时序行为的封装。理解了这句话后面所有的语法细节都是这句话的推论。1.2 二者的本质区别在哪先说结论function 在零仿真时间内完成一次计算并返回一个值task 可以消耗仿真时间、可以产生多个输出、可以没有输出。这句话里藏着三个关键约束我们逐个拆。第一个约束是零仿真时间。function 被调用的那一刻所有语句在同一仿真时刻内执行完毕仿真时间不推进。这直接导致了 function 内部禁止出现#10、(posedge clk)、wait(...)这类时间控制语句——因为如果允许仿真时间就会在函数执行中间推进而函数被调用的位置比如连续赋值语句里根本无法承载时间推进这个语义。你可以把 function 理解成一个纯组合逻辑黑盒输入进去输出立刻出来。第二个约束是返回一个值。function 有且只有一个返回值通过函数名或者return语句返回。这个返回值可以当作表达式的一部分写在assign连续赋值里、写在always块的右侧、写在模块实例的端口连接上。task 不一样task 没有返回值这个概念它的结果通过output和inout参数带出来可以有零个、一个、也可以有十几个。第三个约束是可以消耗仿真时间。这是 task 最大的价值。你在 task 里可以写#(BIT_PERIOD)可以写(posedge clk)可以写wait(ready)甚至可以调用$display打印中间状态。task 只能在initial、always、final这类过程块里调用——因为它可能消耗时间而只有过程块才有时间推进的概念。1.3 一张表看清关键差异光看文字描述容易记混我把最关键的差异整理成对照表这张表建议直接收藏。它覆盖了面试和实际写代码时 90% 的决策场景。对比维度functiontask返回值数量有且仅有 1 个0 个或多个靠 output/inout 传出仿真时间消耗必须为 0不能有#、、wait可以消耗任意仿真时间可包含的赋值只能用阻塞赋值阻塞、非阻塞赋值都可以调用位置表达式可用的任何位置只能在 initial/always/final 等过程块中是否可综合一般可综合作为组合逻辑绝大多数综合器不支持参数方向至少 1 个 input标准 Verilog 不支持 outputinput/output/inout 都支持能否调用对方不能调用 task可以调用 function 和 task递归能力默认 static 不可递归加 automatic 可以默认 static 不可重入加 automatic 可以典型用途位宽计算、CRC、编码、位反转总线时序、数据收发、握手流程这张表里有两个地方新手容易看漏。第一个是参数方向那一行标准 VerilogIEEE 1364规定 function 只能有 input 参数不能有 outputSystemVerilog 才放开这个限制。第二个是能否调用对方那一行是单向的——task 可以调用 functionfunction 不能调用 task。原因还是那条函数必须零时间完成而 task 可能消耗时间调用一个可能消耗时间的单元函数自己就违反约定了。注意SystemVerilog 对 function 做了大幅扩展允许void返回类型、允许 output 参数、允许ref参数。但如果你写的代码要在老的综合工具或老仿真器上跑建议还是按标准 Verilog 的规则来兼容性最稳。2. function 的完整用法与实操要点2.1 语法骨架与 ANSI 风格写法function 的定义骨架是这样的关键字function开头跟返回值的位宽声明再跟函数名然后是小括号里的参数列表推荐 ANSI 风格也就是参数带方向和位宽最后是endfunction收尾。函数名本身既是函数的名字也是返回值的载体——在函数体里给函数名赋值就相当于设置返回值。// 老式 Verilog-1995 写法参数在函数体内声明 function [7:0] add8; input [7:0] a; input [7:0] b; begin add8 a b; end endfunction // Verilog-2001 ANSI 风格参数在端口列表声明推荐 function automatic [7:0] add8_ansi(input [7:0] a, input [7:0] b); begin add8_ansi a b; end endfunction两种写法仿真结果完全一致但 ANSI 风格有三个实际好处。第一参数方向、位宽一眼可见不用把视线移到函数体里。第二代码行数少一个十二参数的函数能省掉十几行。第三不容易写错——我见过不止一次有人把老式写法的input忘了写默认变成 input 但位宽变成 1 bit然后计算结果莫名其妙被截断查半天。关于automatic关键字我在 2.4 节和第三章会详细讲。这里先给个经验仿真用的代码一律加automatic综合用的代码加了也不影响结果综合工具会忽略它因为硬件本身就是并行独立的。这个习惯能帮你避免后面 90% 的诡异 bug。函数体内部的begin...end块在很多工具里可以省略但我建议保留。原因很实际当你需要在函数里声明局部变量比如循环变量integer i时声明语句必须放在begin之后、其他语句之前。保留begin...end能让代码结构统一也方便以后加变量。2.2 返回值位宽与参数扩展的坑返回值位宽是 function 里最容易出错的地方我把它单独拎出来讲。还记得开头那个 promise 吗——参数计算过程会给出来这里就是。假设你要写一个计算每比特周期时钟数的函数输入是时钟频率 50MHz、波特率 115200。按最简单的写法function integer baud_div; input integer clk_hz; input integer baud; begin baud_div clk_hz / baud; // 50000000 / 115200 434 end endfunction这里返回值声明为integer是 32 位有符号类型能表示的范围足够。但如果你声明成[7:0]434 就会被截断成 178然后你会在波形上看到波特率完全对不上——这是真实发生过的案例。位宽的选择逻辑很简单先算一下结果的最大可能值再向上取整到 2 的幂。50000000/115200 约等于 434需要 9 位所以至少声明成[15:0]才稳妥。比返回值截断更隐蔽的是参数位宽扩展。看这段function [15:0] mul_a; input [7:0] x; begin mul_a x * 8d3; end endfunction看起来没问题x * 3最大 255*376516 位够装。但如果 x 声明成[15:0]而乘数写成8d3Verilog 会把整个表达式按两个操作数中较宽的那个16 位来计算结果没问题。真正的坑在有符号数上function [15:0] mul_b; input signed [7:0] x; // -128 ~ 127 begin mul_b x * 8sd3; end endfunction如果 x -100你期望结果是 -300。但如果位宽处理不当比如把 signed 声明漏掉或者中间插了一个无符号的常量-100 会被当成 156 来处理结果变成 468。这类 bug 在仿真里表现为大部分数据对负数全错排查起来非常费劲。我的建议是做算术运算的函数参数和返回值全部显式声明 signed 或全部 unsigned中间不要混用。还有一个常见错误是函数名被赋值多次。标准规定函数名可以多次赋值以最后一次为准。所以下面这段代码的结果是b不是afunction [7:0] ambiguous; input [7:0] a; input [7:0] b; begin ambiguous a; ambiguous b; // 覆盖前一次赋值最终返回 b end endfunction我建议养成一个习惯函数体里只在最后一行给函数名赋值一次中间计算全部用局部变量最后统一输出。这样逻辑最清晰也不会踩多次赋值的坑。2.3 三个能直接抄的函数CRC、优先级编码、位反转理论讲够了上干货。这三个函数我在多个实际项目里反复用过可以直接抄进你的代码。第一个是 CRC-8 单字节计算函数UART 通信、EEPROM 数据校验都用得上多项式取 0x07function automatic [7:0] crc8_update; input [7:0] crc_in; // 上一轮的 CRC 值 input [7:0] data; // 本次要计算的字节 integer i; reg [7:0] c; begin c crc_in ^ data; for (i 0; i 8; i i 1) begin if (c[7]) c (c 1) ^ 8h07; else c c 1; end crc8_update c; // 只在这里赋一次值 end endfunction这段代码里我特意用了局部变量c而不是直接操作crc8_update原因就是上面说的只赋值一次原则。调用方式也很直接crc crc8_update(crc, rx_byte);配合一个 for 循环就能算出整包的 CRC。第二个是 16 位输入的优先级编码器返回最高优先级位的位置仲裁逻辑里经常用function automatic [3:0] prio_encode; input [15:0] req; integer i; begin prio_encode 4h0; for (i 15; i 0; i i - 1) begin if (req[i]) prio_encode i[3:0]; // 从高位往低位扫最后一次赋值即最高位 end end endfunction这个函数的实现思路值得说一下从最高位往最低位遍历每遇到一个 1 就更新结果遍历结束时保留的就是最高位的序号。因为循环是从高往低走最后的赋值天然就是优先级最高的那个。如果反过来从低往高扫就得在第一次命中时 break标准 Verilog 没有 break得用 disable 或者标志位代码会复杂不少。第三个是位反转函数NAND Flash 读出的数据、某些 SPI 设备的 MSB/LSB 顺序转换都会用到function automatic [7:0] bit_reverse; input [7:0] din; integer i; reg [7:0] tmp; begin for (i 0; i 8; i i 1) tmp[7 - i] din[i]; bit_reverse tmp; end endfunction这里用临时变量tmp的理由和 CRC 那个一样。另外注意tmp[7-i]这个索引是变量Verilog 支持变量索引但索引值必须在合法范围内0~7否则会得到 x。如果你要写参数化的位反转可以把位宽做成参数function automatic [WIDTH-1:0] bit_reverse_n; input [WIDTH-1:0] din; integer i; reg [WIDTH-1:0] tmp; begin for (i 0; i WIDTH; i i 1) tmp[WIDTH-1-i] din[i]; bit_reverse_n tmp; end endfunctionWIDTH是定义在模块里的parameter函数体内部可以直接引用。这个技巧在写参数化 IP 的时候特别有用。2.4 function 里绝对不能出现的语句这一节是硬性红线违反了直接编译报错。我列一份清单按报错概率从高到低排时间控制语句#10、(posedge clk)、(negedge rst_n)、wait(cond)、fork...join。这是最常踩的尤其在把 testbench 里的代码顺手搬进函数的时候。非阻塞赋值标准明确规定 function 中不能使用非阻塞赋值。原因是非阻塞赋值的调度语义依赖于时间槽而函数是零时间的。很多人写组合逻辑习惯用搬进函数就报错。task 调用函数里不能调用 task理由前面讲过了。模块实例化函数里不能例化模块也不能调用always块。关于$display这类系统任务情况稍微复杂一点。IEEE 1364 标准对 function 中调用系统任务的规定并不明确实操中各家仿真器表现不一Icarus Verilog 和 VCS 一般允许在 function 里用$display但有些工具会报 warning 甚至 error。我的建议是不要在 function 里打印所有调试信息放到调用处或者用$sformatf拼接字符串返回。这样既保证可移植性也不会在代码里留下一堆调试残留。这里有个思维转换的技巧写 function 的时候你就当自己在写一个 Excel 公式。给几个单元格input算出一个结果返回值中间不能有任何等待和延迟。只要脑子里绷住这根弦上面这些红线基本不会碰。3. task 的完整用法与实操要点3.1 语法骨架与端口方向task 的骨架和 function 类似但没有返回值位宽这一项参数方向需要逐个声明task automatic uart_send_byte; input [7:0] data; // 要发送的字节 output done; // 可以带出执行状态 integer i; // 局部变量 begin done 1b0; tx 1b0; // 起始位 #(BIT_PERIOD); for (i 0; i 8; i i 1) begin tx data[i]; #(BIT_PERIOD); end tx 1b1; // 停止位 #(BIT_PERIOD); done 1b1; end endtask几个语法要点。第一参数方向input/output/inout都是允许的而且方向和位宽必须写清楚。第二不写方向的参数默认是input但强烈建议全部显式写出来尤其是有 output 的时候漏写方向会导致 output 变成 input编译不报错但结果全错。第三和 function 一样局部变量必须在begin之后声明。调用 task 的语法有几种写法我都写一下// 位置对应方式最常用 uart_send_byte(8h55, ack_flag); // 命名方式参数多的时候更清晰SystemVerilog 支持较好 uart_send_byte(.data(8h55), .done(ack_flag)); // 无参数 task 的调用 wait_reset_done;关于 ANSI 风格task 也支持在端口列表里直接声明方向和位宽task automatic uart_send_byte_ansi(input [7:0] data, output done); integer i; begin // ... 同上 end endtask不过要注意老版本的 Verilog-1995 工具不支持这种写法如果你维护的是老代码库还是用传统的函数体内声明方式。3.2 时间控制task 真正的主场task 最核心的价值就是能消耗仿真时间这让它成为 testbench 里描述总线协议的主力工具。我举三种典型的时间控制用法。第一种是固定延时#加时间值。UART 里每个比特保持一个波特周期I2C 里 SCL 高低电平各保持半个周期这类场景直接用#(BIT_PERIOD)就完事。延时的单位由timescale决定比如timescale 1ns/1ps就意味着#434是 434 纳秒。这里有个常见坑不同文件的timescale如果不一致延时值会按各自文件的定义来解释导致时序错乱。统一在文件头部写清楚timescale是每个 testbench 的第一条纪律。第二种是事件同步用。在验证 DUT 的行为时最可靠的写法是跟时钟边沿同步task automatic apb_write; input [31:0] addr; input [31:0] data; begin (posedge clk); psel 1b1; penable 1b0; pwrite 1b1; paddr addr; pwdata data; (posedge clk); penable 1b1; (posedge clk); psel 1b0; penable 1b0; end endtask用(posedge clk)而不是固定延时好处是无论周期怎么变时序都对。缺点是如果时钟停了task 会永远等下去仿真挂死——这点我在第 6 章会讲怎么排查。第三种是条件等待用wait。比如等一个握手信号拉高task automatic wait_ready; input integer timeout; integer cnt; begin cnt 0; while (!ready cnt timeout) begin (posedge clk); cnt cnt 1; end if (!ready) $display(ERROR: wait_ready timeout at %0t, $time); end endtask这个写法把超时保护加进去了非常重要。任何用wait或者while等待信号的 task都必须带超时退出条件否则一旦 DUT 出问题仿真会跑到天荒地老。3.3 static 与 automatic最容易翻车的地方这一节我要重点讲因为它是最隐蔽、最难查的一类 bug。标准 Verilog 里task 和 function 默认都是static的。注意这个static在 Verilog 里的含义不是静态变量这么简单而是说这个 task 内部声明的所有局部变量在整个模块的所有实例、所有调用之间是共享的。你没看错是共享。看这个例子// 有问题的写法 task send_frame; input [7:0] len; integer i; // static 变量 begin for (i 0; i len; i i 1) send_byte(i); end endtask // 两个 initial 块并发调用 initial begin #100; send_frame(8d10); end initial begin #110; send_frame(8d20); end两个initial块在时间上有重叠而它们共用同一个i。第一个调用把 i 跑到 3 的时候第二个调用把 i 重置成 0然后第一个调用的循环条件i 10就乱了。结果就是发送的字节数不对、顺序错乱而且这种 bug 有随机性——换个仿真器、改个延时表现还不一样。修复方式很简单加automatictask automatic send_frame; input [7:0] len; integer i; // 每次调用独立分配 begin for (i 0; i len; i i 1) send_byte(i); end endtaskautomatic的含义是每次调用这个 task 时它的局部变量都重新分配一块独立的内存调用结束后释放。这样两个并发调用就互不干扰了。我的实操原则是testbench 里的 task 和 function 一律加automatic无条件、无例外。加了的代价是零现代仿真器分配开销可以忽略不加的代价可能是几天的调试时间。至于综合用的 function加不加都不影响综合结果但加了可以保证 RTL 仿真和门级仿真行为一致所以我也是无脑加。还有一个细节automatic必须写在task/function关键字和函数名之间写成task automatic foo;或function automatic [7:0] bar;。写在别的位置会报语法错误。3.4 用 task 封装 UART / I2C 时序把前面的知识组合起来看看实际项目里怎么用 task 封装协议时序。先看 UART 接收task automatic uart_recv_byte; output [7:0] data; output frame_err; integer i; reg [7:0] d; begin frame_err 1b0; (negedge rx); // 等起始位下降沿 #(BIT_PERIOD / 2); // 半个周期后采起始位中心 if (rx ! 1b0) frame_err 1b1; for (i 0; i 8; i i 1) begin #(BIT_PERIOD); // 每个数据位周期 d[i] rx; // 在位中心采样 end #(BIT_PERIOD); if (rx ! 1b1) frame_err 1b1; // 校验停止位 data d; end endtask这段代码有几个设计考量值得说。第一用(negedge rx)而不是wait(rx 0)因为下降沿是瞬时事件能精确定位起始位。第二采样点选在位中心起始位后半个周期采样起始位之后每整周期采样一次这是 UART 接收的标准做法容忍度最高。第三停止位校验用!而不是!因为!能把 x 和 z 也判为不等校验更严格。再看 I2C 的 start 和 stop 时序这两个是 I2C 协议的基础task automatic i2c_start; begin sda 1b1; scl 1b1; #(T_HALF); sda 1b0; #(T_HALF); // SCL 高时 SDA 下降沿 START scl 1b0; #(T_HALF); end endtask task automatic i2c_stop; begin sda 1b0; scl 1b0; #(T_HALF); scl 1b1; #(T_HALF); sda 1b1; #(T_HALF); // SCL 高时 SDA 上升沿 STOP end endtask写 I2C 最重要的一点是搞清楚 start 和 stop 的判据SCL 保持高电平期间 SDA 的跳变才是 start/stop 条件SCL 低电平期间 SDA 随便变都不算。所以你会看到我在拉 sda 之前先把 scl 拉低就是为了避免误产生 start 条件。这个细节如果搞错接上真实 EEPROM 波形会一片混乱。有输出参数的 task 也很常见比如读一个字节并回 ACKtask automatic i2c_write_byte; input [7:0] data; output ack; integer i; begin for (i 7; i 0; i i - 1) begin sda data[i]; #(T_HALF); scl 1b1; #(T_HALF); scl 1b0; end sda 1bz; // 释放 SDA 让从机拉低 #(T_HALF); scl 1b1; #(T_HALF); ack sda; // 0 表示 ACK scl 1b0; #(T_HALF); end endtask注意sda 1bz这一步这是 I2C 作为开漏总线的关键主机读完 8 位后要释放 SDA让从机有机会把它拉低表示应答。如果忘了释放ack永远是 1你会以为从机没应答。这个坑我在第一次写 I2C 的时候就踩过。4. 选型决策什么时候必须用哪个4.1 从是否消耗仿真时间入手选型的第一判据永远是这一条这段逻辑需要在中间等待/延时吗需要就选 task不需要就选 function。这个判据之所以排第一是因为它是硬件层面的硬约束不是风格偏好。一个需要#(BIT_PERIOD)的逻辑你想用 function 也做不到编译器直接拦下来。反过来一个纯计算的逻辑如果你写成 task虽然能跑但你就失去了把它嵌入表达式的能力——比如你不能写assign sum add8(a, b);只能先调用 task 再取结果代码会长很多。我举两个边界场景帮你判断。场景一计算一个包的 CRC需要遍历所有字节。这是纯计算选 function而且可以在assign里用。场景二向 EEPROM 写一页数据需要发地址、发数据、等 ACK。这是时序流程选 task。还有一种容易误判的情况带循环的位操作。有人会想循环需要时间吧其实不是。function 里的 for 循环是在零时间内全部展开执行的仿真时间不推进。所以查表、移位、编码这类操作哪怕循环几千次依然是 function 的地盘。4.2 从调用位置反推如果第一个判据还不能帮你决定那就看你打算在哪里调用它。只能在过程块里调用 → 两个都行优先 function更轻量、可综合。要在assign连续赋值里调用 → 只能用 function。要在模块实例的端口连接里调用 → 只能用 function。要在另一个 function 里调用 → 只能用 function。要在另一个 task 里调用 → 两个都行。这里的逻辑其实很清晰function 的位置限制比 task 少得多所以能用 function 实现的别写成 task。反过来说task 能用的位置function 基本都能用除了需要时间控制的场合。一个具体的判断例子我之前写 NAND Flash 读写的验证环境需要把读出的数据做 ECC 校验。ECC 计算是纯位运算写成 function然后在读取数据的 task 里调用这个 function。这种task 里套 function的结构非常常见也最能体现两者的分工——task 管流程function 管计算。4.3 从是否要综合反推最后一个判据是综合。这一条决定了你的代码是给仿真器看还是给综合器看。function 是可以综合的。综合器会把它展开成组合逻辑结果和你直接把运算写开是一样的。所以在 RTL 代码里你完全可以放心用 function 来封装常用的组合运算比如地址译码、优先级编码、数据格式转换。这样写出来的 RTL 更短、更易读、更不容易出错。task 在标准 Verilog 里是不可综合的。绝大多数综合工具遇到 task 会直接报错比如 Vivado 会提示 Task is not supported for synthesis 或者 Unsupported construct。我见过一些工具对无时间控制的 task 有有限支持但这是厂商扩展不是标准换个工具就挂。所以原则很清楚task 只出现在 testbench 里不放进 RTL。这里有个现实问题如果你在 RTL 文件里写了 task仿真能过综合报错你会怎么处理我见过有人为了绕过报错把 task 里的内容手动展开复制三遍。这其实是个信号——说明这段逻辑本来就该写成 function。回头看看自己的 task 里有没有时间控制语句如果没有直接改成 function 是最干净的解法。5. 实战把一段 UART 收发 testbench 重构一遍5.1 重构前的烂代码长什么样讲重构之前先看看需要重构的代码。这是一个典型的能跑但没法维护的 UART testbench 片段initial begin // 发第一个字节 0x55 tx 0; #10416; tx 1; #10416; tx 0; #10416; tx 1; #10416; tx 0; #10416; tx 1; #10416; tx 0; #10416; tx 1; #10416; tx 0; #10416; tx 1; #10416; #100000; // 发第二个字节 0xAA又抄了一遍磁数不同 tx 0; #10416; tx 1; #10416; tx 0; #10416; tx 1; #10416; tx 0; #10416; tx 1; #10416; tx 0; #10416; tx 1; #10416; tx 0; #10416; tx 1; #10416; end问题一眼可见。第一波特周期 10416 硬编码了十几次改一次波特率要全文替换漏一个就时序错。第二每个字节手写十行写错一位数据就得重新数一遍。第三这段代码没法参数化、没法循环、没法加校验。第四想加一个错误注入测试故意发错停止位得再抄一遍。5.2 function 负责计算task 负责时序重构第一步把计算和时序分开。计算部分包括波特周期怎么算、校验位怎么算。timescale 1ns / 1ps module uart_tb; parameter CLK_HZ 50_000_000; parameter BAUD 115200; // 计算每个比特的时钟周期数向上取整 function automatic integer calc_bit_period(input integer clk_hz, input integer baud); integer div; begin div (clk_hz (baud / 2)) / baud; calc_bit_period div; end endfunction // 计算偶校验位 function automatic calc_parity(input [7:0] data); begin calc_parity ^data; // 按位异或等价于偶校验 end endfunction localparam BIT_PERIOD calc_bit_period(CLK_HZ, BAUD); reg tx 1b1; reg rx 1b1; // ... 其他信号这里有两个值得讲的点。第一calc_bit_period里的(clk_hz (baud/2)) / baud是四舍五入除法。如果不加baud/250000000/115200 会得到 434截断实际精确值是 434.03误差可以接受但如果时钟和波特率的组合刚好差了半拍截断会累积误差几十个比特之后就采错位了。加半除数是花一分钱买保险。第二calc_parity ^data用了归约异或运算符一行搞定 8 位偶校验。这个运算符在 function 里用特别顺手比写循环清爽得多。然后 task 部分负责真正的时序task automatic uart_send_byte; input [7:0] data; input parity_en; input stop_bits; // 1 或 2 integer i; reg p; begin tx 1b0; // 起始位 #(BIT_PERIOD); for (i 0; i 8; i i 1) begin tx data[i]; // LSB first #(BIT_PERIOD); end if (parity_en) begin p calc_parity(data); // 复用前面的 function tx p; #(BIT_PERIOD); end tx 1b1; #(BIT_PERIOD * stop_bits); // 停止位支持 1 或 2 位 end endtask这个 task 用了三个参数数据、是否开校验、停止位个数。相比原来的复制粘贴版本能力扩展了代码长度反而变短。而且注意这里调用了calc_parity这个 function——task 调 function 是完全合法的也是实际项目里最常见的分层方式。5.3 多字节收发的分层封装单字节发送做完往上叠一层多字节发送task automatic uart_send_bytes; input [255:0] payload; // 最多 32 字节高位对齐 input integer len; // 实际字节数 integer i; begin for (i len - 1; i 0; i i - 1) begin uart_send_byte(payload[i*8 : 8], 1b1, 2d1); end end endtask task automatic uart_send_string; input [8*16-1:0] str; input integer len; begin uart_send_bytes({str, {(32-len)*8{1b0}}}, len); end endtask这里的payload[i*8 : 8]是 Verilog-2001 引入的部分选择语法:表示从起点往高位取 8 位。这种写法比payload[i*87 : i*8]更安全因为当 i 是变量时冒号语法的边界顺序在编译期不确定不同工具可能有不同解读而:明确指定了方向。发送完了要看接收接收端我也用 task 封装task automatic uart_recv_bytes; input integer len; output [255:0] data; output integer err_cnt; integer i; reg [7:0] b; reg e; begin data 256b0; err_cnt 0; for (i 0; i len; i i 1) begin uart_recv_byte(b, e); data[i*8 : 8] b; if (e) err_cnt err_cnt 1; end end endtaskuart_recv_byte就是 3.4 节那个接收单字节的 task。注意这里 task 嵌套调用了三层uart_recv_bytes→uart_recv_byte层级分明每一层只干一件事。这种结构的好处是当你需要单独测试某一个字节的接收行为时直接调用最底层的 task 就行不用在外面搭一整套环境。主测试流程就变得非常清爽initial begin #1000; // 发送 4 字节命令头 2 字节数据 uart_send_bytes(256hAA55_0002_1234_0000_0000_0000_0000_0000, 6); #(BIT_PERIOD * 20); uart_recv_bytes(6, rx_data, rx_err); if (rx_err 0 rx_data[47:0] 48hAA55_0002_5678) $display(PASS: response matched at %0t, $time); else $display(FAIL: err%0d data%h, rx_err, rx_data[47:0]); $finish; end从原来的 20 行复制粘贴变成了一次函数调用。这中间的差别不只是行数更是可维护性、可扩展性和可读性。5.4 跑仿真看波形要盯什么重构完成之后跑仿真有几个地方要重点看波形。第一起始位的下降沿是否干净。UART 的起始位是从空闲高电平拉低如果波形上有毛刺接收端可能误触发。用 task 生成激励的优势就在于时序是程序化的不会出现手工写错导致的毛刺。第二位宽边界处的采样点。把接收端采样的时刻和发送端的位中心对齐看如果采样点落在数据位的边缘说明BIT_PERIOD计算有偏差。前面说的四舍五入除法就是解决这个问题的115200 波特在 50MHz 时钟下误差应该在半个时钟周期以内才算合格。第三多字节之间的间隔。连续发送时两个字节的停止位和下一个起始位之间应该有明确的空闲。如果波形上看到停止位还没结束就出现下降沿说明stop_bits参数或者 task 调用时的参数传错了。第四错误注入的验证。故意调用uart_send_byte(8h55, 1b0, 2d2)然后用只支持 1 位停止位的接收 task 去收看frame_err是否正确置起。这是验证你封装的错误检测逻辑是否有效的标准做法也能反向验证你的 task 参数是否真的生效了。6. 常见报错与排查速查6.1 编译期报错对照表下面这张表是我这些年攒下来的报错清单遇到的时候可以直接对照。注意不同工具的报错文字有差异但原因基本一致。报错关键词真实原因解决方式Function cannot contain a time controlfunction 里出现了#、、wait改成 task或删掉时间控制Non-blocking assignment not allowed in functionfunction 里用了改成阻塞赋值Task not allowed in constant function在常量函数或参数计算里调用了 task把 task 改写成 functionFunction must have at least one inputfunction 没有声明任何 input加一个 input 参数或改用 SystemVerilog 的voidIllegal use of task in continuous assignment在assign里调用了 task改成 function或把调用挪进 always 块Too few/many arguments in task call调用时参数个数和声明不符数一遍参数特别注意 output 参数也要传Task is not supported for synthesisRTL 里写了 task改成 function或把 task 移到 testbenchautomatic variable used in static contextautomatic和static混用统一加automatic这张表里有两条我要特别强调。第一条是Function must have at least one input很多初学者想写一个返回固定值或者只做全局变量操作的函数结果编译报错。标准 Verilog 确实要求至少一个 input解决办法要么加一个 dummy 参数要么改用 SystemVerilog。第二条是Too few arguments参数个数对不上是最常见的调用错误尤其是带 output 参数的 task——很多人只传了 input忘了 output 也要在调用时提供变量。6.2 仿真挂死与数据错乱编译过了不代表能跑对。仿真阶段的问题通常分两类挂死和数据错乱。挂死的表现是仿真时间卡住不动$finish永远不执行。原因基本都是 task 里的等待条件永远不满足。比如(posedge clk)但时钟模块没启动或者wait(ready)但 ready 因为复位没释放一直是 0。排查方法很直接在等待语句前后加$display(waiting at %0t, $time)看打印卡在哪一行。更专业的做法是给每个等待加超时计数就像 3.2 节那个wait_ready一样。数据错乱的原因就多了我按出现频率排一下。第一是 static 变量冲突两个并发调用的 task 共享了局部变量解法是加automatic。第二是位宽截断返回值或者中间变量的位宽不够解法是算清最大值再声明。第三是采样点偏了UART/I2C 这类串行协议的采样时刻没对齐位中心解法是检查延时常量。第四是参数方向写反把 output 参数当成 input 用了解法是核对 task 声明和调用处。排查数据错乱有个技巧把 task 的每一次调用都打印一条带时间戳的日志。比如$display([%0t] send byte %h, $time, data);然后拿日志和波形对照。很多时候波形上看不出来时序问题的根源但日志的时间戳会直接告诉你哪个字节早发了一个周期。6.3 综合器不认 task 怎么办最后说综合的问题。如果你在 RTL 里写了 task综合报错有三个处理思路。思路一是把 task 改成 function。判断标准是 task 里有没有时间控制语句。如果没有改成 function 是最干净的方案因为 function 是可综合的。改的时候注意两点把所有 output 参数改成通过返回值传出多输出可以打包成一个拼接向量把中间的时间控制删掉。思路二是把 task 移到 testbench 里。如果这个 task 只用于仿真激励那就应该在 testbench 文件里定义RTL 文件里不应该出现。很多项目的目录结构是rtl/和tb/分开的task 天然属于tb/。思路三是手工展开。这是最不想推荐的方式因为它违背了封装原则会带来维护问题。只有在前面两条都走不通而且这段代码确实需要综合的情况下才考虑展开。展开的时候记得加注释说明此处逻辑与 xxx 保持一致方便以后同步修改。还有一个容易忽略的兼容性问题同一个 function 在 RTL 仿真和门级仿真下的行为可能不同。原因是门级网表里 function 已经被综合工具展开成门电路了如果你的 function 里有什么依赖仿真器特性的写法比如未初始化的变量当作 x 处理行为可能对不上。避免这个问题的方法是function 里所有局部变量都显式初始化所有位宽都写全不依赖任何隐式规则。提示写 RTL 用的 function 时我习惯在开头把所有局部变量统一初始化比如reg [7:0] tmp 8h00;。这样无论仿真器怎么处理未初始化变量结果都是确定的。这个习惯花不了几秒钟但能省掉很多仿真对、上板错的问题。最后分享两个我压箱底的小技巧。第一个是关于 function 位宽的写参数化的 function 时返回值位宽尽量用$clog2或者参数表达式来算比如function [$clog2(MAX_LEN)-1:0] find_index;这样即使以后 MAX_LEN 从 16 改成 1024函数都不用动。以前我吃过亏一个索引函数写死了[3:0]后来深度扩到 20 就溢出了波形上表现为索引周期性回绕查了一整天才发现是位宽问题。第二个是关于 task 调试的把 task 的名字和参数在进入时打印出来退出时再打印一次消耗的时间。写法很简单$display( %m at %0t, $time)和$display( %m at %0t, $time)其中%m会自动打印当前层次的完整路径名。这个技巧在多任务嵌套调用的时候特别好用一眼就能看出是哪一层卡住了。我用这个办法在半小时内定位过一个三层 task 嵌套里的死锁问题如果没有它估计得翻半天代码。
