mrflibble
Advanced Member level 5
- Joined
- Apr 19, 2010
- Messages
- 2,720
- Helped
- 679
- Reputation
- 1,360
- Reaction score
- 652
- Trophy points
- 1,393
- Activity points
- 19,551
Alright, both problem and solution. Normally I wouldn't bother posting something like this (after I find the solution ), but some parts of it are sufficiently non-obvious that this may help future googlers.
The problem:
Starting modelsim (vsim) gui from an environment that vsim decides just is not interactive enough for some reason or another. The environment in particular is SVEditor (eclipse based). I could start simulation jobs just fine using the External Tools Configuration. That even gives you a nice interactive console inside the sveditor/eclipse console. In fact, it is exactly like vsim interactive mode. Even when you don't specify interactive mode (-c option). I suspected it had something to do with the eclipse console just not implementing some ioctl that vsim is using to figure out the capabilities of the interactive terminal. In fact, using plain vsim (default gui mode) is exactly the same as vsim -c (interactive mode) when fired from eclipse. And on the other side of things I tested starting from a real terminal. With standard flags ==> get gui. With -c flag ==> get interactive console. All as expected. Okay, start it using nohup. That way you deprive it from anything remotely acting like an interactive terminal. Sure enough, that runs the sim, but this time as if it were batch mode. MMmh, okay, so if that behaviour is as expected then hopefully the other way around also works. Provide it with a nice fake terminal and see if we get a gui. So I did a nohup script vsim, and tadaaa we have gui. The nohup is of course not needed, but just to see if all my guesses were correct. So now ...
The solution:
The external script you use from eclipse normally would have something like this in it:
Using that would give you the above problems .. no gui. One small change required...
The script command will start vsim, only this time providing it with a "proper" fake terminal and now you will get your default gui again.
Does anyone "in the know" happen to know what could cause vsim to behave like this? I suspect an unimplemented ioctl that vsim is expecting to be there, but it'd be nice to know for sure. I did check DISPLAY variables and such, and they were all properly propagated, so that wasn't the issue.
Anyways, hope this is of help to future victims.
The problem:
Starting modelsim (vsim) gui from an environment that vsim decides just is not interactive enough for some reason or another. The environment in particular is SVEditor (eclipse based). I could start simulation jobs just fine using the External Tools Configuration. That even gives you a nice interactive console inside the sveditor/eclipse console. In fact, it is exactly like vsim interactive mode. Even when you don't specify interactive mode (-c option). I suspected it had something to do with the eclipse console just not implementing some ioctl that vsim is using to figure out the capabilities of the interactive terminal. In fact, using plain vsim (default gui mode) is exactly the same as vsim -c (interactive mode) when fired from eclipse. And on the other side of things I tested starting from a real terminal. With standard flags ==> get gui. With -c flag ==> get interactive console. All as expected. Okay, start it using nohup. That way you deprive it from anything remotely acting like an interactive terminal. Sure enough, that runs the sim, but this time as if it were batch mode. MMmh, okay, so if that behaviour is as expected then hopefully the other way around also works. Provide it with a nice fake terminal and see if we get a gui. So I did a nohup script vsim, and tadaaa we have gui. The nohup is of course not needed, but just to see if all my guesses were correct. So now ...
The solution:
The external script you use from eclipse normally would have something like this in it:
Code:
vsim -do my_fav_script.do
Code:
script -c "vsim -do my_fav_script.do" /dev/null
Does anyone "in the know" happen to know what could cause vsim to behave like this? I suspect an unimplemented ioctl that vsim is expecting to be there, but it'd be nice to know for sure. I did check DISPLAY variables and such, and they were all properly propagated, so that wasn't the issue.
Anyways, hope this is of help to future victims.