UVM中的6个关键机制
时间：2021-11-12 14:14:55
手机看文章
扫描二维码
随时随地手机看文章
[导读]UVM内建了许多关键的处理机制，帮助实现验证工程师需要的功能。a.Factory机制Factory机制是产生通用代码的一种典型的软件设计思路。在功能验证中，引入的类经常需要变化。例如，在许多测试中我们可能需要给事务增加更多的约束或字段，或者想在整个环境中或仅仅一个单接口中使用新的...
UVM 内建了许多关键的处理机制，帮助实现验证工程师需要的功能。
a. Factory 机制
Factory机制是产生通用代码的一种典型的软件设计思路。在功能验证中，引入的类经常需要变化。例如，在许多测试中我们可能需要给事务增加更多的约束或字段，或者想在整个环境中或仅仅一个单接口中使用新的派生类。UVM 提供了一个内建的工厂机制，促进环境重用和调整预定义的验证 IP。工厂机制最大的优点之一是，其对于测试人员简单、透明， 并且减少了开发者和用户对面向对象知识的需求。
我的理解就是利用 factory 机制，我们可以方便快捷地更换验证环境中的任何一个组件。
b. Phase 机制
UVM 将 testbench 建立、仿真启动到最后仿真结束分为不同的阶段，各个阶段称为不同的phase。在正式运行仿真的阶段称之为run_phase，在 run_phase 之前有 build_phase、connect_phase 等，在run_phase 之后有 check_phase、report_phase等。各个 phase 都有自己需要完成的动作。
UVM 中的 phase 根据是否消耗仿真时间分为 task phase 和 function phase。只有 run_phase 是 task phase。
在 UVM1.0 时代， run_phase 是其中唯一的一个 task_phase。当 UVM 进化到1.1 版 本 后，又 增 加 了 configure_phase、pre_main_phase、main_phase、post_main_phase 等 12 个 task_phase,同时为了兼容以前的 1.0 版本保留了
run_phase。这 12 个 phase 共同实现了 run_phase 的功能，通过这 12 个 task_phase可以实现对仿真过程更精细化的控制。
phase 的执行是有先后顺序的，是按照整个 testbench 的建立顺序依次执行。
对于 task_phase 来说， UVM 中不同 component 的同一个 phase 的执行顺序是并行执行。UVM1.1 应用指南及源码分析中有提到是“自上而下启动，并行运行”。
c. Field_automation 机制
Field_automation 机制用于产生 transaction。使用该机制，我们能够很方便的用 transaction 的成员函数，比如 print()、compare()（这个在 scoreboard 用的比较多）、pack()（这个函数在 driver 用的比较多）、unpack()（这个在 monitor 用的比较多）等等，简化了很多工作。
d. Sequence 机制
sequence 机制不能不说是 UVM 的一大创新， sequence 使得激励的产生和驱动相互分离，我们通过定义不同的 sequence 来使得 testbench 代码可重用，增加了激励产生的灵活性。
引入 sequence 之后，在不同的 case 中将不同的 sequence设置成 sequencer 中 main_phase 的 default_sequence，这样就完成了不同激励的加
载。同时 sequence 能够通过 starting_phase 来控制验证平台的开启。
e. Config 机制
Config 机制用于在整个验证环境中传递变量，通过 config 机制，可以在验证平台的顶层设置任何一个 component 或者某些指定 component 中的参数。在验证平台中 driver和 monitor 的虚接口和实体接口的连接就是通过 config 机制实现的。
f. Callback 机制
Callback 机制也是为了提高验证平台的可重用性，其原理类似于 phase 机制，但是不同于 phase 机制的是，其仅仅提供了 callback 的接口函数，函数中全部为空，需要开发者自己去填写，通过对 callback 接口函数中填充不同的内容，来适应不同测试的需求。
比如我们要计算 mac 帧的 crc 校验值，那么只能等到 transaction 中的除了 crc之 外 的 其 他 值 全 部 固 定 (randomize) 之 后 才 能 计 算 ， 这 个 计 算 可 以 通 过post_randomize()函数来完成，这个函数就是一个 callback 函数。
a. Factory 机制
Factory机制是产生通用代码的一种典型的软件设计思路。在功能验证中，引入的类经常需要变化。例如，在许多测试中我们可能需要给事务增加更多的约束或字段，或者想在整个环境中或仅仅一个单接口中使用新的派生类。UVM 提供了一个内建的工厂机制，促进环境重用和调整预定义的验证 IP。工厂机制最大的优点之一是，其对于测试人员简单、透明， 并且减少了开发者和用户对面向对象知识的需求。
我的理解就是利用 factory 机制，我们可以方便快捷地更换验证环境中的任何一个组件。
b. Phase 机制
UVM 将 testbench 建立、仿真启动到最后仿真结束分为不同的阶段，各个阶段称为不同的phase。在正式运行仿真的阶段称之为run_phase，在 run_phase 之前有 build_phase、connect_phase 等，在run_phase 之后有 check_phase、report_phase等。各个 phase 都有自己需要完成的动作。
UVM 中的 phase 根据是否消耗仿真时间分为 task phase 和 function phase。只有 run_phase 是 task phase。
在 UVM1.0 时代， run_phase 是其中唯一的一个 task_phase。当 UVM 进化到1.1 版 本 后，又 增 加 了 configure_phase、pre_main_phase、main_phase、post_main_phase 等 12 个 task_phase,同时为了兼容以前的 1.0 版本保留了
run_phase。这 12 个 phase 共同实现了 run_phase 的功能，通过这 12 个 task_phase可以实现对仿真过程更精细化的控制。
phase 的执行是有先后顺序的，是按照整个 testbench 的建立顺序依次执行。
对于 task_phase 来说， UVM 中不同 component 的同一个 phase 的执行顺序是并行执行。UVM1.1 应用指南及源码分析中有提到是“自上而下启动，并行运行”。
c. Field_automation 机制
Field_automation 机制用于产生 transaction。使用该机制，我们能够很方便的用 transaction 的成员函数，比如 print()、compare()（这个在 scoreboard 用的比较多）、pack()（这个函数在 driver 用的比较多）、unpack()（这个在 monitor 用的比较多）等等，简化了很多工作。
d. Sequence 机制
sequence 机制不能不说是 UVM 的一大创新， sequence 使得激励的产生和驱动相互分离，我们通过定义不同的 sequence 来使得 testbench 代码可重用，增加了激励产生的灵活性。
引入 sequence 之后，在不同的 case 中将不同的 sequence设置成 sequencer 中 main_phase 的 default_sequence，这样就完成了不同激励的加
载。同时 sequence 能够通过 starting_phase 来控制验证平台的开启。
e. Config 机制
Config 机制用于在整个验证环境中传递变量，通过 config 机制，可以在验证平台的顶层设置任何一个 component 或者某些指定 component 中的参数。在验证平台中 driver和 monitor 的虚接口和实体接口的连接就是通过 config 机制实现的。
f. Callback 机制
Callback 机制也是为了提高验证平台的可重用性，其原理类似于 phase 机制，但是不同于 phase 机制的是，其仅仅提供了 callback 的接口函数，函数中全部为空，需要开发者自己去填写，通过对 callback 接口函数中填充不同的内容，来适应不同测试的需求。
比如我们要计算 mac 帧的 crc 校验值，那么只能等到 transaction 中的除了 crc之 外 的 其 他 值 全 部 固 定 (randomize) 之 后 才 能 计 算 ， 这 个 计 算 可 以 通 过post_randomize()函数来完成，这个函数就是一个 callback 函数。
下载文档
