[UVM源代码研究] 当我们在tb里调用run_test()时uvm环境是如何启动的

原创最新推荐文章于 2026-10-13 13:34:15 发布 1.1k 阅读 AI写同款

662粉丝48篇原创

关注

UVM验证环境中tb_top与uvm_test的协同工作机制解析本文深入解析了UVM验证环境中tb_top模块与uvm_test类的协同工作机制。通过舞台与导演的生动比喻，阐述了tb_top作为静态硬件平台负责搭建DUT接口与生成时钟复位，而uvm_test作为动态测试控制器负责构建验证环境与执行测试场景。两者通过run_test()启动，并借助uvm_config_db传递虚拟接口实现无缝协作，是构建高效验证环境的核心。阅读详情

AI摘要

文章详细解析了UVM中的run_test函数，讨论了其作为环境入口的角色，函数是任务而非函数，定义在uvm_root中并通过uvm_globals封装为全局可见。分析了run_test带参数与不带的区别，以及如何通过命令行参数启动测试。

作为一个验证工程师，每一个顶层tb里一般都少不了下面这段代码（前后可能还会有些timeformatf或者uvm_config_db的设置），并且书上都告诉你这是uvm环境启动的入口。

initial begin
   run_test();
end

那么问题来了，
1、这个run_test()是一个函数还是个任务？
2、它定义在哪里？
3、为什么module里能够直接调用？
4、有时候可以带参数有时候又可以不带，区别在哪里？
5、作为uvm环境的入口，这个run_test()是怎么做到启动uvm环境的？

我们在uvm源代码里搜索run_test()的定义，找到如下定义：在这里插入图片描述

这个run_test()根源调用的还是uvm_root里定义的run_test()我们稍后再去分析，等于说uvm_globals将uvm_root里定义的run_test()通过单例模式获取uvm_root的唯一实例并将其封装成了一个全局可见的任务run_test()，那我们不禁要问：这个uvm_globals文件是如何实现里面的内容全局可见的呢？
我们在搜下uvm_globals关键字发现它在uvm_base.svh里被include了
添加图片注释，不超过 140 字（可选）

而uvm_base.svh这个文件又是在uvm_pkg.svh里被include的
添加图片注释，不超过 140 字（可选）

这样一来，只要我们在任何需要调用run_test()的作用域内执行import uvm_pkg:😗，我们就可以调用uvm_globals里所调用的全局变量/方法了。
通过上面的分析我们就已经回答了前3个疑问了，即
1、这个run_test()是一个函数还是个任务？task
2、它定义在哪里？uvm_root中，并在uvm_globals.svh中被封装成了一个全局可见任务
3、为什么module里能够直接调用？只要import uvm_pkg::*就可以调用uvm中的全局任务

这里再给大家补充一点systemverilog中关于作用域的知识点：
添加图片注释，不超过 140 字（可选）

以上两种import uvm_pkg::的方法，对应实际uvm内的可见范围是不同的。
方式1是一种全局import，编译后会放在$unit编译单元中，这样后面所有编译的文件都能看到uvm import的相关内容；
方式2这样import只会在module tb内可见，跳出这个module后面编译的文件是看不到uvm import的相关内容的，所以只要不是全局import，在每个独立的作用域内都会去import uvm_pkg::;
所以大家以后import package的时候一定要明白你import的内容的可见域是什么范围，以免出现class not defined这种情况。

下面我们接着一点点分析看看uvm_root里的run_test都做了些什么。首先是变量的声明