How to get handle to env from the sequence in uvm?
In reply to shilpak1:
I would strongly argue that there is never a reason to have a handle to an environment in a sequence. There is nothing in the environment that a sequence needs access to.
However, there may be an environment configuration object that the sequence can use. In this case, after the sequence is created by the test, the configuration object handle can be assigned to the sequence.
In reply to cgales:
I believe it is necessary sometimes.
When I want to disable checking in the scoreboard, for an example, I need the control in the sequence, so I need a env handle in the sequence.
I find a boring approach that link the handle of env in test_base in connect_phase to the handle in a sequencer. Then declare p_sequencer in the sequence. The sequence will have access to all components.
The config approach, as far as I am concerned, cannot or is difficult to turn the components dynamically.
In reply to Leo Lian:
I’d like to underline what cgales is saying: there is never a reason for having a handle of the UVM testbench in a transient oject like a sequence.
In reply to chr_sue:
But why not? Would you provide a better solution to deal with the problem I mentioned above?
In reply to Leo Lian:
I’m not sure why you would want to disable checking in a scoreboard. A scoreboard should be able to handle all of the objects that are sent to it. If there should be no objects sent to a scoreboard, then the monitor should be configured appropriately.
In reply to Leo Lian:
In reply to chr_sue:
But why not? Would you provide a better solution to deal with the problem I mentioned above?
What you want to do is a bad approach because it is limiting your project data for re-use.
There are tons of better solutions available. To advice you I’d need more information what the indication is to stop the compare in the scoreboard and may be to stwitch it on again.
In reply to Leo Lian:
In reply to cgales:
I believe it is necessary sometimes.
When I want to disable checking in the scoreboard, for an example, I need the control in the sequence, so I need a env handle in the sequence.
I find a boring approach that link the handle of env in test_base in connect_phase to the handle in a sequencer. Then declare p_sequencer in the sequence. The sequence will have access to all components.
The config approach, as far as I am concerned, cannot or is difficult to turn the components dynamically.
Disable scoreboard is sometimes necessary. However, the sequence behavior which is used to generate traffic to DUT doesn’t relate anything to scoreboard checker. According to your idea, disabling the scoreboard affects the stimulus of the test, that’s not correct for any circumstances.
Can you explain more, what is “the control” you that are using in sequence?
One more thing, in case you want a sequence uses a configuration/object of env, using config_db to set/get the object to/from sequencer (m_sequencer) is the good solution, not boring at all.
In reply to cgales:
It’s just an example. I may want to switch off any component when needed.
The circumstance I was facing is that, at the very begining I need some illegal stimulus feeding the dut, and after a while, I reset the dut, and finally I feed some new legal trans.
In the first phase, I need to switch off the scoreboard, or monitors whatever, because I dont care about the errors or any stucks there. I’ll reset it anyway.
I turn on the checking after I reset and restart my new legal trans.
I know my approach is awkward so I hope you guys could offer me better solutions.
1 Like
In reply to chr_sue:
In reply to Leo Lian:
What you want to do is a bad approach because it is limiting your project data for re-use.
There are tons of better solutions available. To advice you I’d need more information what the indication is to stop the compare in the scoreboard and may be to stwitch it on again.
see my problem above please. I dont have any extra code within the lower components but only in test_base/ sequences. I dont feel it limits reuse up to now.
In reply to chris90:
In reply to Leo Lian:
Disable scoreboard is sometimes necessary. However, the sequence behavior which is used to generate traffic to DUT doesn’t relate anything to scoreboard checker. According to your idea, disabling the scoreboard affects the stimulus of the test, that’s not correct for any circumstances.
Can you explain more, what is “the control” you that are using in sequence?
One more thing, in case you want a sequence uses a configuration/object of env, using config_db to set/get the object to/from sequencer (m_sequencer) is the good solution, not boring at all.
See my problem above please. Firstly I’m sorry that I was treating sequences as tests, because they’re quite alike in the respect of run-time control. I nearly forgot a sequence is used to generate tranactions. But anyway, the problem is similar that I need to have the control in tests.
The approach you mentioned suits situation that the environment keeps static. When I want to config components dynamically, I find it difficult to use set/ get approach, because I dont konw when to do my second time “get” in my scoreboard. It’s usually to have set once in build_phase and get once at in connect_phase or later but now I need to have multiple set/ get in run_phase.
In my opinion, I think you should create two different sequence for two phase.
And start them in the run_phase in test.
And before and between those two seq.start(), you change the config of them.
Because in my opinion, the env config should not be changed in one sequence.
However, after the run of one sequence, you may change the env config, like the mode of driver or monitor through agent.