In reply to AbdulRauf1251:
I do not really understand what you mean with ‘delay in the scoreboard’. As I said the scoreboard is self-synchronizing because it depends only of the order of the transactions. You have to take care that you do not loose any transaction and you do not modify the correct order. Both is guaranteed when using uvm_tlm_analysis fifos. They have any depth and can store nay number of transactions.
What can happen is that you do not see all transactions generated from the sequencer in the scoreboard because the objection mechanism has stopped the execution of the testbench before all transactions were processed in the scoreboard. This is the case when you have only 1 objection mechanism in the test implemented. You have to decide if this is critical with respect to your verification quality. In most cases this is not relevent. If you are generating 10000 seq_items and you do process in the scoreboard only 9999 this might not be critical.
But there are mechanisms in the UVM to avoid this.:
(1) Defining a drain_time. The corresponding process waits exactly for this time until it drops the objection. This is not easy to use because you have to specify an absolute time.
(2) A more flexible way is to implement the task phase_ready_to_end. The the dropping of the objections will be delayed until this task has been finished.