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

Fig. 2.12 Process for
complete handling of HW
accesses directly using
pointers

Peripheral
Access

Peripheral
Access

2

Application
SW
...
...

SIGBUS raise
and capture

Injected code
execution

Start-transfer
event

*addr = value;

End-transfer
event

Map memory
region

Native
Simulation

Unmap
memory area

Code
injection

Code
recovering

Furthermore there is an another issue with the solution above. Detecting if a
pointer access is a reading or a writing one is also complex. A possible solution is to
disassemble the binary code of the instruction provoking the error, but this solution
is not portable. Moreover, in x86 processors both reading and writing accesses are
performed with "mov" instructions, so it is not easy to distinguish both. The portable
solution is to force the system to raise different signals for read and write accesses.
When executing an I/O pointer access, a SIGSEGV signal is obtained if the memory
address has not been mapped. If the address has been mapped but the associated
file has 0 size, a SIGBUS signal is raised. Thus at initialization the address is only
activated for reading accesses with an empty file. Thus, a SIGSEGV raises at writing
accesses (there is no writing permission) and a SIGBUS raises at reading accesses
(there is no area in the associated file). This way one can differentiate between read
and write HW peripheral accesses. More details on this scheme can be found in [ 50 ].

2.4 HW Platform Modeling

Once the software modeling has been defined, it needs to be connected to a HW
platform for HW/SW co-simulation. For this purpose, an intermediate infrastructure
is proposed. This infrastructure is placed in the OS model and in the target platform
modeling facilities.
The SW modeling facilities presented above in Sect. 2.3 require a bus and, some-
times, a network interface to simulate a real communication of the SW with the rest
of the platform. The bus model has to interact effectively and efficiently with the
HW, thus a simple and flexible HW interface is integrated. This interface allows
connection not only to generic HW components provided by the tool, but also to
user-provided HW modules written in SystemC. For that purpose, three auxiliary
HW models are needed to model a complete communication framework: a network