In reply to mseyunni:
Even if using a virtual sequencer, the virtual sequence needs to have pointers to the “regular” sequencers in the virtual sequencer. You can just as easily set these pointers to the actual sequencer instances and save yourself a level of indirection.
- I am not very clear when you say “create an instance of queue/array”. where does this array exist as a member ?
Wherever you want to put it. The point is that you’ll use the config_db to pass the same object to both your scoreboard and your sequences, so they’ll all use the same actual data structure.
- I wonder what happens if both scoreboard and the sequence both trying to access the same index at the same time ? Do we need any semaphores to take care of this shared resource access ?
That’s an application-specific programming question that you’ll have to answer yourself. But a semaphore is probably a good idea.
- Will this approach reusable, in the sense that when this env is used at top level where env may be replaced with top level env with all agents being passive ?
Whatever env you use must set up the sequences and scoreboard in such a way that they will be useful. If you replace your env with another, you must still do the setup.
- Also, what if I want to access different pieces of information such as array of objects (cloned from observed traffic) and maintained in a system monitor or some other component?
If that’s what you want to do, then you may do it. You can either share the array via config_db, or you can have each of your monitors’ analysis_ports connected to a system monitor (which would probably best have multiple analysis_exports).
Hope this helps,
-Tom