Hi,
can i have 2 instantiations of a single monitor in an agent.the interfaces connected to each monitors are different. now, i created 2 classes, in_monitor and out_monitor. it looks like i am writing extra lines of code.please tell how to make code as reusable like 2 instantiations makes it done?
In reply to roopatoms:
The UVM does not restrict the usage of monitors in an agent. But you should ask why do I need 2 agents, because 1 would be enough.
You are writing the monitors are connected to different interfaces. Is this really correct? If this is true it is highly recomended 2 agents, a passive and an active one.
In reply to chr_sue:
i thought if we need more agents of this type, we can simply instantiate it.
if we use 2 agents, one passive and other active, again 2 monitor lines of code will be coming,am i right ?
In reply to chr_sue:
I concur. There is hardly a situation where a single agent (which is invariably tied to only one interface), would require 2 monitors. If there are checks required, they could be done in the scoreboard.
I am having a similar question and I do not see other solution other than creating two monitors, whether they are in one agent or in different agents (e.g. in_agent, out_agent). However, at the same time, I feel like I am creating duplicate code, as the in/out interface is almost the same.
So,I guess the point here is what you guys call an independent interface. Imagine I have a DUT which is a SERDES, made out of a TX and RX in a back to back configuration. Basically the interface is almost the same (parallel data in/out, start_tx/rx_ready signal), but I believe I need two different implementations of the monitor to account for the (slight) different timing between the start_tx and ready_rx signals and its associate data sampling? Would this qualify as independent interfaces?
Thanks
In reply to kiteloop:
why don’t u use one monitor and you can specify the number of analysis ports you need. Just extend your monitor class from component so you can have all the analysis ports needed.
In reply to qais:
In reply to kiteloop:
why don’t u use one monitor and you can specify the number of analysis ports you need. Just extend your monitor class from component so you can have all the analysis ports needed.
uvm_monitor doesn’t implement any analysis ports anyway, it just extends from uvm_component.
But the problem is not about the analysis ports. It’s about what is the best practice with respect to monitoring the input and output bus of a very similar interface, and how to implement the most ‘UVM-friendly’ solution.
In reply to kiteloop:
after you capture the dut values you need to broadcast them hence the analysis ports.
In reply to roopatoms:
I think you can have 2 monitors, but…
likewise you can also have 2 drivers in the same agent, again but…
So the UVM way 1 agent - 1 monitor, 1 driver and 1 sequencer. Thats it
If you need to have 2 monitors, than either you should use 2 agents, or you dont need to have 2 monitors i.e. you need to change your logic.
In reply to haykp:
What I see from my perspective as a UVM Coach is, that some companies/people are recommending to have one monitor for all inputs to the DUT and another monitor for all outputs from the DUT. I think kthis is not an adequate solution and complicates things which can be made easy having only one monitor.
In reply to chr_sue:
Thanks chr_sue. That’s what I meant. But how to have only one monitor for the input and output sides of the DUT if the implementation has to be coded differently? This is, even if interface is the same on the output side, protocol might be different on each side of the DUT, so I do not see how I can create a generic monitor for this.
Can you kindly point me to some example?
Thanks
In reply to kiteloop:
An interface protocol covers both data directions, input and output. It says if you have certain inputs you will expect corresponding inputs.
To give an example.
You want to write/read a memory.
For the WR your input data are the direction = WR, addr and data. All these are inputs.
For a RD you have the direction = RD and the addr as inputs. And you expect a certain number of clock cycles later the data. Data is an output. If you have one monitor for the inputs and another one for the outputs you cannot model this behavior. See below the run_phase of an APB monitor:
task apb_monitor::run_phase(uvm_phase phase);
apb_seq_item item;
apb_seq_item cloned_item;
item = apb_seq_item::type_id::create("item");
forever begin
// Detect the protocol event on the TBAI virtual interface
@(posedge APB.PCLK);
if(APB.PREADY && APB.PSEL[apb_index])
// Assign the relevant values to the analysis item fields
begin
item.addr = APB.PADDR;
item.we = APB.PWRITE;
if(APB.PWRITE)
begin
item.data = APB.PWDATA;
end
else
begin
item.data = APB.PRDATA;
end
// Clone and publish the cloned item to the subscribers
$cast(cloned_item, item.clone());
ap.write(cloned_item);
end
end
endtask: run_phase
In reply to chr_sue:
Thanks for the example chr_sue
Yes, in that scenario the use of one interface is clear to me. However my scenario is that I have a DUT(s) which process stuff in a pipelined fashion. I.e. in one side there is data in, at the other side data comes out. The input and output side is almost the same except for some load and data_ready signals. Concretely, it is a SERDES system, where TX and RX DUTs are connected back to back. Hence the question of whether of using one or two interfaces here, as it is almost the same interface however each side actually belongs to different DUTs
In reply to kiteloop:
Pipelining is not an issue. This works fine with UVM.
I’m not so familiar with the SERDES protocol. Is my understanding right the TX side is active, driving data in and the RX side is passive observing data and do not drive data?
In reply to chr_sue:
In reply to kiteloop:
Is my understanding right the TX side is active, driving data in and the RX side is passive observing data and do not drive data?
That is correct
In reply to kiteloop:
What you are feeding in on TX comes out on RX, right.
But you do not know the order. I mean you have different TX data, some are going fast through the DUT others slower. But there should be indications when evaluating the RX data.
Is the behavior pipelined or out-of order?
Can you please answer tese questions.
In reply to chr_sue:
Yes, what I feed to the TX comes out on the RX
I also know the order. For each data that comes out I know the data it should match. Behaviour is pipelined.
In reply to kiteloop:
There is nothing special which requires 2 monitors. Then my question is why do you believe you need 2 monitors?