Running a program in Simics is not the same thing as running it on real hardware in the general case. Simics should be viewed as one possible implementation of the architecture, where physical hardware is another. They both comply with the hardware architecture, as defined by the architecture documentation, but the implementations will differ and one of the most important differences is timing. One could differentiate between the timing and the function of a system. The function of a system can be thought of as the state changes the system goes through, given the current state and inputs. These state changes are usually described in a programmer's reference manual or similar document, and they need to be modeled correctly by a simulator. The timing on the other hand is when these state changes occur. It is common that this is not defined by the architecture and thus, there is some headroom for the simulator to make its own choices.
The timing may differ between hardware and simulation model for a number of reasons:
In Simics the most evident timing difference compared to real hardware is instruction timing. In real hardware, the instruction timing depends on memory access latencies, the complexity of the operation, execution resource contention, etc. These things are not simulated by Simics by default. Instead, one instruction is normally simulated each cycle. The simulation of the execution of one instruction is called a step. It is possible to configure a Simics processor to execute more or less than one step per cycle. It is also possible to have two or more processors in one simulation, where each processor has a unique clock frequency. In multiprocessor simulation time advances on one processor at a time, in a round robin fashion. Each processor advances a fixed amount of simulated time, called a quantum, before switching to the next processor. Even though each quantum has the same duration in simulated time, processors may simulate a different amount of steps, depending on their frequency.
Simics offers the possibility to stall memory transactions. This is a common way to affect instruction execution timing to make the simulation more realistic. Memory transaction are usually initiated by a processor and sent to a memory space. The memory space will in turn decide where the memory transaction should go based on its mappings. Each memory space provides the memory hierarchy interface. This interface provides a way to inspect and even alter a memory transaction passing through the memory space, both before and after the actual transaction has executed. In addition, the memory hierarchy interface lets a user stall the transaction. This is how caches are modeled in Simics. It is important to know that all memory transactions are not visible through the memory hierarchy interface by default. During normal operation, instruction fetches are not visible at all, and some data access are not sent to the memory space. Simics caches the result of a memory space look-up so that further access to the same area does not have to do the look-up again. This is done to increase performance. However, Simics can be configured so that all memory transactions are visible through the memory hierarchy interface.