Different approach to implementing multi-monitor - single scoreboard than using the macro `uvm__analysis_imp_decl
INTRODUCTION:
We all know that whenever there are multiple monitors connected to a single scoreboard, we do the connection as mentioned in UVM Cookbook or uvm_user_guide by using the inbuild macro `uvm_analysis_imp_decl(_<string>) and then writing another analysis imp inside the scoreboard with the same name passed in the arg of the above macro
DRAWBACK:
The drawback of the above implementation is that going forward if my num of monitors increases then I need to make changes to my scoreboard file,
I now need to declare the macro also need to add one more imp port inside the scoreboard file and inside the environment newly created imp port needs to be connected.
This goes against the principle of not touching a good working code.
SOLUTION:
The solution I propose here is very simple,
What I am proposing is to declare a string orig_component, dest_component inside the uvm_seq_item class.
Before calling the write method from the monitor do the following assignment

Inside the scoreboard declare a single imp port
uvm_analysis_imp #(my_seq_item, my_scbd) mon_imp;
Inside the function write () we basically check who is the orig_component and based on that we take the action. Don't forget to declare it as virtual as going forward you can extend the base scoreboard and implement more logic to it

Below is the extended scoreboard

From the testcase, you can now override the extended scoreboard to the base scoreboard
ADVANTAGE:
The advantage of this implementation is now your base_scoreboard need not be touched nor your env class. You can extend the scoreboard and do your implementation for any newly added monitor and override the base_scoreboard with extend_scoreboard from your testcase.
The code inside the environment and agent remains the same.
Let me know if you like this method, if any issues you see in the above implementation please do let me know.
Related Semiconductor IP
- nQrux® Root of Trust IP
- AXI to UCIe Bridge IP
- UCIe 2.x Controller IP
- SWI3S (SoundWire I3S Interface) Peripheral Controller Core IP
- OpenTitan-based RISC-V Secure Element
Related Blogs
- Want to Mix and Match Dies in a Single Package? UCIe Can Get You There
- The Shift-Left Approach to Software Development
- One Instruction Stream, Infinite Possibilities: The Cervell™ Approach to Reinventing the NPU
- A Systematic Approach to Robust LVDS Integration in Advanced Node ASICs
Latest Blogs
- From Bug Hunting to Engineering Methodology: Lessons from AI-Driven Development
- Manufacturing Intelligence: Turning EDA Data into Trusted Action
- Execute-in-Place: Getting More from Embedded NVM
- Rethinking RTL flows with AI-driven hybrid formal verification
- Arm and NVIDIA: Building the trusted compute foundation for the agentic AI era