UVM agents - single/multiple?

I want to test a receiver with the following ports:

Details about the arrows in the diagram above:

Control/Status Registers:

• 16x32bit input signals (16 control registers)
• 16x32bit output signals (control read-back and status)
• 16bit write strobe signal for each of the registers
• 16bit read strobe signal for each of the registers

Data:

• 4x8-bit data from the PHY layer
• 1x clock
• 1bit active signal

BRAM: i don't think it's important here, as I have to create an agent for that anyway

The control flow would look something like this:

1. configure control registers
2. add stimulus to Data
3. check status registers and BRAM

How should I go about implementing the agents? UVM suggests having an agent for both Control/Status and Data, which causes me some headache:

• i think it's the preferred way if one has bidirectional functionality (that means input on one interface output on the other + the other way around) - in my case the control flow is fix, i'm not sure whether there would be any benefit in separating the 2 drivers
• if i'd separate control/status and data, i'd have to somehow synchronize the sequencers, in order to have the appropriate control settings for the Data configuration before applying the stimulus. Which i'm not sure how to do, this seems like an overkill.

From the UVM environment documentation:

Is it ok to merge Control/Status and Data into one agent? What would be the drawbacks? Can (should?) an agent contain multiple drivers?

From the information provided, it seems you have 3 distinct interfaces (groups of signals) connecting to the DUT:

1. BRAM
2. Data
3. Registers

This means you will have 3 different SystemVerilog interface's, which leads to 3 different uvm_agent's.

For the Control/Status Registers agent, consider using an array of 16 agents (one for each of the 32-bit groupings).

When you create a test, you likely need to coordinate the sequences running on the different agents. A virtual sequencer is a standard UVM practice and may be appropriate in your case. It is hard to say whether or not it is overkill in this case. Keep in mind that design verification is not trivial.

Can (should?) an agent contain multiple drivers?

No, a uvm_agent should consist of at most one uvm_driver.