M3-SCoPE: Performance Modeling of Multi-Processor Embedded Systems for Fast Design Space Exploration - Multi-objective Design Space Exploration of Multiprocessor SoC Architectures - page 43

Software tasks are defined in the XML System Description file indicating the
name of the main function of the task. To load the main function, dynamic library
management provided by OS is used, by calling the dlopen and dlsym function.
Additionally, other parameters like the OS where it will run, priority, policy and the
main function arguments can be defined. All these elements can be parametrized, so
the DSE flow can explore the best configuration for the SW tasks.

2.5.3 Integration of Independent Component Codes

During the system model creation, multiple HW and SW components are integrated
in a single SystemC simulation. When integrating different components in a system
model, the models of each component can be incompatible for simultaneous inte-
gration in a single executable. If component models contain global variables and
functions, name duplication problems can appear. This is especially important when
integrating SW codes or algorithmic codes, where global variables are really com-
mon. If two components contain elements with the same names or a component is
instantiated more than once, it will cause linking errors during compilation. Recod-
ing of the system components can solve the problem, but it results in a very costly
and error prone task.
To allow reusing names, two direct solutions have been considered in M3-SCoPE
[ 53 ], considering “direct” as solutions without requiring recoding or any additional
design effort. The first solution is to declare all functions and global variables as
static . That way, the names are local to the object “.o” files. Then, when linking
all the object files generated by applying this solution, the linkage is correct.
However, this solution presents four main limitations. These limitations will be
overcome during next sections applying different approaches. The main problems
are:

￿ First, it requires recoding, as it is required to add the static qualifier before the

declarations. Thus, it cannot be called a “direct” solution.

￿ Second problem is that this solution is only applicable if each component is

isolated in a single object file. If the system component description is divided in
several object files, the functions and variables are not visible by the rest of the
component object files. Considering that dividing functionality of SW processes
and algorithms in C/C++ in several object files is usually considered a good
programming practice, the solution is not recommended.

￿ Third problem appears when a component is instantiated several times. If a com-

ponent using global variables is instantiated more than once, all instances will
share global variables. This will generate interferences among the instances and
will end in wrong system operation.

￿ Fourth problem is that this solution can only be applicable to internal functions and

variables. For example, if we want to integrate several SW processes, all starting