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

Thus, when a function in the library calls another function or global variable, it
uses the elements inside the library, instead of accessing the elements of the main
program. Only when a name is not resolved inside the library, the main program or
other shared libraries are accessed. To force the program to use the internal library
elements, the library visibility has to be declared as protected . To do so, when
creating the library, it is required to specify the compilation flag:
-fvisibility = protected
Using this flag, it is only required to indicate the entry points of each component
description in the XML files to enter the visibility scopes. Once the starting function
of the correct library is entered, all internal operations of the component descrip-
tion will be isolated within the library, and without having or producing external
interferences.

2.5.3.2 Modeling Separate Memory Spaces

Providing different visibility scopes guarantees integrating independent component
descriptions in a single executable. However, if a component is instantiated twice,
global variables are shared. In real SW implementations, the memory space separa-
tion provided by the OS for each process solves the problem. Thus, the simulation
framework must provide an equivalent solution.
Using different host processes to create the SystemC simulation is a possible
solution to achieve that. However, inter-process communication mechanisms, and
additional context switches required to perform the simulation makes the solution a
bit complex to use.
A more easy solution to solve the problem of multiple instances is to create a copy
of the shared library for each instance. It provides an automatic solution which is
easy to implement. Storage requirements are increased as several copies of the files
are created. Nevertheless, disk sizes of host computers are usually large enough.
Using dynamic links ( ln -s ) instead of copies is not a valid solution, as the linker
uses the final node directly.

2.6 Simulation Results

As a simulator oriented to evaluate different configurations of software centric
systems, the most important parameters required to demonstrate the validity of M3-
SCoPE are estimation accuracy and simulation time. The estimation accuracy of the
simulator covers two main aspects: the evaluation of the performance of the soft-
ware code and the modeling of the effect the software execution has in the rest of the
system. The first aspect can be checked by comparing the time estimated by the tool
and by an ISS (e.g. Skyeye [ 56 ]). The second aspect can be evaluated verifying the
amount of data injected by the software modeling in the system buses, which means
checking the number of cache misses estimated by the tool and by the ISS.