In reply to dave_59:
In reply to uvmsd:
You did not mention in your original question the intent behind what you wanted to share.
Below is the intent.
REQ_NUM_WORDS represents packet size. I want to send faulty packets(sending the packets with less or more than the standard size). The packet size is set by the sequence and i have added a field in the seq_item. Using this field REQ_NUM_WORDS(packet size), the driver generates cs(chip_select) accordingly.
And i wanted this info to be passed onto monitor too so that the monitor would take appropriate action on those packets.
And REQ_NUM_WORDS might change dynamically(packet boundaries) throughout the test.
If you need a uvm_event, you can put the through the uvm_config_db as well. In that case, you are configuring the handle to a shared uvm_event. It is usable friendly that way because the driver needs no knowledge of the components that contains it.
Sorry, I didn’t get what you said about uvm_event above.
BTW, I have passed uvm_event(not the global pool) through config_db in the driver and retrieved it in the monitor. It did work. It didn’t have to go through agent.
- An uvm_event is created and triggered in driver. It triggered based on certain delays. And this uvm_event is set in build_phase of driver.
- I did ‘get’ to this uvm_event in build_phase of monitor. Monitor waits for uvm_event to be triggered and then starts writing into TLM fifo(that’s the requirement)
Ok, my understanding is that, once you do a set to uvm_config_db to any variable, and if you have retrieved it in other component, it should reflect all the subsequent changes occurring on that variable, right?
Of course, we have to make sure that, the get doesn’t occur before the set.
Please let me know.