1.为什么不接受目视检查波形

在芯片验证中，波形检查主要用于debug，不接受“目视检查”（即人工查看波形）作为最终通过标准，主要基于以下原因：

1） 无法应对大规模回归测试
验证过程中需要运行大量的随机种子（Random Seeds）进行回归测试（Regression）。 面对海量的测试用例，人工逐一检查波形是不现实的，必须依靠自动化比对。

2） 存在“假Pass”风险（波形检查）
仅凭目视或简单的错误计数为零来判断通过并不可靠，可能存在以下漏测情况：
* 断言覆盖不全：如果未编写完整的断言（Assert）或错误处理（Else），某些随机化失败或异常可能不会被报错，导致误判为通过。
* 仿真异常中断：若因服务器原因导致仿真中途停止，可能既无Error也无Fail，目视容易忽略此类未完成的情况。

3）缺乏客观性与严谨性
目视检查依赖个人主观判断，容易出错且无法保证一致性。 工业界标准要求使用 Scoreboard（比较器）将 DUT 的实际输出与参考模型（Reference Model）的期望输出进行自动化比对，以确保结果的准确性。

因此，波形主要用于 Debug 和初步检查，而最终的验证结果必须依赖自动化的数据比对机制。

script激励

image
这张图描述的根本不是 UVM 的“随机激励”，而是一种“指令级脚本激励”——通过解析脚本指令序列来控制 DUT 的行为，类似于“汇编级测试程序”，在仿真开始前就已经生成，需要通过TB来解析解码。
上层（用户自定义指令）：你预先定义好一组指令助记符（SEND、ADDR、NEXT），并写好它们的操作码（11、00、01）和关联数据（A、F）。
中间层（Testbench 解析器）：TB 中的解析模块（Instruction decode）读取这些指令序列，将助记符翻译成实际的控制信号（DO.ADDR、DO_SEND、DO_NEXT）。
底层（DUT 执行）：解析后的信号驱动 DUT 完成具体功能（发送数据、切换地址等）。

reference/golden model特点

高级语言书写，执行时不占用仿真时间，在0时刻就已经运算出结果，并通过scoreboard记录expect期望结果。
自动与DUT的输出进行比对，输出report
image
注意：这里送到两个模型的输入一定要一致，但是输入reference model的可能不符合对应高级语言要求，需要进行转化，此时一定要格外注意，如果结果不一致首先检查的就是这个转化是否正确。

控制

同步激励产生并对DUT/DUV输出进行记录检查，记录的仿真结果包括dut输出和reference model输出，log日志，波形等。
测试平台控制包括哪些：时钟，复位，fail和pass信息，结束控制finish等。

  • 时钟信号和复位信号：一个模块可能有多个复位/时钟，控制不同的部分要在读spec时明确时钟之间、复位之间、时钟与复位之间的关系，明确时钟1和时钟二之间的相位关系，复位1控制复位2的场景（甚至更复杂），时钟与复位之间一般都是时钟到来后复位，也要注意一下。
  • fail和pass信息：参考上面刚开始时的问题，明确fail信息和pass信息的关注点。

UVM TB

image
这个图里面没有写reference model，下面说明一下Agent的active模式和passive模式

  • active模式：可以理解为输入Agent代理，内部包含sequencer、driver、monitor组件，其中monitor组件用于监听driver发送给DUT的输入，并将其带给reference model产生期望输出结果。
  • passive模式：可以理解为输出Agent代理，内部只有monitor用于监听DUT输出并作为计分板的另一个输入进行比较。
  • confing配置：主要用于配置Agent内的组件，例如配置monitor监听信号的波特率。
  • 顶层virtual sequuencer:控制所有testcase的sequencer
  • seqlib_ctrl:用于控制sequencer什么时候开始，选择什么激励序列库，例如测试用例（top_test_1）会从这两个库里挑选具体的序列（Seqlib_2g/3g）来执行，从而产生不同的流量模式。
  • tb_config（全局配置对象）:用于控制各个子 Agent 的配置句柄（producer_config、consumer_config、- - control_config），只需要在顶层测试用例中修改 tb_config.clock_freq = 100M;，这个值就会通过 -- -- config_db 自动下发给所有底层组件，避免了层层传递信号的麻烦。
  • tb_tests_pkg: SystemVerilog 包（Package），里面集中定义了该验证环境支持的所有顶层测试用例类（top_test_1、top_test_2 ... top_test_N）。可以通过 +UVM_TESTNAME=top_test_1 动态指定跑哪一个用例，而不需要重新编译代码。
    可以参考这个链接：https://www.cnblogs.com/tuck0603/p/22494958

Makefile入门：https://zhuanlan.zhihu.com/p/21006634924