Using SID

Running SID

SID is essentially a batch process. It reads a configuration file (see the chapter called Working with the SID Configuration File>) and executes its contents. Thus the basic invocation interface is simple; the hard part is writing a complete, useful configuration file. There are two ways, commonly, of using SID: direct invocation on a task-specific configuration file, and through a wrapper that sets up a more generic simulation environment.

Direct invocation

The most direct (and flexible) way of running SID is with the command-line:

sid [-h] [-n] [-f FILE] [-e LINE] [CONFIG_FILE...]

Table 1. SID Options

OptionMeaning
-hprint this help
-nload/check configuration but do not run simulation
-f FILEalso read configuration FILE
-e LINEalso do configuration LINE

All -f/-e options are performed first, in sequence. Any CONFIG_FILE names supplied without -f are done last, in sequence.

Example 1. SID invocations

sid arm7t-config

runs the simulation environment described in arm7t-config

sid -e 'set angel command-line "simulated banana"' arm7t-config

executes the supplied configuration line (setting the command line to "simulated banana") and then runs the simulation environment described in arm7t-config

sid -f special-settings arm7t-config

executes any directives in the file special-settings, then runs the simulation environment described in arm7t-config

Invoking SID this way is simple, but requires a detailed configuration file CONFIG_FILE in order to perform any interesting simulation tasks. Since many components and connections will vary only slightly between simulation runs, it is often beneficial to introduce a "wrapper" program which automatically constructs configuration files from common idioms.

Invocation through a wrapper

A common wrapper around the sid binary is the perl script configrun-sid, which accepts more customization options and writes a temporary configuration file containing a relatively common arrangement of CPU, memory, gloss, scheduler, mapper, I/O and debugger components, representative of an embedded system "target board". It is invoked with the command-line

configrun-sid [--help] {--cpu=CPU} [--verbose] [--save-temps]
[--trace-extract] [--trace-semantics] [--trace-core]
[--memory-region=BASE,SIZE [,read-only | ,alias=BASE2 | ,file=FILENAME | ,mmap]]
[--gdb=PORT] [--board=BOARD] [--engine= [scache | pbb]] [-EB | -EL]
[--tksm] [--persistent] [--no-run] [--insn-count=N] [--gprof] [--wrap=COMPONENT]

Table 2. configrun-sid Options

OptionMeaningDefault
--helpPrint this help message. 
--cpu=CPUSelect target processornone
--verboseTurn on various run-time verbosity settings.no
--save-tempsKeep generated sid configuration file.no
--trace-extractTurn on CPU insn decode tracing.no
--trace-semanticsTurn on CPU insn execute tracing.no
--trace-coreTurn on bus access tracing.no
--memory-region=BASE,SIZEAdd RAM region from BASE to BASE+SIZE-1. Additional options may be appended, separated by commas: read-only flags this region as read-only, alias=BASE2 adds an alias to this region at BASE2, file=FILENAME loads and saves this memory region from a file, and mmap memory-maps such a file rather than loading it.no
--gdb=PORTAdd a gdb/debugger interface on TCP port.none
--board=BOARDModel given board or system.gloss
--engine=scache|pbbSet given cgen CPU engine.pbb
-EB | -ELSet powerup CPU mode to big/little endian.auto
--tksmAdd an experimental Tk system monitor.no
--persistentRerun top-level loop indefinitely.no
--no-runMake config file (--save-temps) and exit.no
--insn-count=NBlock of uninterrupted ticks for insns.10000
--gprofGPROF-profile, collect every N ticks.no
--wrap=COMPONENTTurn on SID API tracing for named component.none

Typically, if SID is built along with a GNU toolchain, the build process also produces a wrapper shell script around configrun-sid, such as arm-elf-sid, which in turn executes configrun-sid ---cpu arm. This is simply for uniform naming with the other target-specific portions of the toolchain, such as arm-elf-gcc or arm-elf-ld.