uvm

I have a UVM testbench for a small block in my chip. In this there is an agent with a driver that drives data on a virtual interface which looks something like this: interface my_if (input bit clk); logic [3:0] opcode; // Clocking block for the driver clocking drvClk @(posedge clk); output opcode; endclocking // Clocking block for the monitor clocking monClk @(posedge clk); input opcode; endclocking endinterface I use this interface in my driver like this: class my_driver extends uvm_driver #(my_tr); my_if vif; ... virtual task run_phase(uvm_phase phase); super.run_phase(phase); forever begin

UVM(universal verification method)作为通用验证方法学，解决了什么问题？ 验证平台的规范化 验证环境包括激励输入和输出数据的比对。UVM将激励、比对、reference model分别实现为不同的类。在子IP验证环境中使用的组件，可以在IP验证环境中复用。 对System Verilog的封装 System Verilog引入了类似C++，java的语法，可以实现为类。类给我们带来的好处就是封装、继承、多态。 展开说一下， UVM 环境 UVM的整体环境封装在uvm_env中，这可以看作是与真正实例化module的tb同级的环境。 UVM Sequence UVM Sequence是负责发送transaction包的激励来源。 比如axi总线的一个transaction，在真正的verilog中，是按照clock的一拍一拍的数据和地址，在UVM中，可以定义一个uvm_sequence_item，将这一整包的数据和地址封装为成员为int address， int data[]的类；sequence就是负责产生各种各样的transaction。 注意： 1）并不是验证环境中只有一个sequence，而是可能会存在多个sequence。 比如存在以下三种sequence： 专门发送长包的sequence 专门发送短包的sequence

当我们在Agent中创建jelly_bean_driver时，我们编写了build_phase函数和run_phase任务，但是实际调用它们的人是谁？答案是uvm_phase类。 UVM Phases UVM有九个常见的phase类别（以黄色显示）和十二个运行时间phase类别（以粉色显示）。这些phase类是从uvm_topdown_phase，uvm_bottomup_phase或uvm_task_phase类派生的，而uvm_task_phase类又是从uvm_phase类派生的。 uvm_phase类有一个名为exec_func的虚函数和一个名为exec_task的虚任务。从uvm_topdown_phase和uvm_bottomup_phase派生的phase类实现了exec_func，而从uvm_task_phase派生的phase类实现了exec_task。如图所示，每个phase类都会调用uvm_component的相应函数或任务。例如，uvm_build_phase类的exec_func调用uvm_component的build_phase函数，并且uvm_run_phase类的exec_task调用uvm_component的run_phase任务等。 Simplified Flow UVM phase实施的方式相当复杂，但这里是一个简化的流程。 我们调用run

jelly beans ; 一个流是用于“期望的” jelly beans ，另一个是用于“实际的” jelly beans 。 同时假设 jelly beans 被异步喂入记分板。 为了同步 jelly beans ，我使用了两个analysis FIFO： jelly bean计分板 这是实现上述记分牌的示例代码。下面的代码应该是不言自明的。需要注意的是，获取FIFO的下一个项目的方法是阻塞任务（第43和44行）。不过，不管怎样，这个任务在UVM类参考文献中没有记录。 2015年2月14日：更改为明确使用get_peek_export，而不是使用未记录的获取任务。 当期望的 jelly bean 和实际的 jelly bean 都可用时，记分板将它们比较（第45行）。在完成仿真（extract_phase）之前，计分板将检查FIFO中是否有任何存在残留的 jelly bean 。这不容易吗？ class asynchronous_jelly_bean_scoreboard extends uvm_component; `uvm_component_utils( asynchronous_jelly_bean_scoreboard ) uvm_analysis_export #( jelly_bean_transaction ) expected_analysis_export;

I want to create a clock in my top level testbench whose period can be controlled from the test. What I did was set the period into the uvm_config_db and get it back in the testbench. I had to put in a #1 to make sure that the build phase was finished, otherwise the get returned the wrong value: module testbench_top; int clk_period; bit clk = 0; initial begin #1; void'(uvm_config_db #(int) ::get(null, "uvm_test_top.env", "clk_period", clk_period)); // Create clk forever begin #(clk_period/2) clk = !clk; end end I am annoyed by the #1. Is there a better way to check that the config has been set

uvm_objection 和 uvm_component基础 　　 　　uvm_objection 和 uvm_component 是 uvm 中两大基础类，刚开始学习的时候，对两个东西认识不深，以为它们俩差不多，谁知道它两是一个是“爷爷”，一个是孙子的关系，两者贯穿整个 uvm 验证方法学。至于为什么要划分 uvm_object 和 uvm_component 呢，是因为前任在验证的过程中发现，对事情进行分工能降低复杂度，也能提高维护效率。 uvm_object 在 uvm 中的地方比较基础，如果按照 OPP 的思想，它是一个最基础（ base ）没有太多的物理含义，而 uvm_component 是高层次抽象后的，具有物理含义，更像一个“对象”，例如我们前面谈到的 driver or montIor 它们都有自己的意义和功能。 如下图所示，先来整体看一下， uvm 方法学中核心的几个自带类型： uvm_void ：是是始祖类，人如其名，其中不包含任何函数和类 uvm_obect : 比较基础的类，包含一些比较基础的常用函数，如 Copy 函数、 Clone 函数、 Compare 函数、 Print 函数 uvm_component：uvm 组件类，继承于该类的子类，用于构成 UVM 环境（ uvm_tree ），如在系列（一）中已经涉及过的 uvm_driver、uvm

What functions do I need to call to use Regular Expressions in Systemverilog/UVM? Note: I'm not asking how to use regular expressions, just method names. First, if you want to use regular expression, you'll need to make sure you're using a UVM library compiled together with its DPI code (i.e. the UVM_NO_DPI define isn't set). The methods you want to use are located in dpi/uvm_regex.svh . The main function is uvm_re_match(...) , which takes as an argument a regular expression and the string to match against. This is basically a wrapper around the regexec(...) C function found in the regex.h

objection机制用来控制验证平台的关闭。phase和objection与UVM验证平台息息相关，phase恰如铁轨，让UVM这趟列车在铁轨上向前运行，不会脱轨，不会跳过某一段而直接到达后一段，objection则更像是能量，给列车提供能量，控制着这趟列车的起始和终止。 在一个实际的验证平台中，通常会在以下两种objection的控制策略中选择一种： 第一种是在scoreboard中进行控制。通过config_db::set的方式设置收集到的transaction的数量pkt_num，当收集到足够数量的transaction后跳出循环。采用fork…join_any语句，一方面收集预期transaction，另一方面收集实际transaction。 第二种是在sequence中提起sequencer的objection，当sequence完成后，再撤销此objection。 以上两种方式在验证平台中都有应用，其中第二种用得最多，这种方式是UVM提倡的方式。UVM的设计哲学就是全部由sequence来控制激励的生成，因此一般情况下只在sequence中控制objection。 来源： https://blog.csdn.net/W1Z1Q/article/details/100996900

UVM提供uvm_barrier对多个组件进行同步协调，同时为了解决组件独立运作的封闭性需要，定义了新的类uvm_barrier_pool来全局管理uvm_barrier对象。 uvm_barrier 可以设置一定的等待阈值，仅在有不少于该阈值的进程在等待该对象时才会触发该事件，同时激活所有正在等待的进程，使其基础进行。 wait_for Waits for enough processes to reach the barrier before continuing. reset Resets the barrier. set_auto_reset Determines if the barrier should reset itself after the threshold is reached. set_thresh_hold Sets the process threshold. get_thresh_hold Gets the current threshold setting for the barrier. get_num_waiters Returns the number of processes currently waiting at the barrier. cancel Decrements the waiter counter by one.