Guideline of using uvm objection

[ranjisan]

Hi,

I have some doubts on the guidelines of using objections.

1) In the uvm user guide I have seen the guideline like " call raise_objection() in pre_body and call drop_objection() in post_body of root sequence". But when we are using macros like `ovm_do etc .. it will not call the pre_body and post_body by default. So this guideline will fail. What is the best approach at this time?

2) If the sequence is non blocking, what is the best guideline to be used for calling the raise_objection and drop_objection?

3) Is it advisable to use objections in the driver or monitor?

4) If the sequence is not a root sequence is it advisable to use objections at the start and end of the body() task?

Thanks

Ranjith S

[uwes]

hi,

regarding your questions:

#1 raise& drop should be in pre+post body because those functions are ONLY called when the sequence is "started" (aka a root sequence). a subsequence doesnt call pre/post body and therefore doesnt work change the objection count. so as a rule of thumb you would have as much objections as you would have active root sequences. (reactive) sequences such as for slaves and background functionality do not need objections.

#2 if your sequences are non-blocking you got some options:

- first you could wait for the responses to appear after the final sequences have been send

- second you could use a drain time to let your simulation complete after all objections have been dropped

- you could also have the scoreboard, the monitor or driver raising objections to prevent your simulation to stop too early

#3 driver+monitor could have objections too, i see no issue in that some "component" says "please do not stop now"

#4 this is more work to add raise+drop to every sequence body it is simpler to do something like:

virtual class uvm_active_sequence #(type A,type B=A) extends uvm_sequence#(A,;
    // ctor
    function pre_body(); uvm_test_done.raise_objection(...); endfunction
    functionpost_body(); uvm_test_done.drop_objection(); endfunction
endclass

and derive your active sequences (the onces with raise+drop) from uvm_active_sequence and the rest from uvm_sequence

/uwe

[smallnokia]

Hi uwes,

I see the UVM example sometimes they implement raise/drop objection in run_phase() task of testcase which is derived from uvm_test class.

what's the difference with the one you put raise_objectioin()/drop_objection() in pre_body() and post_body() of sequence classes ?

the code is like this :

task run_phase(uvm_phase phase);

phase.raise_objection(this);

seq.start(sqr, xxx);

phase.drop_objection(this);

endtask

Is seq.start() a blocking function which would be released by sequencer ?? What's the consequence I don't use raise/drop in this run_phase() task ?

[joniale]

There are some problems on adding objections in the Master driver and monitor. (slave should not have objections as they are reactive)

 

See https://verificationacademy.com/forums/uvm/question-regarding-dropping-objections-once-stopsequences-issued-sequencer

This problem is seen once you start doing asynchronous reset. If you do that then you have to drop the objections in a controlled way (if you currently has an ongoing xfer/raised objection on the driver). This would be difficult if you are using the disable fork or stop_sequences method for controlling the reset.

These two methods, stop the process on the driver but they don't affect the objections.

I would recommend to control the objections only in your test. That is to say, let the user decide when should the simulation be finished independently on the low level driver status. Moreover, the user should have enough mechanism to wait for responses or wait for the end of a processing xfer on the driver before dropping the objections in the test so the user is still under control.

There are ways to kill/drop all the objections like the function force_stop() under http://www.dvteclipse.com/uvm-1.2_Public_API/uvm_pkg-uvm_test_done_objection.html. However, i will not recommend to use that because this kill not only one specific driver objections but all objections. (Reset could be used only under a specific region on your design and the whole design)

 

Verification academy recommends to do only objections on the test (to end the test).

https://verificationacademy.com/forums/ovm/raise/drop-objections-issues-reset

https://verificationacademy.com/cookbook/endoftest

 

If you want to include the objections in the driver, then you have to drop the objections in the cleanup phase after your reset. You can do this only if there is a raised objection.

`uvm_info("PHASE OBJECTION COUNT",

      $sformatf("%0d", phase.get_objection_count(this)), UVM_LOW);

 

 

See an example of the new UVM 1.2 features about objections

http://www.edaplayground.com/x/2Ny

If you don't want to use UVM 1.2 you can implement your own objection counter in the driver.