| SID Simulator User's Guide | ||
|---|---|---|
| <<< Previous | Next >>> | |
A simulated environment provides embedded software developers with a number of advantages over a typical hardware model. Working in a simulated environment provides a rapid way to examine the complex interactions of the embedded software on the simulated hardware system.
SID is a simulation framework for supporting embedded systems software development. It features a modular architecture of loosely-coupled software components that interact with each other to simulate the behavior of physical hardware parts. This modularity allows users or programs to monitor or interact with a running simulation.
SID insists on a decomposition of a simulation into independent components that share a fixed low-level API, which defines all possible inter-component communication mechanisms. The API is small and general, on which application- or device-specific behaviors are layered.
SID typically reads configuration files to create and manage the web of low-level connections between all needed components. A configuration file may spell out the model of an entire hardware development board, or may add instrumentation to an existing model.
The SID package includes many types of components. The component types fall into the following categories:
hardware model
software model
bridge
special function
A hardware model type component simulates some sort of target hardware device, so it tends to connect to other components through hardware-oriented connections.
Examples include:
a CPU, hw-cpu-arm7t
a hard drive interface, hw-disk-ide
an address space decoder/mapper, hw-mapper-basic
memory, hw-memory-ram/rom-basic
a teletype, hw-visual-tty
These tend to be the busiest components in a running simulation.
A software model type component crosses the hardware-software abstraction boundary by emulating the operation of target software.
Examples include:
a ROM monitor, sw-gloss-arm/angel
a debugging stub, sw-debug-gdb
profiling instrumentation, sw-profile-gprof
an executable loader, sw-load-elf
A bridge type component crosses simulation implementation language boundaries by mapping between a different API and the SID low-level API. It allows a foreign simulation system to impersonate a SID component, and sometimes vice versa.
Examples include:
a Tcl/Tk bridge, bridge-tcl
A special function type component carries out tasks related to the infrastructure of the simulation, or crossing the target/host abstraction boundary.
Examples include:
an event scheduler, sid-sched-sim
a configuration manager, sid-control-cfgroot
a host network interface, sid-io-socket
| <<< Previous | Home | Next >>> |
| About this Manual | Communication Between Components |