1. 从一根线到一套验证管道UART BFM 到底在做什么串口这东西搞嵌入式的人没有不熟的。两根线一根收一根发约定好波特率数据就能一个比特一个比特地传过去。但如果你做过稍微复杂一点的 FPGA 或 ASIC 验证就会发现一个尴尬的现实DUT 的 UART 接口摆在那里你总不能每次测试都手动敲键盘发数据、拿示波器看波形吧。这时候就需要一个UART BFMBus Functional Model总线功能模型来充当“虚拟对端”在仿真环境里自动完成串行数据的收发和校验。我最初接触 BFM 这个概念是在做一款工业控制芯片的验证时。那颗芯片有四个 UART 通道每个通道支持不同的波特率和数据格式如果靠手写 testbench 里的移位逻辑去模拟收发代码又臭又长不说稍微改个波特率就得重算分频系数维护成本极高。后来把 UART BFM 抽出来做成一个可配置的验证组件整个 testbench 的结构瞬间清爽了——激励生成、协议驱动、结果比对各司其职改参数只需要动几个宏定义。这篇文章要聊的就是怎么从零设计并实现一个能用的 UART BFM核心目标是收发自检不仅能按照配置发送串行比特流还能在接收端自动采样、解帧、比对把“发出去的数据”和“收回来的数据”在仿真阶段就闭环验证掉。适合正在搭建 FPGA/IC 验证环境的朋友也适合想理解 BFM 设计思路的嵌入式工程师。哪怕你之前只写过简单的 testbench跟着思路走也能搭出一套可复用的 UART 验证管道。2. 整体设计与思路拆解2.1 为什么不用现成的 UART IP 而要自己写 BFM很多人第一反应是UART 协议这么简单随便找个开源 IP 核塞进 testbench 不就行了我一开始也这么想实际用下来发现几个问题。开源 UART IP 通常是可综合的设计面向的是实际硬件实现代码里充斥着跨时钟域同步、亚稳态处理、FIFO 缓冲这些跟验证无关的逻辑。把它放进 testbench相当于为了发几个字节背了一整套硬件包袱。更麻烦的是可综合 IP 的接口往往是 AXI、APB 或者自定义总线你还得再写一层适配逻辑去驱动它验证代码的复杂度反而上去了。BFM 的定位完全不同。它只面向仿真不需要考虑可综合性可以用 SystemVerilog 的 class、randomize、assertion 这些高级特性代码量能压缩到可综合 IP 的三分之一甚至更少。更重要的是BFM 的接口是“事务级”的——你给它一个字节它负责把这个字节变成符合时序的串行比特流它收到一串比特负责还原成字节并告诉你校验结果。这种抽象层次才是验证环境真正需要的。还有一个现实考量自检能力。现成 IP 只管收发不管对错。而 BFM 可以在内部集成比对逻辑发送时记录期望值接收时自动比对一旦不匹配立刻报错并打印上下文。这个能力在回归测试里价值巨大能帮你省掉大量人工看波形的时间。2.2 收发自检管道的架构设计整个 BFM 的架构可以拆成三个层次我用一个表格来说明各层的职责和关键设计点。层次职责关键设计点事务层提供字节级读写接口管理收发队列支持阻塞/非阻塞调用内置期望值队列协议层完成并行字节与串行比特流的转换波特率分频、起始/停止位生成、采样点对齐信号层驱动和采样物理引脚三态控制、空闲态维持、毛刺过滤事务层是 testbench 直接调用的接口。我通常提供send_byte()、recv_byte()、send_stream()、recv_and_check()这几个方法。send_stream()接受一个字节数组内部循环调用send_byte()recv_and_check()则从接收队列取数据跟期望队列逐个比对。协议层是核心。发送方向它把 8 位并行数据加上起始位、校验位、停止位组装成一个完整的帧然后按照波特率分频系数逐位输出到tx引脚。接收方向它持续监测rx引脚检测到起始位下降沿后在每一位的中间时刻采样凑齐一帧后做校验通过则推入接收队列。信号层处理物理引脚的细节。比如tx在空闲时必须保持高电平发送结束后要恢复到高电平rx采样时要考虑信号抖动通常会在采样点附近做多次采样取多数值。这些细节看似琐碎但少了任何一个BFM 在实际仿真中都会出问题。2.3 参数化设计一套代码适配多种配置UART 的配置参数主要有四个波特率、数据位宽、校验方式、停止位长度。如果 BFM 把这些写死那跟手写移位逻辑没区别。我的做法是用 SystemVerilog 的parameter和typedef enum把这些配置项暴露出来在实例化时通过defparam或参数传递覆盖。波特率的分频系数计算是个关键点。假设系统时钟频率为CLK_FREQ目标波特率为BAUD_RATE则分频系数DIV CLK_FREQ / BAUD_RATE。比如 50MHz 时钟、115200 波特率DIV 50000000 / 115200 ≈ 434。这个值不一定是整数直接取整会引入误差。误差率计算公式是|DIV_actual - DIV_ideal| / DIV_ideal一般要求控制在 2% 以内否则接收端可能采样错位。我在实际项目里遇到过 50MHz 配 921600 波特率的情况DIV 50000000 / 921600 ≈ 54.25取整后误差约 0.46%勉强能用。但如果时钟频率更低比如 25MHz误差就会超过 2%这时候就得考虑用小数分频或者提高时钟频率。这个计算过程在 BFM 初始化时就应该做一次如果误差超标直接报 warning避免仿真跑了一半才发现通信失败。3. 核心细节解析与实操要点3.1 发送路径从字节到比特流的完整转换发送路径的核心是一个状态机我把它设计成四个状态IDLE、START、DATA、STOP。IDLE状态下tx保持高电平收到发送请求后跳转到START拉低tx一个比特时间然后进入DATA按低位先出的顺序逐位输出数据最后进入STOP拉高tx一个或两个比特时间回到IDLE。这里有个容易踩的坑数据位的输出顺序。UART 协议规定低位先出LSB first但很多人在写移位逻辑时习惯性用左移结果发出去的数据位序反了。我建议在代码里明确写注释并且用for循环从bit 0到bit 7逐位赋值避免用移位操作符带来的歧义。校验位的生成也需要仔细处理。偶校验要求数据位中 1 的个数为偶数奇校验则为奇数。实现时可以用^data做归约异或得到数据位的奇偶性再根据校验模式决定校验位的值。如果是无校验模式直接跳过校验位。// 偶校验位生成示例 function bit calc_even_parity(bit [7:0] data); return ^data; // 归约异或1的个数为奇数时返回1 endfunction // 奇校验位生成 function bit calc_odd_parity(bit [7:0] data); return ~(^data); endfunction发送状态机的时钟分频逻辑也值得说一下。我通常用一个计数器baud_cnt从 0 计到DIV-1计满后产生一个baud_tick脉冲状态机只在baud_tick有效时推进。这样状态机的每个状态持续恰好一个比特时间逻辑清晰且易于调试。3.2 接收路径采样点对齐与噪声容忍接收路径比发送复杂因为 BFM 不知道对端什么时候开始发数据必须持续监测rx引脚。我的做法是在IDLE状态下每个时钟周期检测rx是否从高变低一旦检测到下降沿认为起始位到来启动接收流程。采样点的选择是接收路径的关键。理想情况下应该在每一位的中间时刻采样这样对时钟偏差的容忍度最大。具体实现时检测到起始位下降沿后先等待DIV/2个时钟周期确认rx仍然为低过滤毛刺然后每隔DIV个周期采样一次依次采集数据位、校验位和停止位。注意起始位的确认采样非常重要。如果只是检测到下降沿就开始接收一个短暂的干扰脉冲就会导致误触发。我通常会在下降沿后DIV/4和DIV/2两个时刻各采样一次两次都为低才确认起始位有效。停止位的检查也不能省。接收完数据位和校验位后采样停止位如果停止位不是高电平说明帧格式错误可能是波特率不匹配或者对端异常应该报错并丢弃这一帧。我在早期版本里忽略了停止位检查结果波特率配错时接收到的全是乱码排查了半天才发现问题。3.3 自检机制期望值队列与实时比对自检的核心思路是维护一个期望值队列。每次调用send_byte()时除了把数据发出去还把数据推入期望队列。接收路径每收到一个字节就从期望队列头部弹出一个值进行比对。如果队列为空或者值不匹配立即报错。这个机制在回环测试loopback中特别有用。把 BFM 的tx和rx短接发送什么就应该收到什么自检逻辑会自动验证整个收发链路的正确性。我在项目里通常会在仿真开始时先跑一轮回环自检确认 BFM 本身工作正常再去连 DUT。比对失败时的错误信息要尽可能详细。我一般会打印期望值、实际值、当前仿真时间、已发送/已接收的字节计数。这些信息能帮你快速定位是发送端出了问题还是接收端出了问题还是 DUT 本身有 bug。// 自检比对逻辑示例 task automatic recv_and_check(output bit [7:0] data); bit [7:0] expected; recv_byte(data); if (expected_queue.size() 0) begin $error(接收队列为空收到意外数据: 0x%02x %0t, data, $time); return; end expected expected_queue.pop_front(); if (data ! expected) begin $error(数据不匹配: 期望 0x%02x, 实际 0x%02x %0t, expected, data, $time); end endtask3.4 时钟域与复位处理BFM 通常运行在 testbench 的时钟域下而 DUT 的 UART 可能工作在另一个时钟域。如果两者时钟频率不同就需要在 BFM 和 DUT 之间做时钟域转换。最简单的做法是 BFM 直接使用 DUT 的时钟但这样会限制 BFM 的复用性。我的做法是让 BFM 自带一个时钟输入端口在 testbench 顶层把 DUT 的时钟接进来。这样 BFM 的波特率分频系数就是相对于 DUT 时钟计算的采样点也能和 DUT 的发送时序对齐。如果 DUT 有多个时钟域每个 UART 通道配一个独立的 BFM 实例各自接对应的时钟。复位处理也需要注意。BFM 应该在复位有效时清空所有队列、状态机回到IDLE、tx拉高。我见过有的 BFM 实现忘了在复位时清空期望队列结果复位后第一次比对就报错查了半天才发现是队列里残留了复位前的数据。4. 实操过程与核心环节实现4.1 环境搭建与文件组织先说一下我的文件组织方式这套结构在多个项目里验证过比较好维护uart_bfm/ ├── uart_bfm_pkg.sv // 包定义包含所有 class 和 typedef ├── uart_bfm_if.sv // 接口定义声明 tx/rx 等信号 ├── uart_bfm.sv // BFM 顶层模块实例化接口和 class └── uart_bfm_test.sv // 简单的自测 testbench把 BFM 做成 package 的好处是testbench 里只需要import uart_bfm_pkg::*;就能使用所有类和方法不需要关心内部实现。接口文件单独放方便在不同的 testbench 里复用。顶层模块uart_bfm.sv的职责是把接口信号和 class 对象连接起来。它内部实例化一个uart_bfm_class对象把接口的tx、rx信号通过 virtual interface 传给 class。这样 class 里的方法就能直接操作物理信号了。4.2 波特率分频系数的计算与验证前面提到了分频系数的计算公式这里展开说一下实际计算过程。假设系统时钟CLK_FREQ 100MHz目标波特率BAUD_RATE 115200DIV_ideal 100_000_000 / 115200 868.0555... DIV_actual 868 (取整) 误差率 |868 - 868.0555| / 868.0555 0.0064%这个误差非常小完全没问题。但如果CLK_FREQ 10MHz同样 115200 波特率DIV_ideal 10_000_000 / 115200 86.8055... DIV_actual 87 误差率 |87 - 86.8055| / 86.8055 0.224%也在可接受范围内。但如果波特率提高到 921600DIV_ideal 10_000_000 / 921600 10.8507... DIV_actual 11 误差率 |11 - 10.8507| / 10.8507 1.376%接近 2% 的警戒线了。这时候如果对端也有类似误差累积起来就可能采样错位。我的建议是在 BFM 初始化时自动计算误差率超过 1.5% 就报 warning超过 2% 直接报 error 并终止仿真。4.3 发送任务的实现细节发送任务send_byte()的完整流程如下等待 BFM 空闲状态机在IDLE把数据推入期望队列拉低tx启动起始位等待DIV个时钟周期逐位输出数据位LSB first每位等待DIV个周期如果有校验位输出校验位并等待DIV个周期拉高tx输出停止位并等待DIV或2*DIV个周期回到IDLE这里有个细节停止位的长度。标准 UART 支持 1 位、1.5 位、2 位停止位。1.5 位停止位在实现上需要等待1.5*DIV个周期如果DIV是奇数还得处理半个周期的情况。我通常建议在 BFM 里只支持 1 位和 2 位停止位1.5 位用得少且实现麻烦如果 DUT 需要 1.5 位可以在 testbench 层面做特殊处理。发送过程中的阻塞行为也值得考虑。send_byte()默认是阻塞的调用后会一直等到发送完成才返回。如果 testbench 需要连续发送多个字节可以在send_stream()里循环调用或者提供一个非阻塞版本send_byte_nb()把数据推入发送队列后立即返回由 BFM 内部的状态机异步处理。4.4 接收任务的实现细节接收任务recv_byte()的流程等待rx出现下降沿起始位等待DIV/2个周期确认rx仍为低等待DIV/2个周期此时处于第一个数据位的中间采样数据位每隔DIV个周期采样下一位采样校验位如果有采样停止位检查是否为高校验通过则把数据推入接收队列接收任务通常是阻塞的调用后会一直等到收到一个完整字节才返回。如果 testbench 需要同时处理多个通道可以为每个通道创建一个独立的接收线程用fork...join_none启动接收到的数据推入共享队列主线程从队列取数据做比对。提示接收线程里一定要加超时机制。如果 DUT 因为某种原因没有发送数据接收线程会永远阻塞导致仿真挂死。我通常设置一个超时时间比如 10 个帧时间超时后报 error 并退出线程。4.5 回环自测的搭建与运行回环自测是验证 BFM 本身是否正常工作的最快方法。搭建步骤实例化 BFM把tx和rx短接配置波特率、数据位宽、校验方式、停止位生成一组随机数据建议覆盖 0x00、0xFF、0x55、0xAA 这些边界值调用send_stream()发送数据调用recv_and_check()接收并比对检查错误计数如果为 0 则 BFM 工作正常我通常会在自测里跑 1000 个随机字节覆盖不同的数据模式。如果自测通过再去连 DUT 就有信心了。自测不通过的话问题一定在 BFM 本身排查范围小很多。// 回环自测示例 initial begin bit [7:0] test_data[$]; // 生成测试数据 for (int i 0; i 1000; i) begin test_data.push_back($urandom_range(0, 255)); end // 添加边界值 test_data.push_back(8h00); test_data.push_back(8hFF); test_data.push_back(8h55); test_data.push_back(8hAA); // 发送并自检 bfm.send_stream(test_data); foreach (test_data[i]) begin bit [7:0] recv_data; bfm.recv_and_check(recv_data); end $display(回环自测完成错误数: %0d, bfm.error_count); end5. 常见问题与排查技巧实录5.1 接收数据错位或乱码这是最常见的问题表现是接收到的数据和发送的不一致或者全是乱码。排查思路按以下顺序进行排查项检查方法常见原因波特率分频系数打印 DIV 值和误差率计算错误或误差超标数据位序检查发送和接收的移位方向发送 LSB first接收误用 MSB first采样点位置波形上确认采样时刻采样点偏移到数据位边缘停止位检查确认停止位采样为高波特率不匹配导致停止位错误校验位配置确认收发双方校验方式一致一方有校验一方无校验我遇到最多的是波特率分频系数算错。有一次用 24MHz 时钟配 9600 波特率DIV 24000000 / 9600 2500这个值是对的但代码里写成了2499导致累积误差越来越大收到第 5 个字节开始就乱码了。所以分频系数的计算一定要用宏或者函数自动完成不要手写数字。5.2 起始位误触发如果rx线上有毛刺或者对端在空闲时信号不稳定BFM 可能会误判起始位导致接收线程被意外唤醒。解决方法是在检测到下降沿后等待DIV/4个周期再采样一次确认仍为低才继续。如果DIV较小比如小于 8可以适当增加确认采样的次数。还有一种情况是 DUT 的tx在复位后没有正确拉高一直保持低电平BFM 会认为起始位一直有效接收线程反复触发。这时候需要检查 DUT 的复位逻辑确保tx在空闲时保持高电平。5.3 仿真挂死或超时仿真挂死通常是因为接收线程在等待一个永远不会到来的起始位。我建议在所有接收任务里都加超时机制task automatic recv_byte(output bit [7:0] data); fork begin : wait_start (negedge rx); // 接收逻辑... end begin : timeout #(FRAME_TIME * 10); $error(接收超时 %0t, $time); disable wait_start; end join_any disable fork; endtask超时时间一般设为 10 个帧时间。如果 10 个帧时间内都没收到数据说明对端确实没有发送或者连接有问题。5.4 多通道并发时的资源冲突如果 DUT 有多个 UART 通道每个通道配一个 BFM 实例需要注意共享资源的保护。比如多个 BFM 同时往同一个日志文件写错误信息可能会导致输出交错。我的做法是给每个 BFM 分配独立的日志文件或者在写日志时加互斥锁。另外如果多个 BFM 共享同一个期望队列需要确保队列操作是线程安全的。SystemVerilog 的队列本身不是线程安全的多个线程同时push_back或pop_front可能导致数据损坏。我通常给每个 BFM 配独立的队列避免共享。5.5 校验错误的处理策略校验错误奇偶校验不匹配的处理策略取决于测试场景。如果是回环自测校验错误说明 BFM 本身有问题应该立即报 error 并终止。如果是连 DUT 测试校验错误可能是 DUT 的 bug也可能是测试激励的问题这时候应该记录错误但继续运行让测试跑完后再统一分析。我通常会在 BFM 里提供一个error_policy配置项支持STOP_ON_ERROR和CONTINUE_ON_ERROR两种模式。回归测试用CONTINUE_ON_ERROR调试阶段用STOP_ON_ERROR。6. 性能优化与复用扩展6.1 提高仿真速度的技巧BFM 的仿真性能主要受限于波特率分频系数。如果DIV很大比如 868每个比特要等 868 个时钟周期发一个字节要等将近 9000 个周期仿真速度会很慢。优化方法有几种一是降低系统时钟频率。如果 DUT 允许把仿真时钟降到刚好满足波特率要求的最低频率。比如 115200 波特率理论上 1MHz 时钟就够用DIV ≈ 8.68没必要用 100MHz。二是使用时间缩放。在 testbench 里用timescale把时间单位放大减少实际仿真周期数。但这个方法要小心可能影响 DUT 内部的其他逻辑。三是批量发送。把多个字节打包成一个事务发送减少状态机切换的开销。我在send_stream()里做了这个优化连续发送时状态机不需要回到IDLE直接从前一个字节的停止位过渡到下一个字节的起始位。6.2 从 UART 扩展到其他协议的思路UART BFM 的设计思路可以复用到其他串行协议上。核心抽象是事务层 协议层 信号层的三层架构。把协议层替换成 SPI、I2C 或 CAN 的编解码逻辑事务层和信号层基本不用改。比如 SPI BFM协议层需要处理时钟极性、时钟相位、片选信号这些 SPI 特有的细节但事务层的send_byte()、recv_byte()接口可以保持不变。I2C BFM 则需要处理起始条件、地址帧、应答位这些 I2C 特有的机制。我在一个项目里把 UART、SPI、I2C 三个 BFM 做成了统一的serial_bfm_base基类派生类只需要实现协议层的encode_frame()和decode_frame()方法。这样 testbench 可以用统一的方式调用不同协议的 BFM代码复用率很高。6.3 与 UVM 验证方法的集成如果项目用的是 UVM 验证方法学UART BFM 可以作为 UVM agent 的一部分。具体做法是把 BFM 封装成一个 UVM driver事务层的接口对应 UVM sequence item自检逻辑放在 UVM scoreboard 里。UVM 的优势是提供了完整的验证框架包括 sequence、driver、monitor、scoreboard、coverage 等组件。但 UVM 的学习曲线比较陡如果项目规模不大直接用 SystemVerilog class 写 BFM 更轻量。我的经验是模块级验证用纯 SV BFM 就够了系统级验证再考虑上 UVM。7. 一些实操心得与避坑建议先说一个我踩过的坑期望队列的深度管理。如果 testbench 发送数据的速度快于接收速度期望队列会不断增长占用大量内存。我在一个压力测试里发了 100 万个字节期望队列涨到了 100 万条仿真内存直接爆了。后来改成滑动窗口机制期望队列最多保留 1024 条超出的部分自动丢弃并报 warning内存问题就解决了。另一个坑是复位时的队列清理。前面提过但值得再强调一次。复位有效时一定要清空期望队列和接收队列否则复位后的第一次比对必然失败。我建议在 BFM 的复位处理逻辑里加一个assert确保复位后队列为空。关于校验方式的选择我的建议是如果 DUT 支持尽量用偶校验而不是奇校验。偶校验的实现更直观归约异或直接得到校验位调试时也更容易理解。奇校验需要额外取反多一步操作就多一个出错的可能。最后说一个调试技巧在 BFM 里加一个verbose开关打开后打印每个比特的发送/接收详情包括时间戳、比特值、当前状态机状态。这个功能在排查时序问题时非常有用能让你不用看波形就知道 BFM 在做什么。当然verbose 模式会拖慢仿真速度只在调试时打开。这套 UART BFM 我在三个项目里用过从简单的回环测试到复杂的多通道并发验证都跑得通。核心经验就是把协议细节封装在 BFM 内部对外只暴露事务级接口自检逻辑内置参数全部可配置。做到这三点BFM 就能真正成为验证环境里可靠的“收发自检管道”而不是又一个需要维护的负担。