simics> enable-real-time-modeThis will cause Simics not to run faster then the the wall clock. Normally this is not a problem and it will only happens when the x86 processor is sitting idle on a HLT instruction.
For NetBSD, you will also need to lower the check interval to avoid repeated keystrokes:
simics> enable-real-time-mode check_interval=100
To run as fast as possible again you simply run the command:
simics> disable-real-time-modeSee the Reference Manual for further information.
Certain key combinations are normally caught by the host operating system or the window manager and may have dangerous side effects. An example is the ctrl + alt + del combination used to bring up the task manager on Windows and to reboot Linux systems. Such key combinations can be safely inserted using Simics commands instead.
For example to send ctrl + alt + del:
simics> con0.input -e "C-A-Del"
Regular strings can also be issued:
simics> con0.input "mkdir foo\n"
There are also some functions written in Python available in the home/scripts/expect.py file. They can be used to wait for certain output to appear on the simulated screen. Similar functionality is also available through the console if the use_video_text_console option has been activated.
The firmware will most likely pause, complaining about a Timer Error. At that point F1 must be pressed to continue the boot process. To send F1 to the system issue:
simics> con0.input -e "F1"
The halt on system error can also be disabled through the firmware configuration menues.
The clock frequency of a simulated processor can be set arbitrarily in Simics. This will not affect the actual speed of simulation, but it will affect the number of instructions that need to be executed for a certain amount of simulated time to pass. If your execution only depends on executing a certain number of instructions, increasing the clock frequency will take the same amount of host time (but a shorter amount of target time). However, if there are time based delays of some kind in the simulation, these will take longer to execute.
At a simulated 1 MHz, one million target instructions will correspond to a simulated second (assuming the simple default timing of one cycle per instruction). At 100 MHz, on the other hand, it will take 100 million target instructions to complete a simulated second. So with a higher clock frequency, less simulated target time is going to pass for a certain period of host execution time.
If Simics is used to emulate an interactive system (especially one with a graphical user interface) it is a good idea to set the clock frequency quite low. Keyboard and mouse inputs events are handled by periodic interrupts in most operating systems, using a higher clock frequency will result in longer delays between invocations of periodic interrupts. Thus, the simulated system will feel slower in its user response, and update the mouse cursor position etc. less frequently. If this is a problem, the best technique for running experiments at a high clock frequency is to first complete the configuration of the machine using a low clock frequency. Save all configuration changes to a disk diff (like when installing operating systems). Then change the configuration to use a higher a clock frequency and reboot the target machine.
Note that for a lightly-loaded machine (for example, working at an interactive prompt on a serial console to an embedded Linux system), Simics will often execute quickly enough at the real target clock frequency that there is no need to artifically lower it.