Hello,
In a sequence, why does it make sense to randomize after calling start_item in a sequence? In the sequence code below, it seems like you would want to randomize transaction tx before pushing it to the driver.
start_item(tx);
assert(tx.randomize());
finish_item(tx);
This is done for what’s know as late randomization. The transaction is actually getting pulled by the driver, not pushed. A call to start_item() is blocked until the driver has call get_next_item() and the sequencer has made its arbitration decision to begin this item. Then you can randomize, or make any other direct modifications to the transaction based on the state of things at the time the request is granted.
Most people don’t take advantage of this functionality, so it won’t matter (I think) if you call randomize before start_item(). But it’s better to be consistent in case you do need the functionality later.
In reply to dave_59:
Dave,
Can we have wait states (calling wait_for_delay function) after the randomize? In one of my cases, I need to wait for a DUT signal for a particular address. But this address will be known after this randomize function.
I really appreciate your reply.
Thanks.
Murali
In reply to mpattaje:
There can be no delays between start_item() and finish_item(). Depending on how your driver is set up, you can either have finish_item() block until the driver issues item_done(), or you can have the sequence use get_response() waiting for the driver to do a put_response().
In general, there should be no wait states in your sequence. All time consuming functionality should be in the driver.