I am new to uvm.
I have an agent with an analysis port.
I need to connect this agent to a scoreboard.
The scoreboard has a fifo.
So ultimately, the analysis port of agent needs to be connected to the fifo of scoreboard.
I had used uvm_analysis_export in scoreboard and connected this export to fifo in scoreboard’s connect_phase.
Then I connected the uvm_analysis_port of the agent to the scoreboard’s export in the agents’ connect_phase.
But it looks like the transaction dint get into fifo.
fifo.size() always gives out zero.
Do I need to implement any write function other than this?
I thought that the connection would automatically pass on the transaction.
Could anyone help me fix this?
I would like to add that the agent I used is an mvc_agent from “Questa verification IP”.
So I expect the transaction to come out of the agents’ analysis_port, provided that the sequence is correctly driven into the mvc_agent’s sequencer.
The connection from analysis port to analysis fifo is very straight forward.
Make the following connections in your test_env or system env
→
my_env.agent[0].monitor.analysis_port_instance.connect(scoreboard.my_fifo.analysis_export)
→
analysis export is not required for connecting an analysis_port to analysis_fifo.
you will have to implement function in the scoreboard only if have used uvm_analysis_imp. ie only if trying to connect analysis_port to analysis_implementation.
if you are still unable to get the transaction in the scoreboard then put some displays in the agent where you are trying to publish the transaction to check if transaction is infact being published on the analysis port.
It is not good to use mailboxes here as mailboxes facilitate one-to-one communication where as
analysis ports are one-to-many. Analysis port can have more than one subscriber for eg. a scoreboard, a checker etc. can be the subscribers to the transactions published from a monitor. But this cannot be facilitated using mailboxes without have a mailbox for each subscriber.
appears like some of the ports in ptp_sc do not have any connections. OVM/UVM mandates that every port must be connected to an implementation port. Every port has a min and max number of connections that can be connected to it. Check if all ports and export within “ptp_sc” are connected.
The uvm_analysis_fifo implements the write() function, which is required in order to connect to an analysis_port. You did the right thing in connecting your fifo to the scoreboard’s analysis_export and then connecting the monitor’s analysis_port to the scoreboard’s export. It sounds like you didn’t use the analysis_fifo but instead created something of your own that didn’t have a write() method. That’s just a guess.
If following the guidelines in the Cookbook page don’t work, please let us know.
Good luck,
Tom
Thanks for the reply.
Looks like my scoreboard is well connected to the agent’s analysis port.
I doubt if the agent actually publishes the transaction.
Im using an mvc_agent which has an inbuilt sequencer, driver and a monitor.
My sequence passes on from driver to DUT. So I am sure that the agent drives the sequence.
I doubt if the sequence comes out of the monitor’s analysis_port.
I have just created the agent in the build_phase of my environment.
Then I have connected the agent’s analysis_port to the scoreboard’s analysis_export in the connect_phase of my environment.
Could anyone familiar with Questa MVC tell me if this connection is sufficient.
Could there be any reason for the transaction being not collected by the monitor?
Could anyone throw me some light on this?
Even though the cookbook recommends implementing export to export(export of fifo) connection in the scoreboard, I am pretty sure that is unnecessary. the uvm_analysis_fifo has an export to which an analysis fifo can connect to. You can probably try an example where the analysis port in your agent connects directly to the export of the fifo. Just make sure that you dont any unconnected exports in you component.
For reuse purposes, please keep the connection between the agent and the scoreboard’s analysis_export. Do not connect to the embedded analysis_fifo directly.
As a debug exercise, create a simple uvm_subscriber #(your_transaction_type) and have the write() method issue a `uvm_info that will print a message that the transaction was received and use this in place of your scoreboard. That way you’ll be able to tell if the transaction is actually getting out of the mvc_agent.
You could actually put a breakpoint on the write() method calls, but it’s a little harder to explain how to do that in a forum like this.
Thanks for your reply.
I am new to uvm and I have a basic doubt with this subscriber.
Where does the call to write() method occur? Is it implicitly called or we should call explicitly?
I just went through the source code of uvm_subscriber but could not reason out this and hence I am posting this here.
This was the subscriber that I used.
class p_subscriber extends uvm_subscriber #(mvc_sequence_item_base);
`uvm_component_utils (p_subscriber)
function new(string name, uvm_component parent);
super.new(name,parent);
endfunction
function void write( mvc_sequence_item_base t);
$display("%m Inside write");
endfunction
endclass
And in the connect_phase of my env I have this connection
where p_sub is the instance of p_subscriber.
With this done, I ran the simulation for a sufficiently long time and could not find the display statement inside write() task being displayed.
I think the answer to the question asked in the beginning would answer this also.
If the call to write() is implicit, when does the call to write() occur? Then does this indicate the transaction is not sent out by the agent?
The write() call actually happens in the agent’s monitor. Through the magic of TLM (via the connect() call), it winds up calling the write() method of the subscriber/scoreboard. If your subscriber’s write() method isn’t getting called, then the agent/monitor isn’t making the call in the first place, since your connections seem to be OK. I think it’s time to contact your normal support channel.
-Tom
PS. I’d recommend not using the type name “p_sequencer” since that’s actually used as a variable name internally in sequences in some cases. It’s not the cause of your problem here, just something to be aware of.