Simple concept really, probably many ways to solve.
If I have an agent which can operate in several pin wiggling modes,eg a serial port that could be spi or pcm. The mode can’t be preempted from just pin wiggles, therefore driver and monitor in the agent need to some how stay in touch, or share a common input from the test/env
One solution would be to use the config db to set the agent operating mode.
Both driver and monitor would read the config db to determine required/expected pin wiggle behaviour.
Are there other, more appropriate mechanisms to achieve what’s required.
The config_db would certainly be the simplest. But we would need to know more about how the mode changes, and how the driver/monitor need to be synchronized to those mode changes.
In reply to Rocketfingers:
The config_db would certainly be the simplest. But we would need to know more about how the mode changes, and how the driver/monitor need to be synchronized to those mode changes.
Thanks for the reply.
So it would be unreasonable in the sport example for the mode to change mid frame / tr. but let’s assume for the time being the agent configuration can change several times per test or sequence, real time.
I’m just interested in the other options to get a better overview of a non config db approach.
As I said above, a lot depends on the timing of the mode change. Who is changing the mode? Is this mode encoded in the transaction sent to the driver? Then you could use a TLM channel (put or analysis portion) between driver and monitor. There is also umm_queue and umm_event_pool
There are too many ways of communication in the UVM, I suggest sticking to the smallest set and only use other options when there is good justification for it.