IEEE Consumer Electronics Magazine - March/April 2021 - 29

functionally equivalent no matter whether the
directives are honored or not.
The initial goal of OpenCL,5 first published in
2009, was very different. It targeted the use of
heterogeneous external accelerators, mainly
GPGPU (general-purpose computing on graphics
Processing Units), for which every vendor had at
that time a proprietary API (e.g., Nvidia's CUDA).
OpenCL consists of two main elements: a dialect of C or C++ to write compute-intensive pieces
of code called kernels that run on devices, and a
low level API that is used to define and control how
the kernels are to be executed on the available
devices. It is considerably more complex than
OpenMP, but that is not surprising as it intends to
be the " write once, run everywhere " of heterogeneous multicore computing. There are OpenCL
implementations from all major CPU and GPU vendors (Intel, AMD, Nvidia, ARM, Qualcomm...), but
also for multicore DSPs (digital signal processors)
from Texas Instruments or FPGAs (field programmable gate arrays) from Xilinx and Intel. Also, some
vendors have provided OpenCL support for somewhat unconventional architectures, such as manycore based products like Adapteva's Epiphany or
Kalray's MPPA. Some of these implementations,
however, seem to have lost momentum and have
not been updated for some time.

Other Approaches
There are other development strategies that
either are intended or can be used to write parallel software radio applications. They are often
based on dataflow models of computation, to
which software radio is inherently well suited.
Two examples are PREESM,6 which can be used
with several target platforms from desktop computers to DSPs or FPGAs, and the one described
by Dardaillon et al.,7 which targets an experimental NoC (Network-on-Chip) based heterogeneous
multicore platform.
Another approach is that of domain specific
languages, such as Ziria8 for commodity processors or SdrLift,9 which is aimed at high-level synthesis of FPGA datapaths from algorithmic
descriptions of actors behavior.
Finally, model-based design tools can also be
used, either by themselves or augmented with
hardware vendor supplied libraries, to prototype and develop software radios.

March/April 2021

EXAMPLES OF SOFTWARE RADIO
IMPLEMENTATIONS
We will discuss now on the suitability of the
standards described in the " Standards-Based
Methodologies " section for the development of
software radio applications, specially on the
embedded platforms that are usually employed
for consumer electronics devices.
Examples of OpenMP in embedded systems
are given by Nikishkin et al.,10 where an eightcore DSP is used for orthogonal frequency division multiplexing symbol generation; or by Sever
and C¸avus,11 where a low density parity coding
decoder is implemented on the same DSP.
OpenCL has been also used to implement the
same algorithm in a related processor by Kharin
et al.12
OpenCL is sometimes the programming tool
of choice for nonconventional specialized processors. A good example of this are the works
described by Kultala et al.,13 where the critical
parts of a Turbo decoder are implemented on a
transport-triggered architecture based processor,
and by Kultala et al.,14 where two algorithms for
multiple input multiple output detection are compared using a similar architecture.
In all these examples, only one algorithm, or
even only part of one algorithm, is accelerated.
This is usually the case not only on embedded
platforms, but also on desktop computers. In
general, we think that it is safe to say that both
OpenMP and OpenCL are better suited to applications that have just one compute-intensive
algorithm to accelerate. OpenCL supports the
notion of device partitioning to exploit task parallelism, but its use is not very extended and can
sometimes lead to serious performance penalties, as reported for example by Piscopo.15 We
refer the interested reader to the work done by
Jaaskelainen et al.,16 which contains a discussion
on OpenCL usage patterns and the performance
of multiple kernels running simultaneously.
It is worth noting that, especially in embedded platforms, sometimes one of the APIs get
better results than the other due to the characteristics of the vendor implementation. For
example, in the work by Vicente et al.17 a Raptor
FEC (forward error correction) decoding algorithm is implemented in two mobile platforms
that support GPU acceleration, and the results

29
IEEE Consumer Electronics Magazine - March/April 2021

Table of Contents for the Digital Edition of IEEE Consumer Electronics Magazine - March/April 2021
