How to choose the uvm_event for uvm_heartbeat?

[hugemx830202]

Hi,

Recently I just want to try to use uvm_heartbeat class to replace our original watch_dog class, but I am not very clear about how to choose the uvm_event when calling set_heartbeat(uvm_event e, ref uvm_component comps[$]), place the event trigger inside the raise/drop or outside?

For example:

1. sub-routines():

raise(this);

...

event trigger;

...

drop(this);

If the above routine is dead after event trigger, then the event will never be triggered again, it seems that heartbeat will not monitor this routine, and only timeout will kill this simulation.

2. sub-routines():

event trigger;

...

raise(this);

...

drop(this);

seems the same problem.

So my question is that, how to place the uvm_event? Does anyone know that?

[uwes]

hi,

the objection and the event for the heartbeat can be considered as two separate things. usually they are controlled from two separate threads:

1. the uvm_event trigger() defines the heartbeat window.

2. the associated uvm_objection is expected to happen in the heartbeat window.

the heartbeat feature now would stop the simulation if there are NO objection "events" (RAISE|DROP) between two conseq. events in the heartbeat window defining uvm_event. with that you should split your functionality into two parts:

1. defining a window (could be time based or based on specific event in your simulation (start-of-frame|end-of-frame)...) and

2. something which triggers your objection as sign of "being alive" (like "processing finished",...., interrupts)

attached is an example of the heartbeat

// -*- test:  irun -uvmhome ~/src/uvm/distrib/ ~/src/uvm/distrib/src/dpi/uvm_dpi.cc test72.sv +UVM_TESTNAME=test +UVM_OBJECTION_TRACE

module test72;
   import uvm_pkg::*;
   `include "uvm_macros.svh"

   class test extends uvm_test;
       `uvm_component_utils(test)
       uvm_heartbeat hb;
       uvm_callbacks_objection myobj;

       function new(string name, uvm_component parent);
           super.new(name,parent);

           myobj = new("heartbeat-objection-source");
           hb = new("this-heartbeat", this, myobj);
           hb.add(this);      
       endfunction
       task run_phase(uvm_phase phase);
           uvm_event e = new("e");
           int i =5;

           super.run_phase(phase);

           // stall the phase until WE are done
           phase.raise_objection(this);

           // this is a component to monitor
           hb.add(this);

           // start the heartbeat
           hb.start(e);

           // now run the thing
           fork
               // window definition
               forever
                  #10 e.trigger(this); 

               // raise+drop
               // at least one of RAISE|DROP must be in the heartbeat window defined by conseq
               // event triggers
               begin
                   repeat(10) begin
                       myobj.raise_objection(this);
                       i++;
                       #i myobj.drop_objection(this);
                   end
               end            
           join_any
           hb.remove(this);
           hb.stop();

           // now WE are done
           phase.drop_objection(this); 
       endtask
   endclass

   initial run_test();
endmodule

regards

/uwe

[hugemx830202]

Got it ,thanks a lot!

But I have another 2 questions:

1. what 's the difference between phase.raise_objection(this) and uvm_test_done.raise_objection(this)?

2. Could I just use phase.raise_objection itself instead of "myobj"?

[uwes]

hi,

#1 both raise_objection raise an objection. the one on "phase" objects to the end of the current phase - the one on 'test_done' objects to that. and as you spotted correctly they are somehow doing very similar stuff. 'uvm_test_done' comes from 'ovm_test_done' and was the original way to end the run "phase" of ovm (ovm did only have a single runtime phase). the correct way for uvm10 is probably to use "phase.(raise|drop)_objection" to stop the current phase from progressing to the next phase.

#2 you cant use the uvm_phase.get_object() in place for a uvm_callbacks_objection - that would mean that you expect in your simulation a raise|drop to end the current phase within the heartbeat window.

[hugemx830202]

#2 you cant use the uvm_phase.get_object() in place for a uvm_callbacks_objection - that would mean that you expect in your simulation a raise|drop to end the current phase within the heartbeat window.

My questions:

1. Do you mean I can not use uvm_phase.get_object() in place for a uvm_callbacks_objection?

2. in uvm_phase class, only defined get_objection() function, and return the phase_done object, do you mean we can place for uvm_callbacks_objection?

[uwes]

My questions:

1. Do you mean I can not use uvm_phase.get_object() in place for a uvm_callbacks_objection?

2. in uvm_phase class, only defined get_objection() function, and return the phase_done object, do you mean we can place for uvm_callbacks_objection?

#1 no, because a uvm_objection is not a uvm_callbacks_objection - you could use a uvm-call_backs_objections as uvm_phase.objection() but uvm doesnt allow you to set the objection. im not sure if just the setter is missing or if there are other places holding references to the objection object. only option now is probably to sync two objection objects (basically phase.objectio(raise+drop) will cause some_uvm_call_backsobjection raise+drop.

#2 you could probably create a derived class from uvm_callbacks_objection which holds additionally a ptr to an objection and hooks into the objection raise/drop. but you cant use a base call as replacement for a derived class.