Phase control of distributed UVC's

[AgentSmith_l]

For my application, various UVM components are instantiated at various levels in the DUT using Binding Method.

Hence these components are distributed at various levels and in different places in the DUT.

I am assuming that UVM would be suitable for this application. Alternative suggestions are welcome.

I have the following queries:

1)Will all these components be elaborated under the same uvm_root?

1a) If yes, then any specific things I should keep in mind?

1b) If not, Is haveing multiple uvm_roots in a simulation legal?

1bi) If No then is there a workarround?

1bii) If yes then how do I control the phases of these components since more than one run_test is not legal?

Edited November 11, 2011 by AgentSmith_l

[Erling]

1)Will all these components be elaborated under the same uvm_root?

Yes. Think about a bound component as any other component with direct dut signal access. There can be as many as you like, it is just more of the same. The sample code at http://www.uvmworld.org/forums/showthread.php?409-Still-Having-Problem-With-Bind-for-VHDL-Architecture-Signals shows one way to deal with this.

Erling

[uwes]

hi,

>1)Will all these components be elaborated under the same uvm_root?

i think you mix some things:

1. the scope there the component is created (and who has references to it)

2. the notion of the logical path

3. uvm_root

-

for uvm_root documentation:

// Implicit top-level - The ~uvm_top~ serves as an implicit top-level component.

// Any component whose parent is specified as NULL becomes a child of ~uvm_top~.

// Thus, all UVM components in simulation are descendants of ~uvm_top~.

so where you instantiate your component (scope) doesnt matter. what matters are the name argument and the parent reference. this means for Q1:yes, Q1bii: all components are phased by the same/single uvm_root phase controller. how they are phased depends upon their domain/schedule association and custom/phase transitions.

BTW: as you typically connect your tb with the DUT via virtual interfaces there is no need to instantiate your tb(or components) inside the dut.

/uwe

[Erling]

BTW: as you typically connect your tb with the DUT via virtual interfaces there is no need to instantiate your tb(or components) inside the dut.

/uwe

This works, sort of, for blackbox verification via one static pin-interface. In practice, designs that used to live in their own device have a tendency to be reused as subcomponents in new designs. Thus, the norm, in my experience, has become multiple pin-interfaces, a number of generated pin-interfaces, and many internal signal-interfaces. The internal interfaces can be all kinds of things from trivial checkpoints and coverage support to complete sub-design interfaces. Real interfaces can handle all these cases nicely, while virtual interfaces can not, because a pointer to a static structure, manually distributed for use by any task or function, is a pretty limiting concept. With SV supporting classes with methods in interfaces or modules, there seems to be no need for virtual interfaces, all they have to offer is the buzz phrase name.

Erling

[uwes]

virtual interfaces are the primary method to reach out from a class context into the static module area. using OOMR (out of module refs) have downsides and break encapsulation and i typically avoid them. also to note is that there is a semantic difference whether you instantiate something in an interface/module context (this is what you suggest as far as i understand) or in a program block context (thats what the SV lrm suggests to separate TB/DUT).

>Real interfaces can handle all these cases nicely, while virtual interfaces can not

dont understand this. a virtual interface is a reference to a real interface instance.

as a side note:

there is also the concept of an interface db. you could for instance

1. create a module wrapper for an interface type (a module with an instance of an interface)

2. bind an instance of #1 to some place in the dut hierarchy

3. statically register inside the module wrapper a reference (a virtual interface) with a name in a db

4. then your tb you simply ask the db for a logical if and the db would return the virtual if instance associated with that logical name

basically this allows you to separate dut-if from tb via a logical if name.

/uwe

[AgentSmith_l]

Okay guys thanks a lot for your replies.

from what I understood, It's possible to have uvm components bound in various places in a DUT Design.

Working on these lines I tried a simple experiment in which I have top tb something like this:

module test();

dut_top dut();

bind enet_bus enet_monitor monitor(.rx_clock(rx_clock),

.tx_clock(tx_clock),

.rx_enable(rx_enable),

.tx_enable(tx_enable),

.rx_data(rx_data),

.tx_data(tx_data)

);

initial

run_test();

endmodule

enet_bus: is the name of the basic ethernet module instantiated at various places in the DUT.

enet_monitor: is a verilog module which contains my UVM_monitors, SVA etc. The parent of all the UVM components are specified as uvm_root.

nc_elab on running this gives a fatal erorr "an unexpected situation encountered"..

I think I'm missing something very basic..

Any Ideas??

Edited November 15, 2011 by AgentSmith_l

[AgentSmith_l]

So on further investigation, I found that:

The error appears as soon as even a declaration of any UVM component (or even instantiation of an interface) exists in the module enet_monitor which is being bound into the DUT.

It seems UVM components can not be instantiated in modules bound in the DUT using bind statements.

So what am I missing here?

[Erling]

there is also the concept of an interface db. you could for instance

Why would anyone in their right mind want to do this when SV comes with implicit virtual pointers taking you from testbench context to dut interface context automatically, and also support direct access from classes to signals in the enclosing context without any form of glue or qualification? These properties combined with the uvm factory open for what I call real interfacing, contrasting virtual interfacing.

With virtual interfaces, how do you prevent quick and dirty access from anywhere and thereby making reuse significantly more difficult? How do you re-define an interface as needed when any task and function can peek and poke inside it?

Erling

[Erling]

It seems UVM components can not be instantiated in modules bound in the DUT using bind statements.

So what am I missing here?

Good question. Is all you get "an unexpected situation encountered" message?

I would try to create a mickey-mouse sized test project to check if the tool set you are using actually supports bind, i.e. a trivial dut with a trivial module to bind to, and so forth, everything trivial just to figure out if the simplest possible bind results in "an unexpected situation encouterted".

Erling

[AgentSmith_l]

Yes the following is the only message I get:

ncelab: *F,INTERR: INTERNAL EXCEPTION

-----------------------------------------------------------------

The tool has encountered an unexpected condition and must exit.

Contact Cadence Design Systems customer support about this

problem and provide enough information to help us reproduce it,

including the logfile that contains this error message.

*and some more date/time etc details**

So as I said I started by commenting out code to find out wats giving the problem..

So 1st I removed all code in enet_monitor.. conclusion: binding is workin fine

finally the conclusion: instance of the interface is causing the error.

so heres a simple enet_monitor:

module enet_monitor(

input tx_clock,

input rx_clock,

input tx_enable,

input tx_data,

input rx_data,

input rx_enable);

skel_enet_bus uvc_enet_bus(rx_clock, tx_clock);

skel_enet_monitor uvc_enet_monitor;

assign uvc_enet_bus.tx_data = tx_data;

assign uvc_enet_bus.rx_data = rx_data;

assign uvc_enet_bus.rx_enable = rx_enable;

assign uvc_enet_bus.tx_enable = tx_enable;

initial

begin

uvc_enet_monitor = skel_enet_monitor::type_id::create("uvc_enet_monitor", uvm_root::get() );

uvc_enet_monitor.assign_vi(uvc_enet_bus);

end

endmodule : enet_monitor

So if I comment out all code involving the interface uvc_enet_bus the error is eliminated...

But I am not able to understand why..

[Erling]

What's the point with the internal interface in the enet_monitor? It is an extra level of indirection and extra signal assignment just to create an interface to pass to your uvm monitor. Why not have the uvm monitor implementation directly in the enet_monitor module, for example:

module enet_monitor(
  input tx_clock, 
  input rx_clock,
  input tx_enable,
  input tx_data,
  input rx_data,
  input rx_enable);

  class skel_enet_monitor_imp extends skel_enet_monitor;
  
    function new(string name, uvm_component parent);
      super.new(name, parent);
    endfunction: new
    
    task run_phase(uvm_phase phase);
     // detect signal activity here, whatever
    endtask: run_phase
    
   `uvm_component_utils(skel_enet_monitor_imp)
    
  endclass: skel_enet_monitor_imp
  
  initial
    factory.set_type_override_by_type(
      skel_enet_monitor::get_type(),
      skel_enet_monitor_imp::get_type()
    );
	  
endmodule: enet_monitor

This way, you can instantiate the monitor as any other component in the build phase, and it can be factory replaced etc. and it would be nothing special about it. Of course, this does not explain why your tool is crashing, but may still be something to try.

Erling

[uwes]

an "an unexpected situation encountered" is an internal tool error. you should contact cadence support along with your tools version/setup/testcase. there is nothing wrong you did.

/uwe

[AgentSmith_l]

Thanks uwes and erling for your replies.. I figured out the problem (or rather a way out ). The error was appearing while elaborating some internally generated Top level unit.. Just gave -top to solve the issue..

Neway a new query/limitation/problem:

I am Binding the enet_monitor module to an entity in the DUT. But as you have seen the module enet_monitor has UVM components created under UVM_root. So I cannot have more than one instance of the entity cos we cannot have components with same names under UVM_root.

So currently the workarround I am using is to bind enet_monitor to each instance(instead of entity) and pass a unique int id for each bind. I am using id in enet_monitor for naming those components differently.

Ne better way out?

[Erling]

I have one bind per entity, no matter how many instances there are in the dut, and use the unique part of the %m (format specification) string to register classes in bound interfaces with the factory, either for explicit use in the environment or implicitly by mean of instance overrides. This is not of much help, though, since you aren't registering bound classes with the factory.

Erling

[AgentSmith_l]

Thanks Erling... Got this Idea from your reply..

I just concatenated the names of each of the UVM components with %m.. This will create unique names of the components for each instance of enet_monitor...

[uwes]

hi,

yet another reason NOT to mix static and dynamic hierarchy althrough technically you can create unique paths using % or unique prefix paths. to me its much simpler just to instantiate my required classes complete separate from the DUT infrastructure and ONLY supply the interface for my agents/monitor/s via the virtual interface.

/uwe

[AgentSmith_l]

Yes Uwes agreed it does looks little more complicated in this simple examples.

But according to me, when we are talking about requirement of large number of interfaces to verify passively (in various active testcases) in a large DUT in one simulation it becomes more convenient to bind it in the DUT rather than individually supplying the interfaces from various places in DUT.

[uwes]

hi,

im not convinced that the bind of classes into the dut is a good way - big setup or not. i rather feel that the proposed structure is the outcome of some of the shortcomings/unexpected behavior of (virtual) interfaces interfaces.

/uwe