Why phase raise_objection and drop_objection is required in test class run_phase?

UVM
,
1

There are hand shaking mechanisms available in between sequencer and driver. Until driver sends item_done() the sequence will not be completed. Also the start() method in test also blocking so until sequence is not complete the run_phase task also will not be completed. My question is then why we need raise and drop objection in run_phase of test class?

2

In reply to Subhra Bera:
You are mixing 2 things together:
(1) the interface between sequencer and driver
(2) the objection mechanism.

The objection mechanism is used to stop the simulation after all components in your UVM environment are ready with their work.

For the handshake between sequencer and driver there are 2 different approaches possible:
(1) get/put, this TLM 1.0 style
(2) get_next_item/item_done this is TLM 2.0 style

3

In reply to Subhra Bera:
Your testbench may have many components with run_phase processes. Some of these processes run forever, like the code in your driver. It is up to the testbench architect to decide when the “test” should end. Usually the test raises an objection before starting a sequence and drops it when the sequence returns because that represents the stimulus to your DUT. But sometimes, the test is not over when the stimulus completes, like if the stimulus only represents configuring the DUT. Then you might have a scoreboard or checker waiting for some results, and has an objection raised waiting for the result to drop it.

4

In reply to dave_59:

could you please provide an example of this type of test class. Actually I am unable to understand the last line of your answer.
“Then you might have a scoreboard or checker waiting for some results, and has an objection raised waiting for the result to drop it.”-- means is this objection raise and drop will be inside the run_phase of scoreboard/checker?

5

In reply to dave_59:

also if run_phase is not complete then how the extract phase will start? As run_phase of driver has a forever loop.

6

In reply to Subhra Bera:

The run phase completes when there are no more raised objections. They do not wait for all the run_phase() tasks to return. This the way all time consuming phases end.

Suppose your design was a packet decompressor. Your test sequence would prepare a number of compressed packed to drive into your DUT. Your test would drop its objection after sending the last packet. But the DUT may take many more cycles to decompress, and the scoreboard would be waiting for the last packet to come out. So it raises an abjection as long as it as packets waiting to check.