In the default model, the execution of a step takes no time by itself, and steps are run in program order. This is called the Simics in-order model. It implements the basic instruction set abstraction that instructions execute discretely and sequentially. This minimalistic approach makes simulation fast but does not attempt to model execution timing in any way.
Normally one step is executed every cycle, so that the step and cycle counts are the same. See the section Changing the Step Rate for how to change this.
The in-order model can be extended by adding timing models to control the timing of memory operations, typically using the memory hierarchy interface described in chapter 16. When timing models are introduced, steps are no longer atomic operations taking no time. A step performing a memory operation (whether an instruction fetch or a data transaction) can stall for a number of cycles. Cycle events are performed during the stalling period as time goes forward. Step events are performed just before the step execution, as in the default model. Note that in this mode, Simics still executes one step at a time, with varying timing for each step, so the simulation is still performing an in-order execution of the instruction flow. The basic step rate can also be changed; see the section Changing the Step Rate below.
Simics also has an extended timing control mode called Micro-architectural Interface (MAI). When running in MAI mode, step execution is completely under user control. Cycle events are still executed one cycle at a time, but no step execution is performed unless a user processor timing model is driving it. This user timing model is usually called every cycle to make instructions advance in the processor pipeline, stall, allocate resources, etc. Whenever an instruction is committed by the processor timing model, Simics increases the step counter, executes all step events related to this step and finally commits the step execution. From the point of view of event handling, Simics MAI is similar to the standard model, but the number of steps executed (or, in this case, committed) per cycle is entirely under user control.
Simics MAI transcends the standard model by providing an infrastructure for parallelized and speculative execution, allowing a much more accurate timing simulation of complex processors. Simics MAI mode is also called Simics out-of-order mode. A complete description of Simics MAI is available in the Simics Micro-Architectural Interface document. Note that Simics MAI is only available for the UltraSPARC and x86/x86-64 processor models.
Choosing an execution mode is matter of trade-off between performance and accuracy. As the timing control becomes more refined, the simulation slows down. Simics allows you to choose the execution mode dynamically (using checkpoints), so it is possible to use a simple model to reach interesting parts of the simulation quickly, then switch to a more complex model.
The step rate is the number of steps executed each cycle, disregarding any stalling. It is expressed as the quotient q/p. By default, p=q=1; this schedules one step to run in each cycle. This can be changed by setting the step_rate processor attribute to [q, p, r] where the last r parameter is a remainder to keep track of the relative phase of the cycle and step counters; set it to zero if you are not interested in sub-cycle accuracy. For example,
@conf.cpu0.step_rate = [3, 4, 0]
will set the step rate of cpu0 to 3/4; that is, three steps every four cycles.
If q<p, then some cycles will execute no step at all; if q>p, then some cycles will execute more than one step. The step rate parameters are currently limited to 1 <= p <= 128 with p=2k for some integer k, and 1 <= q <= 128.
Setting a non-unity step rate can be used to better approximate the timing of a target machine averaging more or less than one instruction per cycle. It can also be used to compensate for Simics running instructions slower than actual hardware when it is desirable to have the simulated time match real time; specifying a lower step rate will cause simulated time go faster.
The step rate is sometimes called IPC (instructions per cycle), and its inverse, the cycle rate, may be called CPI (cycles per instruction). The actual rates will depend on how many extra cycles are added by stalling.
Let us look at an example using a single Ebony card. We will first run 1 million steps with the default settings:
+----------------+ Copyright 1998-2005 by Virtutech, All Rights Reserved
| Virtutech | Version:
| Simics | Build:
+----------------+
www.simics.com "Virtutech" and "Simics" are trademarks of Virtutech AB
simics> c 1000000
[cpu0] v:0xfff8a610 p:0x1fff8a610 mftbu r5
simics> ptime
processor steps cycles time [s]
cpu0 1000000 1000000 0.010
The processor has run 1 million steps, taking 1 million cycles to execute them. Let us set the cycle rate to the value mentioned above, 3 steps for every 4 cycles:
simics> @conf.cpu0.step_rate = [3, 4, 0] simics> cb 1200000 simics> c Caught time breakpoint [cpu0] v:0xfff8a634 p:0x1fff8a634 bl 0xfff8a608 simics> ptime processor steps cycles time [s] cpu0 1900000 2200000 0.022 simics>
When running the next 1.2 million cycles, the processor executes only 900000 steps, which corresponds to the 3/4 rate that we configured.
It is possible to set the step rate to infinity, or equivalently, to suspend simulated time while executing steps. This is done by setting the step_per_cycle_mode processor attribute to one of the following values:
While time is suspended, the cycle counter does not advance, nor are any time events run. To the simulated machine this appears as if all instructions are run infinitely fast.
Conversely, it is possible set the step rate to zero, thus suspending execution while letting simulated time pass. This can be done by stalling the processor for a finite time (see Stalling above) or by disabling the processor for an indefinite time. Disabling and re-enabling processors is done with the commands <processor>.enable and <processor>.disable.
Using the same example as above, we set the step per cycle mode to "infinite" to prevent the simulated time from advancing:
simics> @conf.cpu0.step_per_cycle_mode = "infinite" simics> c 1000000 [cpu0] v:0xfff8a614 p:0x1fff8a614 cmpw r3,r5 simics> ptime processor steps cycles time [s] cpu0 1000000 0 0.000 simics>
The processor has executed 1 million steps but the simulated time has not advanced. Note that setting this mode would probably prevent a machine like Ebony from booting since many hardware events (like interrupts) are time-based.