Hi Madhu and thanks for your question.
This topic comes up a lot, I am considering writing more advice about it.
My quick advice to you for this situation, where you have two or more interfaces to your DUT and you wish to co-ordinate some aspect of verification (e.g. sequence contents) between them, is to create a scoreboard that subscribes to analysis port of your passive agent, and maintains some level of ‘model’ of the behavior that is to be shared with the stimulus on the active agents. (similar to a register model that can be referred to/updated by both stimulus (sequences) and analysis (monitors/scoreboards).
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.
You can use the config db as a mechanism for managing config objects:
For a technique to give your sequence access to a config object, read: