If you have problems typing in the password when logging in because the simulated machine times out too quickly you can issue the Simics command:
simics> enable-real-time-mode
This will cause Simics not to run faster than 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-mode
See 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> board.console.con.input -e "C-A-Del"
Regular strings can also be issued:
simics> board.console.con.input "mkdir foo\n"
Without the connection of the USB tablet device, only the relative coordinates of the mouse can be reported to the graphical console. So if the simulated console and the real desktop disagree about the mouse acceleration or position, you will get seemingly erratic mouse behavior which is common and very irritating.
To resolve the problem, you can connect the USB tablet device by setting the parameter connect_usb_tablet to TRUE. Then in the Simics target script, enable the absolute pointer like this:
if ($connect_usb_tablet == TRUE) {
$console.con->abs_pointer_enabled = TRUE
}
Now the absolute mouse coordinates will be reported, which means that the mouse pointer is exactly at the point where it is on the real desktop. You can then start Simics and the mouse movement in the graphical console should become normal.
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 artificially lower it.
The sample-core-timing model is a simple instrumentation tool that can adjust the timing based on what goes on in a core. The code can serve as an example on one way to extend a functional simulation with approximate timing.
The model works by running a number of instructions fast while collecting information about what goes on in what is called a period. Then the core is stalled to make the core's time match the calculated number of cycles for the instructions retired during the period.
The provided example model collects read and write operations, total number of instructions and number of instructions of a configurable set of instruction classes. This will not give any real timing information since the inner workings of a modern core is much more complicated.
Activity
The tool can also calculate activity to provide a base for power and temperature modeling. Activity is calculated in a similar way to the cycles but also include a base activity per cycle. Again, these numbers will not match the real thing but can be used to exercise power management code.
To create a sample-core-timing model and attach it to the core(s)
simics> new-sample-core-timing-tool name = timing -connect-all
This will create a central tool called timing and one timing-model object per core.
All the standard commands for instrumentation tools can also be used with sample-core-timing. See instrumentation chapter in the Simics User Guide for more information on the instrumentation framework.
There are a number of commands in the tool to help set it up. With the commands set-base-cycles-per-instruction and set-base-activity-per-instruction the number of cycles and amount of activity used for each instruction is set. With set-base-activity-per-cycle a background activity that is added per cycle can be set. Both cycles and activity can be specified as floating point numbers. Default for the activity settings is 0 but for cycles default is 1 cycle per instruction.
simics> timing.set-base-cycles-per-instruction cycles = 0.5
simics> timing.set-base-activity-per-instruction activity = 227.4
simics> timing.set-base-activity-per-cycle activity = 4.56
Read and write operations can add both extra cycles and activity. The commands set-cycles-per-read, set-activity-per-read, set-cycles-per-write and set-activity-per-write are used to configure those settings. Default cycle and activity values are 0.
simics> timing.set-cycles-per-read cycles = 0.11
simics> timing.set-activity-per-read activity = 34.5
simics> timing.set-cycles-per-write cycles = 0.27
simics> timing.set-activity-per-write activity = 128.3
Instruction classes
In this context an instruction class consists of a substring and adjustment settings for cycles and activity. Since base-cycles and base-activity are specified for all instructions, this is a way to tune for particular sets of instructions. To help set up there are a couple of commands.
With add-instruction-class a new instruction class is added. The adjustment values for cycles and activity can be either positive or negative. The activity value can be omitted which is the same as setting it to 0.
simics> timing.add-instruction-class instruction = "div" extra_cycles = 0.7 extra_activity = 328
simics> timing.add-instruction-class instruction = "nop" extra_cycles = -0.25 extra_activity = -118
simics> timing.add-instruction-class instruction = "xmm" extra_cycles = 0 extra_activity = 147
simics> timing.list-instruction-classes
Finally, there are two commands to inspect what the sample-core-timing models have found out. The list-performance-metrics lists IPC, instructions per cycle, and activity per cycle for the last period and average IPC and activity per cycle for the whole time the model has been enabled. The list-metrics lists all the internal metrics accumulated in the timing models.
simics> timing.list-performance-metrics
simics> timing-list-metrics
Telemetry from the timing model can be retrieved through the telemetry-interface. Three different telemetry-classes are provided. A notification called "isim-telemetry-update" is notified when there is new data to look at.