Objection Mechanism

UVM
1

Hi all
i am confused with objection. i have two questions
I know that if there are no objection to a particular phase , the simulation will move on next phase.
1.Why no one put raise_objection and drop_objection in all phase(ex:build phase,connect phase,run_phase,main_phase etc) in all class?
2.Where should be recommended to put raise_objection and drop_objection?
Thanks!!!

2

In reply to peter:

The objection machanism should be used when your tasks consume time (in run_phase)
For other phases (build, connect, etc.) which are zero timing execution,you don’t need to use objection.

3

In reply to peter:

You use objections to extend a phase beyond one time unit. The build/connect phases are functions and cannot consume any time, so objections would not do anything.

Only one task needs to raise an objection to extend the phase, and that typically is the test class run_phase. “The Test” knows when the test is over.

4

In reply to dave_59:

Thanks for reply
what do you mean that Only one task needs to raise an objection to extend the phase?

i put raise_objection and drop_objection in the test class run_phase.
Do i need to put raise_objection and drop_objection in driver class?
if no need, is it because the test class run_phase trigger seq.start, so no need to put raise_objection and drop_objection in driver class?
is it wrong putting raise_objection and drop_objection in driver class?
Thanks a lot!!

task run_phase(uvm_phase phase);  // test class
   phase.raise_objection(this);
   seq.start(agent.sequence);
   phase.drop_objection(this);   

endtask

task run_phase(uvm_phase phase)  // driver class, without raise_objection and drop_objection
  forver begin
   //phase.raise_objection(this);
   seq_item_port.get_next_item(req)
     drive();
   seq_item_port.item_done();
   //phase.drop_objection(this);
  end
endtask
5

You raise/drop objection in your test is enough. As Dave said, it because your test knows exactly when your simulation finish. Using objection in driver is completely unessersary, sometimes it hangs your simulation. Let’s assume you use objection in driver same as your code:


task run_phase(uvm_phase phase)  // driver class, without raise_objection and drop_objection
  forver begin
   phase.raise_objection(this);
   seq_item_port.get_next_item(req)
     drive();
   seq_item_port.item_done();
   phase.drop_objection(this);
  end
endtass

Now, when all transactions complete, instead of blocking at get_next_item and waiting simulation finish (by dropping objection in test). Your code above raises an new objection and blocks at get_next_item statement, the drop_objection is never executed. Thats why your simulation will never stop.

6

In reply to chris_le:

You raise/drop objection in your test is enough. As Dave said, it because your test knows exactly when your simulation finish. Using objection in driver is completely unessersary, sometimes it hangs your simulation. Let’s assume you use objection in driver same as your code:


task run_phase(uvm_phase phase)  // driver class, without raise_objection and drop_objection
forver begin
phase.raise_objection(this);
seq_item_port.get_next_item(req)
drive();
seq_item_port.item_done();
phase.drop_objection(this);
end
endtass

Now, when all transactions complete, instead of blocking at get_next_item and waiting simulation finish (by dropping objection in test). Your code above raises an new objection and blocks at get_next_item statement, the drop_objection is never executed. Thats why your simulation will never stop.

Thanks for answer. Could you explain how the test knows when the test is over?

7

In reply to peter:

In your test you are starting 1 or more (virtual) sequences. Whann all sequences have been completed your test is over and your objection will be dropped.

8

Thanks a lot

9

just to add more to this conversation, sometimes even if your producer sequences are done the DUT might still be active.

In that case, if your scoreboard maintains a list of active transactions and thus “truly” knows when the test is done.

So, you can either maintain another set of raise/drops in the scoreboard/checker or have an idle event/signal from scoreboard/checker to understand when the test should drop the objection.

Sometimes, you might need to use drain_time as well to control your tests better: I suggest you look into this paper: http://www.sunburst-design.com/papers/CummingsDVCon2011_UVM_TerminationTechniques.pdf