How to monitor verilog module internal signal through uvm testbench

UVM
1

i want to monitor status of one signal called rf_count from one of my verilog module in my code through uvm testbench.

2

See my DVCon paper The Missing Link: The Testbench to DUT Connection

3

In reply to dave_59:

thanx, it really helped me

4

In reply to dave_59:

See my DVCon paper The Missing Link: The Testbench to DUT Connection

Hi,

Really that was helpful for my current scenario,where I need to tap the RTL signal.But, while implementing the code with reference to the paper,I ended up with the following error with the VCS tool:
Error-[BPRHS] Bad RHS expression of parameter
-I-:/rtl_probe_if.sv, 9
-I-:“PATH”
-I-: The RHS expression of the parameter could not be evaluated.
-I-: localparam string PATH = $psprintf(“%m”);
-I-: Please check for undeclared variables, nets, parameters with unknown values,
-I-: hierachical references or illegal operators.

How I can get rid of this issue.Also,why you are using the create_object_by_name instead of the available UVM macros.

Thanks in advance :)

5

In reply to ajithomas003:

Could you please show some more details on the file rtl_probe_if.sv, especially line 9.

6

In reply to chr_sue:

//RTL Probe Interface  to be bind inside the dut
interface rtl_probe_if #(int WIDTH)(inout wire [WIDTH-1:0] shift_data);
  import uvm_pkg::*;
  `include "uvm_macros.svh"

  typedef logic [WIDTH-1:0] T;

  import rtl_probe_pkg::*;
  localparam string PATH = $psprintf("%m");
  
  //Implementation of Abstract Class
  class rtl_probe extends rtl_probe_abstract #(T);
  
    function new (string name = "");
      super.new(name);
    endfunction

    typedef uvm_object_registry #(rtl_probe,{"probe_",PATH}) type_id;
    static function type_id get_type();
      return type_id::get();
    endfunction

    function T get_rtl_probe();
      return shift_data;
    endfunction

  endclass

endinterface
//Binding in the top level module is as follows
bind fetch_engine : dut.inst_fetch_engine rtl_probe_if #(32) b1(shift_data);

yeah sure.
I’m following the same piece of code in the reference paper to tap the RTL signal.

7

In reply to ajithomas003:

I guess this line makes trouble:

 typedef uvm_object_registry #(rtl_probe,{"probe_",PATH}) type_id;

I have only a pdf from DAves article and I do not see there this line of code.
My virus program is blocking the link Dave was sending.

8

In reply to chr_sue:

Yeah.it has defined inside the interface in the sample code mentioned in Appendix-A.
Throughout in the code it is mainly taking the use of uvm_object_registry.Is there any advantage for this over the uvm macros?

The Missing Link: The Testbench to DUT
Connection

Thanks,
Aji

9

In reply to ajithomas003:

The problem with the UVM macros is that they can create unique string names for specializations of parameterized classes and also places where classes (See Parameterized Classes, Static Members and the Factory Macros - Verification Horizons). If you can guarantee there is only on specialization of the class, then you can use the macro.

When classes are declared inside a module/interface, you run into another problem that you can’t access the class type from outside the module. So if there are multiple instances, you need to come up with a unique string for accessing the factory override.

You could get around your problem by using the config_db instead, but that will be a few more steps.