Again rasie/drop objection

UVM
1

Dear Forum,

I know this topic were discussed hundreds of times, but still please help to clarify one thing

1) Why needed raise/drop objection in a sequence?
All my life I use test class as a place to raise/drop objection and never face issues. However recently I got new environment where the raise/drop objections are done in sequence. There is a one layer of sequence which raise/drop objections in pre/post_body phases. What is the benefits of using such method?
I assume may be it is done for VIP level, when someone creates VIP, than they raise/drop objections in sequence as they don’t have access to test class. Is my understanding right?

2) Starting_phase variable: I know this is for UVMV 1.1 and in 1.2 changed to set/get_starting_phase. But my questions is why we need to check if it is null? When we call sequence we are already in run_phase, right? We just cannot call sequence in null phase as all other phases take 0 time.
And in UVM1.1. how staring_phase variable get initialized?
Also in doc is written to use starting_phase in defaul_sequence, which is now depreciated…

This is code example:

class pkt_sequence extends uvm_sequence#(packet);
   `uvm_object_utils(pkt_sequence)
 
   function new(string name="pkt_sequence");
      super.new(name);
   endfunction // new
 
   virtual task pre_body();
      if(starting_phase != null) begin
	 `uvm_info(get_type_name(), $sformatf("%s pre_body() raise objection[if], %s", get_sequence_path(), starting_phase.get_name()), UVM_LOW)
	 starting_phase.raise_objection(this);
      end
      else begin
	 `uvm_info(get_type_name(), $sformatf("%s pre_body() raise objection[else]", get_sequence_path()), UVM_LOW)	 
      end
   endtask // pre_body
 
   virtual task post_body();
      if(starting_phase != null) begin
	 `uvm_info(get_type_name(), $sformatf("%s post_body() raise objection[if], %s", get_sequence_path(), starting_phase.get_name()), UVM_LOW)
	 starting_phase.drop_objection(this);
      end
      else begin
	 `uvm_info(get_type_name(), $sformatf("%s post_body() raise objection[else]", get_sequence_path()), UVM_LOW)	 
      end
   endtask // post_body
2

In reply to haykp:

  1. You should never need to raise/drop an objection in a sequence. As you mentioned, it should be handled at the test level. It is not the responsibility of the VIP provider to ensure that the user raises/drops objections properly. While there is nothing inherently wrong with raising/dropping objections in a sequence, there can be a significant performance penalty if you make use the sequence often. Also, debugging can become difficult when there are a large amount of objections in use.

  2. The variable starting_phase is set when using ‘default_sequence’. You could theoretically use it to determine which actual phase the sequence was started in. In this case, it just checks that it is actually called in a run time phase and not inadvertently called at some other point.

3

In reply to cgales:

In reply to haykp:

  1. You should never need to raise/drop an objection in a sequence. As you mentioned, it should be handled at the test level. It is not the responsibility of the VIP provider to ensure that the user raises/drops objections properly. While there is nothing inherently wrong with raising/dropping objections in a sequence, there can be a significant performance penalty if you make use the sequence often. Also, debugging can become difficult when there are a large amount of objections in use.
  2. The variable starting_phase is set when using ‘default_sequence’. You could theoretically use it to determine which actual phase the sequence was started in. In this case, it just checks that it is actually called in a run time phase and not inadvertently called at some other point.

Hi cgales,

You mention that we should never raise objections in a different place than the test level, I wonder what alternative have for checking things that are reactive, for example you have a read request but you don’t have any timing for the response besides the fact that it should come out of the DUT, I do understand about the performance penalty of raising/dropping objections but how this situation could be approach.

Thanks

4

In reply to rgarcia07:

When all objections are dropped, the run_phase() will wait for the duration specified by the drain_time before it is terminated. This drain_time is designed to allow the DUT to finish all transactions in process.

You can then use the post-run phases to ensure that all expected transactions were received by the scoreboards. If there are any missing transactions, you can generate an error condition.

5

In reply to cgales:

In reply to rgarcia07:
When all objections are dropped, the run_phase() will wait for the duration specified by the drain_time before it is terminated. This drain_time is designed to allow the DUT to finish all transactions in process.
You can then use the post-run phases to ensure that all expected transactions were received by the scoreboards. If there are any missing transactions, you can generate an error condition.

Thank you very much for the response

-R