In reply to gordon:
Thank you Gordon for the explanation.
Hi Gordon,
For this I would add a ‘config object’ which is a non-component, populated by the scoreboard based on observations, and referred to by the sequences running on the active agents.
Of course in doing so you are creating some OOP coupling between two or more parts of your testbench by the fact they both need a handle to this config object, but this is quite valid when it is done for verification reasons.
Keep the scoreboard lightweight, keep the ‘model’ data in a lightweight config object, and your solution will scale up for reuse.
When you say config object it should be extended from uvm_object, right ? How can the object be populated by the scoreboard as it will not have any tlm ports ? Could you please explain ?
Could you please elaborate on what you meant by, Keep the scoreboard lightweight, keep the ‘model’ data in a lightweight config object, and your solution will scale up for reuse - did you mean the scoreboards just feed in observed transactions to the config object and all the required processing should be done in the config object. I am not very clear on “lightweight config object” here.
Also, I would be very grateful, if you can share an example for this interaction.
Regards,
Madhu