典型的基于UVM 的验证平台（Testbench）通常会实例化DUT和UVM Testcase，以及完成DUT和UVM Testcase之间的链接。其中Testcase中的内容可以根据“静态”和”动态”两方面进行分类。
静态的内容，即在不同的测试用例中都保持不变的东西，也就是“验证环境”
动态的内容，即在不同的测试用例中会发生变化的东西，包括“配置”，“输入激励”
执行仿真回归时，仿真器会动态地实例化UVM Testcase，但是静态的验证环境只需要编译一次。
通常我们也会有一个base test类，在此类的基础上进行扩展，通过不同的配置和sequence以覆盖不同的测试场景。
UVM验证架构的一个典型特征就是分层，例如UVM Environment底下的 UVM
Agents, UVM Scoreboards ，并且一个系统级的UVM Environment也可以实例化多个IP级的UVM Environment，例如一个SoC的UVM Environment会实例化PCIe Environment, USB Environment, Memory Controller Environment等等
UVM Agent组件下会实例化支持同一个事务类型的组件，UVM Sequencer、UVM Driver和UVM Monitor。
上述为UVM验证平台架构的静态部分，动态部分（配置和激励）都是通过验证平台和DUT进行作用的。
下面继续阐述这些组件各自的作用：
UVM Scoreboard的作用就是check。首先实现一个参考模型输出期望数据，然后将这个期望数据和DUT输出的实际数据进行比对，所以Scroreboard决定了我们参考模型的准确度、数据比对的完备性。
UVM Agent 体现面向对象编程良好的封装特征，将处理相同事务的各个组件捆绑在一起使用。
UVM Sequencer控制输入激励的发送，在行为上类似一个仲裁器或者管道。管道中流通的内容就是输入激励，即UVM Sequence。UVM Sequence属于动态的内容，从DUT的输入到输出期间就是其生命周期。
UVM Driver 和UVM Monitor是永远的翻译者，它们不生产内容，只做内容的二次转换。****UVM Driver将工程师方便控制的事务级激励转换成DUT能够识别的接口级或者信号级激励，在施加输入激励的同时可以增加更多的随机性，以覆盖更多的可能发生的应用场景。UVM Monitor相反，它的功能就是将DUT接口级或者信号级的输出转换成容易理解的事务级数据，即前面提到的实际数据，和期望数据进行比对。
到此，整个基本的验证回路就闭环了。
作者： Xin\_Xin\_Hu
原文链接：https://mp.weixin.qq.com/s/YMncPaW41UrvBE75f4FZag
授权转自数字芯片实验室公众号，请勿二次转载。
推荐阅读
更多数字IC设计技术干货等请关注数字芯片实验室专栏。
