uvm_analysis_imp#()::get would be nice

[Logger]

It would be really nice to be able to receive TLM messages in some sequences for the purposes of coordinating stimulus with monitored events.

 

I have a solution which gets the job done, but it's not as clean as it should be, and this missing feature feels like a gaping hole in the methodology.

 

I think a very nice solution would be to have uvm_analysis_imp#() class either implement the get() method, or maybe more clearly have a new method called wait_for_write( T t ).

 

You could then extend your sequencer to have a uvm_analysis_imp#(), and use `uvm_declare_p_sequencer() in your sequence to provide access to the analysis port.  Here's a partial example of what the user code would look like:

class ItemSqr extends uvm_sequencer#( Item );
    uvm_analysis_imp#( OtherItem ) other_item_analysis_export;
    // .. rest of class definition
endclass


class TestSeq extends uvm_sequence#( Item );
    `uvm_object_utils( TestSeq )
    `uvm_declare_p_sequencer( ItemSqr )
  
    // ....

    virtual task body( );
        OtherItem t;
        // .. do some transactions
        p_sequencer.other_item_analysis_export.wait_for_write( t );
        // .. do some more transactions
    endtask


endclass

I basically implement this now, but UVM should do it for me.

 

-Ryan

 

[bhunter1972]

This isn't a solution to a glaring problem:  it's standard operating procedure. If you want your sequences to receive events or access other information from the component hierarchy, this is what you do.

 

However, the way you wrote it isn't entirely clear. I tend to plop a uvm_tlm_analysis_fifo in the sequencer and have the sequence pull from that. Or, I'll implement the write in the sequencer and put the data item in something like a mailbox that the sequence can access.

 

The downside to this practice is that these sequences cannot just run on any ol' sequencer--once you declare the p_sequencer, that's the only one they can run on. It so happens that that is what I want most of the time, but some UVM purists may whince at the notion.

 

Sequences can't have TLM imps or exports because they are not components. They can be created and destroyed throughout the life of the sim and so cannot have these quasi-static elements inside them. The declaration of the p_sequencer roots them into the component hierarchy.

[Logger]

But that's the problem, this "standard operating procedure" is not a documented procedure, nor is it a single procedure.  No two people do it the same way, and good luck finding an example when you google or search the UVM forums.  You'll mostly likely come across someone raising the question, but it's never answered.

 

So is there no canned solution, because we haven't yet agreed on how this should be implemented in the general case?  Or is it just one of those things that UVM hasn't gotten around to yet?

 

[tudor.timi]

Another point: the way I interpret TLM (and someone please correct me if I'm wrong) is that a port is basically a stand-in for an actual object that implements the interface of that port. For example, an analysis port has only a write(...) method, this means it will connect (though exports and imports) to a component that implements a compatible write(...) function. By calling write(...) on the analysis port, you are effectively calling write(...) on the end-point component. You couldn't have a get(...) inside your component do what you want to do, for two reasons. First it's an export and you can't call methods on exports (as the flow of method calls in TLM1 is uni-directional). Second, even if you could, this would mean that you would be calling get(...) on the component connect on the other side.

 

The way bhunter suggested it (using the analysis FIFO) is the way I've implemented it in the past as well and I would consider it pretty standard TLM. I guess it's not documented in UVM as an example because it's a more "exotic" use case. With respect to finding the question and not the answer on Google or on forums, I do think that there has been more participation lately w.r.t. to how to do stuff in UVM, because it's gotten wider adoption. Don't forget to try StackOverflow as well when you have SV questions, as that site is also pretty active.