Filter uvm_info statements in the monitor by interface

UVM
, ,
1

I am in the situation were i have a significant amount of interfaces (+60) of the same type.

I would like to see the output of specific monitors. Now i have plenty of UVM debug statements in my monitors, but with lots of monitors this is very difficult to filter.
At the moment i have added the virtual interface handle to the uvm_info calls (see below) and then i will grep my log files


	`uvm_info("MONITOR", $sformatf("[%p]WR Data %0d of %0d ", vif,capture_count,collected_transfer.burstLen), UVM_HIGH)

Can anyone advise a better way of doing this? I wish i could shorten the vif because the hierarchy looks awful in the log files.

Thanks

2

In reply to Phill_Ferg:

Hi Phill,

Best Way is to filter UVM Message is to have unique Message ID.

you could try such implementation

`uvm_info("MONITOR:Filtername", $sformatf("[%p]WR Data %0d of %0d ", vif,capture_count,collected_transfer.burstLen), UVM_HIGH)

you will get “[MONITOR:Filtername]” this pattern in log and then its easy to grep for this id. I hope this is what you are looking for.

Regards,
Vinay Jain

3

In reply to Vinay Jain:

Vinay,

thanks for the response, i understand what you mean. However when i write the code i won’t know what i want to filter.
All i know is that i would like to look at the uvm_info statements from a particular monitor instance, when i see things going wrong in the scoreboard.

How do i trace this instance and put it in my uvm_info statements? I am needing something unique per instance , a number or an interface.

I remember noticing an agent id field in template code - but never paid any attention to this - perhaps i should be look for fields inherited from uvm_monitor.

4

In reply to Phill_Ferg:

Hi Phil,
How about assigning a unique string for each monitor from environment and add that string variable in info .

5

In reply to kavin:

Thanks kavin, i’ve kind of done this, but using the vif instead of a unique id. It is a lot more useful, but is a bit verbose on the transcript window.
I was hoping that there was an in-built uvm_compoment field that might help here.

Sadly my agents only have scope of their configuration, so i guess i could put in a associative array along with the vifs, but this just seems overkill

6

You could make the ID field of the monitor based on the name or full_name of the monitor and filter on that. That’s kind of what the ID field was intended for.

7

In reply to tfitz:

Am i right in saying the ID field is a user defined field, so i would have to populate it from the the agent?

At present i have a testbench level config that pulls the virtual interface from the config_db. This then creates uvc based configs and passes the vif handles down. At some stage i will specific how many agents of a particular type i have and align them to a vif. At this stage i have an “id” that i can pass to the monitor.
I am happy with this approach, but i just wanted to make sure i wasn’t missing anything embedded in uvm_component that may help me in the same way.

I like neat transcript windows and greping on "MONITOR.[/top/interface_name]" is not pleasant, "MONITOR.[vif0] would be lovely.

8

In reply to Phill_Ferg:

The ID field is user-defined. It doesn’t need to be populated from the agent. It’s just a string, so you could define it inside the agent. You’d probably want to define it once up-front (like in build_phase() or end_of_elaboration_phase()), and you can base it off either the monitor’s name/full_name, or any other information you may get from the config_db. You could easily write a function that returns the “vif0” part of the interface name and use that.

9

In reply to Phill_Ferg:

Hello Phill ,
why would a string variable in monitor would affect anything(i meant your configs). In environment either build phase or connect phase make monitor IDs(string value for each monitor instance), since you are naming it , greping also will be easy .

This is what tfitz idea too .

10

In reply to kavin:

Kavin

I agree - my initial point was to check i wasn’t missing anything obvious.

My configs at the UVC level contain the number of agents, their configs which include the vif to assign to a particular agent.
There are a few options:

  1. write an ID fields in the monitor from the agent based on the virtual interface name of array location.
  2. write a function in the monitor to parse extract the virtual interface name.

I’ll probably go with point one to keep the code simple.

Thanks

11

In reply to tfitz:

Thanks Tom,

as mentioned above:

My configs at the UVC level contain the number of agents, an array of their configs which include the vif to assign to a particular agent.

I am most likely to write the ID field in the monitor from the agent based on the array index which holds the config for that particular agent.

Thanks :)

12

In reply to Phill_Ferg:

However you are getting the information into the monitor is fine. We recommend using a configuration object to hold all information for a particular component so you only have to do one config_db::set/get per component. As you pass in the specific vif instance in the config object, you can also include a separate field that holds the ID key. Then, you can make your monitor’s ID something like

{"MONITOR", config_obj.key}

where ‘key’ could either be a string set by the agent or an int which you convert to a string via $sformat.

13

In reply to tfitz:

Thanks Tom, i have configs for each agent so its an easy change to set id’s now in configs.
I am really enjoying this aspect of SystemVerilog/UVM - as the complexity increases there is always something new to discover in the methodology and capability in the language