Table 3.3: Comparison of approaches to synthesis of DDF and PN specifications.
MoC
(Language) Scheduling Mapping Evaluation Constraint
Hetero- geneity
Plishker [203] DDF (func. DIF) QSS – Host – ✗
Falk [78] DDF (–) QSS – Host, FPGA – ✗
Wiggers [272] DDF (OIL) Dynamic – Simulation Time ✗
Parks, Geilen,
Basten [17, 86, 197] KPN (C++) Dynamic – Host – ✗
Nikolov [191] (Daedalus) PPN (SANLPs , C+coord.) Static Evolutionary algorithms Simulation Time, Resources ✗ Edwards [70] (SHIM) Rendezvous-KPN (Tiny-SHIM) Dynamic – Host/Cell BE – X Keinert [130] (SystemCoDesigner) SDF, CSDF, ... (SystemC) Static, Dynamic Evolutionary algorithms Simulation Time, Resources ✗ Thiele [249] (DOL) PN (C+coord.) Static, Dynamic Evolutionary algorithms Simulation, MPA Time X MAPS SDF, KPN (CPN) Static, Dynamic Heuristics Simulation, Trace replay Time, Resources X
used to describe process interaction, while process behavior is specified in C. Using a co- ordination language raises the problem of consistency between two separate descriptions of the same application. Specifications that build on top of the C language are generally preferred because they provide a smooth transition from sequential codes.
The second and third columns in Table 3.3 describe how applications are mapped to the target platform. Most authors use evolutionary algorithms to compute a mapping. In this work, instead, heuristics are proposed that apply to different applications. Most of the heuristics are fast, allowing better user interaction. Additionally, heuristics can be more robust to inaccurate performance estimates, common in early software development phases. For instance, heuristic decisions based on the KPN topology would hold even with wrong time estimates. The fourth column describes how the synthesis results are evaluated. For fast exploration cycles, having an alternative to cycle-true simulations is a must. For this purpose, DOL uses MPA and MAPS a so-called trace replay mechanism. The next column displays the kinds of constraints that are supported by the different flows: time constraints (e.g., latency and throughput) and resource constraints. Finally, the last column shows that only a few frameworks truly support heterogeneous systems.
3.4
Software Defined Radio
The idea to move radio functionality from hardware to software was initially motivated by the military in the late 90s. This would allow a single platform to implement several radio standards. Today, there is a big community performing research in technologies for SDR, which will enable, among others, the deployment of cognitive radios.
3.4.1
SDR Approaches
Besides advances in the Radio Frequency (RF) frontend, the success of SDR greatly de- pends on new programming methodologies. An ideal SDR methodology should allow
54 Chapter 3. Related Work designers to describe a radio standard by means of a high-level language, enabling faster waveform development cycles and easier waveform migration across platforms. Three main solutions can be identified: Component-Based Software Engineering (CBSE) approaches,
library-based approaches and language-based approaches.
Today CBSE techniques (e.g., Fractal [28]) have found large acceptance and are widely used in many application domains. CBSE methodologies provide a well-structured and well-defined software development process on top of programming languages such as C/C++ or Java. However, employing such technologies directly is not an option in em- bedded systems targeting SDR solutions. They rely on infrastructures that are neither well suited for real-time computing (e.g., Java Virtual Machine), nor designed for plat- forms with heterogeneous processing elements and limited memory size. In the domain of wireless communications only few frameworks exist that target the specific needs of SDR systems, among them, Prismtech’s Spectra CX tools [205], Zeligsoft [285] and CRC Scari++ [33]. These frameworks are based on the Software Communication Architecture (SCA) [124], a standard from the Joint Tactical Radio System (JTRS) [123] which is widely accepted in the SDR community. Most of the SCA implementations are based on the Com-
mon Object Request Broker Architecture (CORBA) [246]. Despite recent speed improvements,
current CORBA implementations are not lightweight enough for baseband processing ap- plications. Due to this limitation, the aforementioned frameworks only apply to the MAC and above layers. These frameworks treat PHY-layer applications as a single component.
Several companies have coupled CBSE flows (e.g., Simulink) with SDR development boards, e.g., Lyrtech [168] and Coherent Logix [53]. The latter provides a complete flow from Simulink to a 100-core MPSoC [198]. In order to circumvent the problem of compil- ing directly from Simulink, the authors allow the user to write optimized C code for the platform and embed it into Simulink blocks. This mixture of CBSE and embedded opti- mized library functions is similar to this thesis approach. It is however, not generalized for several platforms into a suitable methodology.
Library-based approaches expose a high-level API that hides implementation details to the programmer. The API contains highly optimized functions, often programmed in assembly, for the most common algorithmic kernels supported in the target platform. This approach is commonly followed by commercial platform vendors such as TI. Libraries typically achieve a better performance compared to standard software implementations, especially when targeting irregular architectures, e.g., DSPs or ASIPs. However, they are, by definition, platform dependent and therefore not portable. Given the high variety of embedded processors and co-processor interfaces, it is unlikely that the community will agree on a single SDR API.
Language-based approaches provide more flexibility than library-based ones by adding language constructs to represent common operations. These operations can be then trans- lated to target-specific APIs. Püschel et al. [206] presented Spiral, a tool that generates optimized target code provided an abstract mathematical representation of the algorithm and a description of the platform. Such tools can be used to accelerate the process of library implementation, as the SDR case study in [265] showed. The authors claim that the abstract representation in form of the so-called Operator Language helps to overcome com- piler limitations. The Spiral technology has been recently used in the context of SDR [265]. However, developers are used to program in C and it is unlikely that a radically new specification language will be broadly adopted. In more conservative approaches, au- thors propose extensions to the C language [1, 180, 193]. They provide more information
3.4. Software Defined Radio 55
Table 3.4: Comparison of different approaches to SDR.
Specification Portability Efficiency Layer
Spectra CX [205], Zeligsoft [285]
Scari++ [33] SCA/CORBA XXX X MAC
Lyrtech [168],
Coherent Logix [53] Simulink ✗ XXX PHY
Optimized libraries
(Spiral [265], C-Dialect [180]) machine-code, low-level C X XX PHY
Shen [220] dataflow (C-based) XX XX PHY
MAPS KPN (CPN) XXX XX PHY
to the compiler, thereby improving performance but reducing portability. Moorby et al. [180] presented a C dialect for vector operations and memory management. Code written with this dialect is portable across different vector processors. Some language-based ap- proaches tend to become processor-specific and therefore share the drawbacks of library- based approaches. In general, new languages can achieve good performance, but at the cost of high investments in compiler technology, instead of reusing the compilers provided by the processor vendors.
Authors have also used dataflow programming languages to describe radio applica- tions. Shen et al. [220] proposed a design flow for SDR based on the DIF framework. They reuse the existing design processes, e.g., compilation and synthesis flows. Their flow includes functional verification of the waveform and final implementation on a target plat- form. Portability is achieved by defining function prototypes on header files, which is not as general and flexible as the approach presented in this thesis.
Finally, Yehia et al. [283] presented a work on so-called Compound Circuits that shares several similarities to the approach described in Chapter 7. They decompose algorithms into primitive HW components and then compose them in order to implement more com- plex algorithms. The final compound circuit is usually smaller than the sum of its parts, which makes it cost effective while retaining flexibility. This hardware-oriented method- ology complements the software-oriented methodology presented in this thesis.
3.4.2
MAPS in Perspective
The works presented in the previous section show two major driving forces in SDR: (1) A desire for a CBSE programming methodology to achieve cross-platform portability and programming efficiency, mainly pushed by industry and the military, materialized in the SCA, and (2) A quest for providing the full platform performance for algorithmic kernels, either via APIs or specific languages. The main characteristics of the existing approaches are listed in the first four rows of Table 3.4. Abstract programming models achieve better portability at the cost of efficiency.
The last row of the table stands for the extensions for SDR added to the MAPS frame- work. As discussed in Section 2.6.1, the nucleus methodology allows to combine the benefits of CBSE and library-based approaches. Optimized implementations (i.e., flavors) could be generated by an expert, e.g., using Spiral. Flavors could themselves be portable, if developed with a C extension for SDR, e.g., Open Vector Radio [180].
56 Chapter 3. Related Work