adding delay between regmodel transactions

[phil]

I am trying to figure out a way to insert random delay between regmodel transactions, but couldn't find any facility in UVM_REG that support this.

Could anyone share some insights about how to approach this?

Thanks for the help.

Phil

[Logger]

This doesn't work?

model.reg.write(...);

#100; //< insert any old kind of delay statement here

model.reg.write(...);

[phil]

This certainly works. But somehow it seems non-uvm-ish to me.

Since I am new to UVM, I am trying to learn the recommended UVM way first, before becoming creative.

Is above a typical way to automatically randomize delay between register_model transactions?

Thanks.

Phil

[Roman]

Hi Phil,

I think you'd better add the random delay on the iUVC's Driver. (iUVC = Interface UVC) between transaction..

As we know, reg item from UVM REG will be translated to bus item by UVM REG Layering, and iUVC's Driver will drive the bus.

UVM REG model is just designed to facilitate productive verification of SW programmable HW.

I don't think it's better to implement random on the UVM REG model.

[uwes]

hi,

some other/more options:

1. add a random_delay to your low level transaction and have the driver make the gap before/after a transaction. (your reg model doesnt see the gap)

2. create an extension container holding a random_delay field. pass the container during read/write/update/etc in the extension arg. translate in the adapter to a low level gap (either as part of the low level transaction (see#1) or cause a GAP-transaction on the low level sequencer/driver, or invoke a custom gap() member in the driver....)

3. have the adapter inserting random gaps before/after transactions

4. have a parallel sequence running the low level driver just doing gap-transactions. this will randomly mix the gap (transactions) with all other traffic.

5. throttle the low level driver by only getting a real transaction after a certain gap (basically have the low level driver doing+injecting the gaps)

6. i guess there are more options

the path depends what you need in terms of controllability, reuse and simplicity.

regards

/uwe

[phil]

Thank you all for your responses.

The ideas and explanations are really helpful. I will go ahead and impelment one of them.