Simics is a system-level instruction set simulator. This means that:
- Simics models the target system at the level of individual instructions,
executing them one at a time.
- Simics models the binary interface to hardware in sufficient detail that any
software that runs on the real hardware will also run on Simics.
In practice, what this means is that there is no code that is too
“low-level”—Simics can run, and debug, any kind of software: firmware, hardware
drivers, operating systems, user-level applications, whatever. There are some
caveats, though:
- Simics’s model of time is rather simple; for example, it assumes by default
that all instructions take the same amount of time to run. It is not difficult
to write a program that uses this fact to detect the difference between Simics
and real hardware. However, this is seldom a problem with real-world software.
You can read more about Simics and time in the Understanding Simics
Timing application note.
- The hardware models must be detailed enough. Models of nontrivial pieces of
hardware do not typically model all functions and details of that hardware, so
it is possible to write a program that detects the difference between Simics
and real hardware by probing unimplemented functions. However, any given piece
of software can be accommodated by extending the hardware models to cover the
missing functions.
You can read more about hardware modeling in the Model Builder User’s
Guide.
Simics has powerful built-in inspection and debugging facilities. These include:
- Inspecting registers, memory, and hardware state.
- Modifying register and memory contents, and hardware state.
- Setting (and triggering) breakpoints and watchpoints.
- Powerful scripting support for all of this.
Because these are implemented in the simulator, no debugging software needs to
be on the target at all. As a result, the debugging machinery is completely
invisible to the target (and thus to any software running on it).
One of the most powerful properties of full-system simulation is that time
inside the simulation and time in the real world are two completely different
things. This brings a number of substantial benefits:
- You can pause the simulation at any time, and the software running in the
simulation simply cannot detect this. This allows you to inspect (and
optionally modify) the state even at points where real hardware would be
unable to stop.
- You can save the state of the simulation to disk (this is called a
checkpoint), and start again from that point at any time, any number of
times.
- The simulation is completely deterministic. Every time you start from the same
state (such as a checkpoint), the exact same thing will happen. This can be
tremendously useful when hunting down certain types of bugs.
These advantages apply to the entire simulated system, whether it is a single
target machine or an entire network.