I am trying to understand the way I can write a UVM scoreboard for a DUT (arbiter) with multiple masters and one slave

Question

I need to write a scoreboard for a DUT which has 3 AXI masters as input and one of them goes out on the other side to AXI slave, like 3 AXI masters-> DUT-> AXI slave. Please let me know if my understanding below is correct or are there any more ways to do it.

Since there are three AXI master interfaces and one goes out to the slave, I will need to instantiate the interface 4 times --> like axi_interface m1, m2, m3, m_out, am I correct?

My scoreboard (sb) will get AXI transactions from one monitor which I can add in the env which will be sampling AXI transaction 1 (m_tran_1), AXI transaction 2 (m_tran_2) and AXI transaction 3 (m_tran_3) from 3 instantiations of AXI master interface. In this monitor, I can wait for req1, req2 or req3 to go high and and based on round robin (for example), it will make gnt_1, gnt_2 or gnt_3 high and send that transaction to the sb which will store it in a queue say expected_q, and sb will also get AXI output transaction (m_out_trans) from this monitor and stores as actual_q and compares both expected_q and actual_q transactions?

Is my understanding correct?

Is it okay to add a monitor in the env to get hold of all the 3 master transactions?

Is there a better way of doing it?

Answer 1

Yes, since your DUT has 4 AXI interfaces, your testbench also needs 4 AXI interface instances.

Your testbench needs 4 instances of an AXI agent, where each agent contains a monitor, a driver and a sequencer. This means the testbench has 4 AXI monitors. Each of the 4 monitors collects AXI transactions and sends them to the common scoreboard. In other words the scoreboard receives transactions from all 4 monitors.

It sounds like you only have one AXI monitor in your env. That is not a recommended approach according to the Universal Verification Methodology.

Generally-speaking, your scoreboard approach sounds correct, except that you need to collect transactions from 3 AXI master monitors and 1 AXI slave monitor. On the master side, the sb will have 3 separate input channels from the 3 different monitors, so you know which transaction came from which interface (1, 2 or 3). I recommend building the priority logic into the sb, that way the AXI agents remain simple and generic.