Synchronization between UVM agents? UVM RAL to other agents

I have a UVM RAL model. I have its agent defined. I want to complete all register writes and then start driving or monitoring DUT signals using another agent. How can I solve this? UVM Events? Can anyone give me example?

The scoreboard fails depending on when second agent’s monitor starts monitoring. One of the register write starts driver and monitor. But subsequent writes change the behavior of the DUT and thus need to discard samples or start driving after all the register writes are done.

In reply to Vishwasu Deshpande:

There are some Options to perform this synchronization.
The most simple would be looking on some Register Content and then starting the Monitor.
Or you can use uvm_events or uvm_barrier.

In reply to Vishwasu Deshpande:

Synchronization between agents should happen at the sequence level. Using a virtual sequence allows you to ensure that one sequence has completed prior to starting another sequence on a different agent.

You should never use events or barriers between agents as this introduces elements which prevents the reuse of components.

In reply to cgales:

I do have virtual sequence. The sequences can be synchronized properly. But the issue is as follows:

I receive a configuration file with address and data (I use a sequence 1 [agent 1] with get_reg_by_offset) from firmware engineers. I should not modify it and use as it is to perform address writes. One of the register kicks off the 2nd driver and monitor [agent 2] by setting some enable signals.

But I also have my config file with field name and data (I use a sequence 2 [agent 1] with get_field_by_name) that is catered to align DUT data on how I drive rest of the signals [agent 2] using sequence 3 [agent 2].

My problem is that the scoreboard via monitor throws null pointer exception. If I don’t use firmware data I don’t get it. So I need to wait till my configuration is completed and then start rest of the agents.

In reply to Vishwasu Deshpande:

I’m not sure what you mean by a null pointer exception in your scoreboard. When you receive transactions in the scoreboard, you should do checking to ensure that they are valid. You should easily be able to determine if you are attempting to access something that doesn’t exist prior to getting a null pointer exception. Worst case is that the scoreboard ignores all transactions until it receives the one indicating that the DUT is properly configured.

In reply to Vishwasu Deshpande:

Null pointer exceptions means you do not have an object available.
The question is have you an indication from the DUT when the configuration is ready?
If yes, than you should work with this by creating a uvm_event.