IP验证最终回归到时序级建模

假设验证一个FIFO模块。设计的RTL代码严格按照时钟周期工作,第10个时钟上升沿写入数据,第15个时钟上升沿读出数据。而参考模型如果用Python写,内部用队列结构模拟,可能第1秒push数据,第2秒pop数据。

问题来了:比较器该怎么判断结果对不对?

更麻烦的是,这个时间差还不固定。FIFO里数据量不同,延迟就不同。有时DUT第20周期输出,有时第25周期输出,而参考模型的输出时间也在飘。两边的时间基准完全不同步,比较器根本没法建立稳定的对应关系。

有人会说,不关心时序不就可以了，这样很多复杂乱序处理、延迟变化、突发流量等各种情况就验证不够完备。

所以IP验证走到最后,大家发现最靠谱的办法还是:参考模型和DUT用同一个激励源,按同样的时序运行。

这就意味着参考模型不能完全脱离硬件时序,它需要理解时钟周期、握手信号、ready/valid协议这些底层概念。虽然还是可以用SystemVerilog或者高级语言写,但必须是时序级参考模型(Cycle-Accurate Model)。

时序级参考模型长什么样?

go 复制代码

// 简化的FIFO参考模型示例
class fifo_reference_model;
  logic [7:0] queue[$];
  
  task run(input logic clk, wr_en, rd_en, 
           input logic [7:0] wr_data,
           output logic [7:0] rd_data);
    @(posedge clk);  // 和DUT同步到时钟边沿
    if (wr_en) queue.push_back(wr_data);
    if (rd_en && queue.size() > 0) 
      rd_data = queue.pop_front();
  endtask
endclass

注意那个@(posedge clk),这就是时序同步的关键。参考模型和DUT共享同一个时钟,在相同的时钟边沿执行操作,输出自然就能对齐。

当然,时序级参考模型牺牲了一些灵活性。它不能像纯粹的算法模型那样随意组织逻辑,必须考虑握手、流控、延迟这些硬件细节。但这是必要的代价,因为验证的本质就是要在真实的时序环境下检查设计行为。

这里有个微妙的平衡。参考模型要足够抽象,避免陷入RTL实现细节,否则就失去了独立性。但又要足够贴近硬件时序,才能和DUT的输出建立可靠的对应关系。太抽象对不上,太具体又失去了验证意义。

实际项目中,验证团队通常会分层建模:

顶层用事务级模型(Transaction-Level Model)快速验证功能正确性
底层用时序级模型精确比对每个周期的输出
两者配合使用,既保证效率又保证准确性