synchronization between monitor and driver within an agent

[sandip.gaikwad]

I want to synchronize between monitor and driver. If a number of read requests are put. The driver should not do other transactions until all the read transactions are complete. I check for the read data in monitors.

Can i use a semaphore in both the monitor and the driver processes to hold the driver from issuing any other transaction till the monitor informs all the read data was received. How can I use this?

Or, is there any other way doing this synchronization?

Thanks,

Sandip

[ajeetha.cvc]

A crude way would be to have a variable indicating the number of pending_reads in a "common" place (say in a package) and access ti both from monitor and driver. One could use uvm_config_db to keep it more scalable/reusable maybe - but I am not sure if these are good "architectural" level solutions, your problem may better be solved via better re-arch, though it can't be done via forums/email.

HTH

Ajeetha, CVC

www.cvcblr.com/blog

[yangyuf]

If you just using SV, you can use semaphore. Put a key in it when driver send a read trans, and get a key out when monitor recieve a read data. Then, whenever need issue a write transfer, the driver need check whether there is still key in the semaphore (use try_get task).

[DavidLarson]

Yes, I agree with yangyuf. Semaphores are the way to go. You could even get fancy and pass the reference of the semaphore to the monitor and driver through uvm_config_db#(semaphore) (not tested, though).

[uwes]

hi,

it depends what you mean with "synchronize".

- the monitor should work without the driver being present (in passive mode you just observe)

- the driver and the monitor should always observe the very same interface

- so all the driver can do is to utilize events from the monitor (since driver and monitor look at the same wires they should generate the same events - this is therefore a small shortcut)

depending upon your infrastructure you can use a semaphore, an objection + all_dropped/wait_for*, or you could eventually use a normal fork/join. you could also instantiate 4 single threaded drivers which ensures to have at max 4 items running. or you fork 4 independent get_next_item+drive threads...

/uwe

[DavidLarson]

Actually, now that I think about this more, I would create an analysis port in the monitor that the driver subscribes to. The monitor would advertise what it saw and the driver can react to it.