Hi:
during simulation running, I need to change a few signals’ vaules. These signals are driven either by “force” in initial do file or by OVM driver(initialize them in task run). how could I “force” them in a testcase on my special time?
like :
in OVM dirver task run,
pins.vpp <= 3.0;
if I need force vpp to 1.0 after some time, how could I do this? cuz I defined test scenario in a sequence, I can’t use $signal_force system function to do this, like
`ovm_do(seq1);
`ovm_do(seq2);
need to change vpp here
`ovm_do(seq3);
of course, I can do this through do file, like estimating seq1 and seq2 run time then force vpp, like
run 2000ns (seq1/seq2 done after 2000ns)
force vpp 1.0 -freeze
run -all
but this workaround is not a good way since I need to estimate sequence run time before I reforece some signals
confusing me.
please advise.
Thanks
P
forget to say… I am using questa6.4c, $signal_force is a function I looked up from questa manual, maybe not supported for other tools
so if somebody can provide a OVM method to approach this, no matter which tool I am using, that’s perfect.
Thanks.P
Since forceis not legal on a virtual interface member (not a procedual context), you can delegate the forceby creating a function inside the interface to do it for you, and call the function through the virtual interface.
I’m assuming vppis a power signal. Treat a change in power like any other transaction You can either create a TLM connection betwen the sequencer and driver to send power transactions. Or ideally, create another sequencer that connects to your driver and send sequence items to change the power.
Two quick comments.
Since forceis not legal on a virtual interface member (not a procedual context), you can delegate the forceby creating a function inside the interface to do it for you, and call the function through the virtual interface.
Thanks, Dave. I am still not clear how to call this kind of function through test case? cuz test case is written in a sequence, not a object. please explain it more detailed.
I’m assuming vppis a power signal. Treat a change in power like any other transaction You can either create a TLM connection betwen the sequencer and driver to send power transactions. Or ideally, create another sequencer that connects to your driver and send sequence items to change the power.
Dave
yes, this vpp is a power. I got your point, but how about this case: if some signals will change rarely, only in some special case, I drive them through a do file when initialization, not through OVM mechanism. Is it possible to use this “force” command or anything like that in an OVM sequence?
I mean,
`ovm_do(seq1);
"force some signals which are not driven by OVM"
`ovm_do(seq2);
Though in principle you can achieve this with mix of OVM + TCL combination I suggest you avoid it for the following reasons:
Simulators provide MAX performance when such TCL commands are not in use. It is always nice to be able to “compile” things especially for regressions. If it is for debug, then it is a different ball game.
For such “rarely changing things” one can think of a “noise generator” component/sequencer that wakes up once in a while and do this randomly/predictably.
If you show a base code (say built on XBUS), it is quite easy for us to show you how to achieve this with Questa. Sure enough every tool provides similar TCL interface so porting is not all that hard, if you choose TCL route.
If you show a base code (say built on XBUS), it is quite easy for us to show you how to achieve this with Questa. Sure enough every tool provides similar TCL interface so porting is not all that hard, if you choose TCL route.
sorry, Srini, could you give me an example about this?
I can’t find which segment code in XBUS shows that.
sorry, Srini, could you give me an example about this?
I can’t find which segment code in XBUS shows that.
I meant to say that if you can demo your goal using XBUS as a base, then someone may help faster. i.e. take the test_read_write from XBUS and “toggle” an extra signal in say interface with pseudo-code.
Srini is correct. If you use Tcl commands this to modify a signal, you may lose the ability to optimize that signal, as well as anything that signal touches. The other problem is, it might be great for you as the writer of the quick and easy sequence, but for the poor engineer who has to read and maintain your code after you have gone on to better things, it is a nightmare to trace how a signal got modified. (Just like AOP ;))
But if you insist, there is a built-in mti_fli package that gives you access to modelsim/questa’s Tcl interface.
As designs become more power-aware, you are going to have to deal with more than just changing power levels. You will have to sequence isolation, retention, level-shifting and other signals as well.
At a minimum, I would suggest adding an extra port to your driver and executing the Tcl command from a thread in your driver.
ovm_get_port #(power_trans_t) power_port;
task power_controller; // fork'ed from run()
string command;
power_trans_t t;
forever begin
power_port.get(t);
$sformat(command,"force vpp %f -freeze",t.data);
mti_fli::mti_command("force vpp 1.0 -freeze");
end
Then, assuming you’ve added an export to your sequencer, your sequence would look like (psuedo-code)
