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

Mapping HW peripheral accesses to a created memory page in native memory
space results in another issue. These peripheral accesses from SW usually commu-
nicate particular event notification to the HW. Hence these HW peripherals must be
notified about these HW access events. HW Peripherals are not designed to make
polling of any variable. They react to read or write accesses from the system proces-
sors. Even in case of using a high-level model for the HW peripherals, it will also
be based on such event-based communication. Whereas in technique presented in
the previous section, the access is performed but the peripheral does not receive any
event informing that a read/write operation has been performed in their registers.
The only way to produce the event is not to map HW access to a created memory
page and let the simulation crash. When the simulation is going to crash due to the
segmentation fault, the error can be captured, solved and then the simulation can
continue. The advantage of this approach is that the HW access is detected and the
event can be sent to the peripheral model. When the SW tries to access an invalid
memory address, the native operating system raises a SIGSEGV signal. This signal
can be captured with an appropriate signal handler. This prevents the program to
terminate, but this solution creates another challenge. During the signal handler,
neither the access type (read/write) nor the value are known. Hence, the HW access
cannot be performed at the signal handler.
To obtain the data, the memory remapping technique presented in the previous
section is used. At the signal handler the memory mapping is activated and the code
returns to repeat the pointer access. To perform a correct read access, the read transfer
to the virtual platform is done first, updating the necessary memory address. Thus,
when retrying the pointer read, the value obtained is correct. To perform a correct
write access, the pointer access is performed first, and after that the new value is sent
to the virtual platform.
Performing an "mmap" allows retrying the instruction, but once an access has been
performed, the memory page is active and further accesses are not detected. To solve
that, the memory page must be unmapped. However, when the code returns from the
failed instruction, it continues normally without unpin the page. A possible solution
is to create a parallel thread that wait for a certain time and then unmaps the page.
However, this is an unsafe solution. There is no guarantee that there will be no more
accesses before the unmap step, and even there is no guarantee that the unmap is
done once the application SW code continue the native simulation.
To unmap the memory page properly, the SW code itself must do it. Just after the
memory access is performed, the page must be unmapped. To do that, the original SW
code must be modified. The solution applied is to dynamically inject code after the
load/store assembler instruction that provoked the error. This injected code disables
the memory page, re-establish original SW code and continues the execution. As a
consequence, when the HW access is performed, the peripheral model is informed
and the simulation status returns to the correct point to detect new accesses. Although
the memory page is unmapped the data stored are not lost. The values are saved in
the file associated to the memory page. The entire process is summarized in Fig.
2.12 .