Simulator/OVM will terminate/complete the run phase of simulation on following conditions, right?
o Seeing raise and drop objection count is zero
o Executing terminating functions (global_stop_request, $finish…)
o On seeing end for a body if there are no objections definitions
If the above conditions are true, I have a problem i.e.
I have a environment, in which I need to re-use the IP sequences from two different teams.
One team has followed raise and drop objection and other didnt and they just wait till the end of body to complete the run phase.
I need to call these two sequences inside a for-join_none thread, the thread which has raise and objections defined will complete faster than other and hence the test is completing abruptly before completing other sequence.
Planning to change the OVM code, which will wait for both raise objections to complete as well as all sequences would complete their body.
Please help me, in pointing the section of OVM code which has to be edited for this kind of scenario.
If you add a raise_objection() and drop_objection() to your test, your test will only end when all of the sequences are completed and the test is ready to finish.
Sorry, I didnt completely understand your question.
From your answer, I understood this i.e. even with mixed sequences (with and without objections) simulation will complete only if all parallel sequences reaches end of body.
That is correct. As long as there is one outstanding objection at the test level, the simulation will continue. When all sequences are completed (and drop their associated objections), the test can drop the final objection and the simulation will complete.
Repeating the question again, for more clarification and to give you more picture i.e.
class seq_obj extends ovm_seq;
task body;
raise objection; #10;
drop objection;
endtask
endclass
class seq_noobj extends ovm_seq;
task body; #100;
endtask
endclass
class seq_test extends ovm_seq;
seq_obj with_obj;
seq_noobj with_noobj;
task body
fork ovm_do(with_obj); ovm_do(with_noobj);
join_none
endtask
endclass
can you explain at what time simulation finishes.
→ top level sequence doesnt have objections
→ both base sequences are called in a fork and join none (top level seq will not wait for the completion of base seq)
→ I know, this might be a wrong way of codding. want to understand the behavior
→ seq_test will complete its operation by 0 time
→ @0 time seq_obj would have raised obj
Will test complete after 10 units of time or 100 units of time?
Simulation completes when the objection counter reaches zero, irrespective of whether the top level sequence/test finishes or not. So, in the above case although seq_test finishes at time 0 itself, your simulation runs till 10 units which is where the objection count reaches zero and then the test gets terminated.
As per the scenario you specified, here are the values of the objection counter at different times.
@ time 0: objection count: 1 (objection raised by seq_obj)
@ time 10: objection count: 0 (objection dropped by seq_obj).
So, its always good to use raise/drop objection in the test, especially when the mixed style sequences (with and without raise/drop_objection) to avoid early termination of your tests.
Responding to your previous post again,
==== From your answer, I understood this i.e. even with mixed sequences (with and without objections) simulation will complete only if all parallel sequences reaches end of body. ====
As cgales mentioned above, your understanding is correct only if you use raise/drop objections at the test level/virtual sequence level too;
If you want to make sure that seq_noobj completes, then you shouldn’t put it inside of a fork/join_none block. You should either call it sequentially using the start() method and wait for it to complete, or call it inside of a fork/join block.
You should ALWAYS use objections in your test, raising the phase objection before starting any sequences and dropping it when all sequences are completed. Why can’t you use objections in your test?
I still don’t understand why you can’t raise and drop objections at the test level. This would be significantly easier to do than trying to modify the OVM code base itself. Once you modify OVM, you lose all the benefits of using a vendor provided code base which may have simulator-specific enhancements such as transaction tracing and debugging features.
Now, I understood your problem. Since you are calling the top level sequence “seq_test” from some test (test1) and raising and dropping objections there. In that case, your test still ends at 10units because,
Your top level sequence ends at #10units because of fork/join_none usage.
Then test objection will be dropped immediately and objection_count reaches zero.
The solution is
to use fork/join in the toplevel sequence instead of fork/join_none, if the scenario permits you do. (as cgales suggested)
or
to edit the noobj sequence to add raise/drop objections if you can.
I am not sure about where the relevant OVM code of your interest exists, but I think it is better to choose option (2) rather than going and updating the source code of OVM to stop the test termination.
Or, let us wait and here from the experts if there is any other elegant way to resolve this issue w/o editing the base sequences.
It has never been recommended to use objections in sequences for the exact reason that you are encountering. I would recommend removing the objections from all of your IP sequences and utilize them at the test level as they are designed to be used.
The OVM and now UVM methodologies are great for providing coding patterns that reduce the amount of code you need to write yourself, but they will never get to the point where there is exactly one way to do every task. We are all designing and verifying hardware with different requirements, and the UVM keeps coming out with new and better ways of accomplishing the tasks to meet those requirements. Some will say that there are too many features in the UVM, and that is exactly why we have the OVM/UVM cookbooks to provide the extra guidelines to help you avoid the complexity when it is not needed.