I want to use the monitor handle inside sequence to generate stimulus by monitoring some signals.
How can I create component inside sequence because “this” will refer to hierarchy where monitor is created i.e env.agent.monitor?
If I create monitor inside agent , then I will use below statement:
mon_h = monitor::type_id::create(“mon_h”, this);
Bu using above statement is giving run time error of Null object access.
But if I create monitor in sequence , then how should I create component. Should I change “this” during component creation and what should I write in place of this?
I am using below URL as reference to use monitor inside sequence:
Looks strange what the guys are proposing. I have never seen this before and it is not compliant with the code they are showing in the link.
The common way to use the feedback from the DUT in the sequence generation is th sebd back a response from the driver to the sequence.
See the details here: https://verificationacademy.com/cookbook/driver/bidirectional
But I am not using driver component. I just have monitor component at one interface to monitor design signals and with respect to those signals, I want to drive reset sequence inside virtual sequence. To have different mid_sim reset test cases, I want to monitor some signals and want to start sequence.
In reply to chr_sue:
Hi,
Actually I am having 2 agents in which 1 agent is to monitor dut APB signals which has only monitor.
Other reset agent is having driver & sequencer both to drive resets into dut.
In virtual sequence, I am calling reset sequence to drive reset signals to dut . I want to call reset sequence at specific dut signal values which I am monitoring though first agent having only monitor.
I want to ask how can I use monitor signal values inside sequence to drive resets?
In reply to chr_sue:
Hi,
Iam having many interfaces. My question is in 2 agents. 1 agent of APB signals which Iam monitoring though monitor. And other interface to drive all resets of dut . I want to drive reset signal under certain conditions of APB signals which is given by dut.
In reply to Shefaliv:
It is confusing whar you are writing, because each agent has to be related to a functional interface like an APB bus or an i2c interface etc.
Resets should be activated seperately for each interface. If you want to activate them you have to write reset sequences which are integrated in a virtual reset sequence. This would be a clean and reusable approach. Any other aggregation of signals of different interfaces will limit the reusabolity which is bad.
You can’t instantiate a monitor in your sequence because, well, it’s not a component. So yes, that error is correct.
What you may have wanted is a HANDLE to that monitor. So create the monitor in your agent/enviroment and then pass the handle to that sequence when instantiating it.
Typically you would not use the monitor directly for this purpose. You’d use the output of the monitor, which is the transaction that the monitor will emit through its analysis port. You can try something like creating a virtual sequencer with an analysis port that can listen to the monitor. Then start the virtual sequence on this sequencer and use the analysis port to wait for a ‘reset ready’ transaction to start the reset sequence on the active agent.
You can’t instantiate a monitor in your sequence because, well, it’s not a component. So yes, that error is correct.
What you may have wanted is a HANDLE to that monitor. So create the monitor in your agent/enviroment and then pass the handle to that sequence when instantiating it.
Typically you would not use the monitor directly for this purpose. You’d use the output of the monitor, which is the transaction that the monitor will emit through its analysis port. You can try something like creating a virtual sequencer with an analysis port that can listen to the monitor. Then start the virtual sequence on this sequencer and use the analysis port to wait for a ‘reset ready’ transaction to start the reset sequence on the active agent.
You do not have to cretae an anylsis_port. Because the monitor wants to initiate an activity it has to be an export.
But the sequencer has an rsp_export.
See what the source code says:
// The rsp_port in the driver and/or monitor must be connected to the
// rsp_export in this sequencer in order to send responses through the
// response analysis port.
You may want to brush up on your Object Oriented Programming and working with classes. A handle is essentially a reference to an object. Thus after the monitor has been created, you now have a reference in, say, env.agent.monitor. In the connect phase, you could assign that to a new data member in your custom sequencer. If you do it from env, in the connect phase, you’d call something like env.virtual_sequencer.monitor = env.agent.monitor
I’d still look into making sure this is the right way to solve your problem. Your sequences will be coupled to the implementation details of the monitor and that’s usually not desirable.
I don’t understand your concern for using monitor in sequence.
But If you want to monitor reset signal and on that basis you want to do something(In your case : driving reset sequence)
So In that case you can use Interface handle itself in your sequence.