Reconfigurable Baseband Processing for Wireless Communications - Adaptive Signal Processing in Wireless Communications - page 469

Very large applications or failed heuristic searches are often tackled with manual help
from a designer.
There is no general method for spatial mapping to all kinds of MP-SoC, because what
constitutes a good mapping depends heavily on the available resources of the MP-SoC
and the resource demands of the application. For example, when the number of proces-
sors per NoC node (multiple processors can be connected to a single router) is relatively
high, communication is likely to become a problem in the mapping. In such a case,
searches generally start of with determining the minimum bandwidth clustering of the
process graph into clusters that fit on a tile.
When using SDFGs, a great advantage of performing a spatial mapping at design
time is that a so-called static-order schedule can be calculated for actors mapped onto
the same tile. This means that the order in which the actors fire is known and the actors
are ordered such that they fire in sequence. If a static-order schedule is found, the sched-
ule can be implemented by grouping the actors together and compiling them into a
single piece of binary code for the tile, thereby eliminating the need for scheduling at
runtime and the overhead it would induce.
It is worth noting that tiles of architectures that do not have support for multitasking
can still be allocated to multiple actors, if such a static-order schedule can be found. This
follows directly from the fact that actors in a static-order schedule can be compiled into
a single binary executable.
15.4.2 Runtime Mapping
Performing the spatial mapping at runtime is necessary, whenever the application set
is not known completely at design time. This happens for a wide variety of reasons; for
example, when the platform allows the user to use software from any vendor, developed
for that platform. When different software vendors produce software for the same plat-
form independently, no one knows the complete application set. Also, when the resource
availability of the MP-SoC is not known beforehand, the spatial mapping must be found
at runtime. This can happen when tiles can be broken (by wear or by faults in produc-
tion), or when applications are developed, not for a specific MP-SoC, but for a class of
MP-SoCs that have the same types of tiles and the same type of interconnect, but in a
different configuration. Runtime spatial mapping in this sense is inherently ad hoc, i.e.,
only when an application is started will the system know what resources are available.
When mapping to a heterogeneous MP-SoC, having multiple implementations of
computational kernels for different types of tiles increases the options for the spatial
map. Performance figures—(expected) worst-case execution time, energy consumption,
etc.—of these implementations can be determined at design time. However, some fig-
ures of the applications simply cannot be determined at design time. Interprocess com-
munication parameters (e.g., estimated latency), for example, need to be determined at
runtime, as these are dependent on the specific mapping of the communicating pro-
cesses. Likewise, it is only known at runtime on which tile a process will be executed
and which processes are already running on this tile, so the actual execution time (often
referred to as response time in the synchronous data flow world) of a process is only
known at runtime.