Previous - Up - Next

3.4   Advanced Tweaks

3.4.1   Platform specific notes

The workspace setup script has a default set of make-variables (CC, CFLAGS, etc.), which are setup in the and [simics]/config/ files. If you need to change any of the variables in, you may override them in The may be edited by the user.

The makefile with the actual build rules for all modules is [simics]/config/ This file is included at the end of each module Makefile. To override rules or variables in this, add a file in the workspace, similar to the file described above.

There is a special wrapper utility called cygwrap which is used for launching native windows binaries, which converts the Cygwin-style paths used by GNU make to native paths. It also does some argument translation, for example, to allow the LIBS variable to contain Unix-style -l library options.

The default set of variables assumes that you will be using GCC. If you want to use a different compiler, you need to change the CC variable in The flags for the compiler are setup in [simics]/config/

If your compiler is not supported by, please report to Virtutech.

3.4.2   Module Makefiles

In order to make the build environment in Simics recognize a module as a build target, there must be a makefile called Makefile in its source directory.

A module makefile must set up a number of make variables and then include the generic makefile for Simics modules. The following is an example of a module's Makefile, for a module written in C:






The user can also add new rules to the makefile, either before or after the inclusion of the generic $(MODULE_MAKEFILE). This is usually not needed.

The following variables can be used in the module's makefile (i.e. [workspace]/modules/<module>/Makefile). They should be considered read-only, i.e. they should not be changed.

3.4.3   Standard Module Host Defines

There are a number of defines that are set depending on the host that the module is being compiled on. They are usually not needed, but useful in some special cases. Examples: HOST_64_BIT, HOST_32_BIT, HOST_BIG_ENDIAN, and HOST_LITTLE_ENDIAN. There are also defines specifying the host architecture and host operating system. All these defines are set in the Simics include file global.h.

3.4.4   User Defined Module Version Numbers

It is possible to set a user defined version number (or string) in loadable modules. This is done by setting the USER_VERSION define in MODULE_CFLAGS in the module's Makefile. The version number will be printed by the list-modules and list-failed-modules commands.

3.4.5   Module Loading Support

When Simics starts, it will check all modules for their supported architecture and word size. Only modules that match the running Simics binary will be available for loading into Simics. While scanning the modules, Simics will also check what classes the module will register when it is loaded. This way modules can be loaded automatically when classes they define are used in a configuration.

If a module does not match the current Simics, it will be added to the list of failed modules. This list can be displayed with list-failed-modules, that takes an optional parameter -v for more verbose output.

simics> list-failed-modules

Current module version number: 1050  Lowest version number supported: 1050

8042                   1040
image                  1040                          X

The columns after the module name (or file name in the case of a link error) indicate different kinds of errors. An X in the DUP column means that this module could not be loaded because this module has the same name as another module found in the Simics module search path, and that this one was overridden. An X in the VERSION column means that the module was created for another, non-compatible, version of Simics. LINK means that this module cannot be loaded into Simics because of unresolved symbols. Use list-failed-modules -v to see the actual error message from the run-time module loader.

Previous - Up - Next