Questions on Typical Coding practice in Sequence body()

UVM
,
1

Hi ,

I have a few questions on the typical code written in body() of user_sequence

[ A ] Randomizing Request Item


//  In  body()  of  user_sequence  

  req  =  user_seq_item :: type_id :: create( "req" ) ; 

  start_item( req ) ;
  
  //  [Q1]  Request  Item  is  recommended  to  be  randomized  here  ,  why  ?? 

  finish_item( req ) ; 

  endtask

One scenario I see is constraint is based on some properties ( sequencer properties , TB Current Condition etc )

So when start_item() unblocks the properties would have latest values hence it makes sense to randomize() here .

[ B ] Consuming Time between start_item() N finish_item()



  " finish_item must be called  after start_item with no delays or delta-cycles.
    Although pre_do is a task, consuming simulation cycles may result in
   unexpected behavior on the driver. " 
  
  //  Why  unexpected  behavior  on  driver  ??

[Q2] Why is it so ?
Is there a Error if blocking statement / delay is added between
start_item() N finish)_item() OR consuming Time via task pre_do() is added

  **EDIT  ::**  Refer  [try_next_item_protocol_check](https://verificationacademy.com/forums/uvm/uvmerror-only-trynextitem)  where  we  Observe  that  task **' try_next_item ' has  checks  to  ensure  there is  No  delay  (  apart  from 1  NB ) between  call  to  start_item( req )  N  finish_item( req )** !!
2

In reply to MICRO_91:

This is done for what is called “late” or “just-in-time” randomization. This allow you to randomize using the state of the testbench/design exactly at the point when the driver gets the item. It is your choice to randomize before or after start_item().

When you call start_item(), you are telling the sequencer you are ready to deliver an item to the driver as soon as it is requested. The sequencer waits for the driver request, and if the arbitration scheme determines now is your turn, start_item() returns and it your responsibility to deliver the request with no delay. If you were to add a delay, this means you were not ready and is a violation of the protocol.