Efficient And Portable SDR Waveform Development: The Nucleus Concept
Venkatesh Ramakrishnan, Ernst M. Witte, Torsten Kempf, David Kammler, Gerd Ascheid, Heinrich Meyr, Marc Adrat, Markus Antweiler
aa r X i v : . [ c s . I T ] J u l This work has been submitted to the IEEE milcom 2009 conference for possible publication. Copyright may betransferred without notice, after which this version may no longer be accessible.
EFFICIENT AND PORTABLE SDR WAVEFORM DEVELOPMENT: THE NUCLEUS CONCEPT
Venkatesh Ramakrishnan, Ernst M. Witte,Torsten Kempf, David Kammler,Gerd Ascheid, Rainer Leupers, Heinrich Meyr
Institute for Integrated Signal Processing Systems,RWTH Aachen University, [email protected] and
Marc Adrat, Markus Antweiler
Research Establishment for Applied Science (FGAN),Dept. FKIE/KOM, Wachtberg, [email protected]
ABSTRACT
Future wireless communication systems should be flexibleto support different waveforms (WFs) and be cognitive tosense the environment and tune themselves. This has leadto tremendous interest in software defined radios (SDRs).Constraints like throughput, latency and low energy demandhigh implementation efficiency. The tradeoff of going for ahighly efficient implementation is the increase of portingeffort to a new hardware (HW) platform. In this paper, wepropose a novel concept for WF development, the Nucleusconcept, that exploits the common structure in variouswireless signal processing algorithms and provides a wayfor efficient and portable implementation. Tool assisted WFmapping and exploration is done efficiently by propagatingthe implementation and interface properties of Nuclei. TheNucleus concept aims at providing software flexibility withhigh level programmability, but at the same time limitingHW flexibility to maximize area and energy efficiency. I. INTRODUCTION
Flexibility in modern radio devices has been proposed toserve different goals, such as efficient multi-modal or multi-standard transmission in order to support compliance withnew and old WFs, promote interoperability and reductionof costs via modular and parametric design. Furthermore,system cognition results in high flexibility requirements,which need to be efficiently addressed by the transceiverleading to a solution like SDR system.One of the key requirements for flexibility is WF porta-bility across various HW platforms. Portability cannot bedefined as a binary term but as an inverse to the portingeffort [1]. Portability can offer several key advantageslike implementation reuse and fast time-to-market. It isalso a goal of the joint tactical radio system (JTRS)program [2]. Pure software solutions for a SDR offermaximum portability. Due to low implementation efficiencyand tough throughput, latency constraints pure software
This research project was performed under contract with the
TechnicalCenter for Information Technology and Electronics (WTD-81), Germany. radios are not yet feasible. Therefore, currently some ofthe processing intensive components are still implementedin dedicated application-specific integrated circuits therebylimiting portability.WF implementation in C/C++ is portable, at-least, acrossplatforms with programmable processing elements (PEs).But the implementation is not efficient enough to meet therealtime constraints. For example, assembly can be moreefficient by one order of magnitude than a C program [3].WF implementation at such a low level needs tremendousporting effort. Furthermore, C/C++ is not able to provideadequate support needed for physical (PHY) layer signalprocessing e.g. fixed point types, circular buffers, etc.Therefore, one of the key challenges that needs to beaddressed in SDR development is to enable WF portabilityand maintain implementation efficiency at the same time.This challenge is currently addressed by raising theabstraction level for WF implementations leading to librarybased approaches. As depicted in Figure 1, the basis of cur-rent approaches [4–7] is a library with basic components ofa few WFs. A component X is shown as CX in Figure 1. TheWF is constructed as a structured assembly of components,each of the components implementing a part of the WFfunctionality [8]. Figure 1. Traditional Library Based Waveform Development
The library provides efficient implementations of somebasic components. From a platform independent model(PIM) of a WF a platform specific model (PSM) can be his work has been submitted to the IEEE milcom 2009 conference for possible publication. Copyright may betransferred without notice, after which this version may no longer be accessible.derived using the library. The advantage of this approachis that the same PIM can be used for porting to anotherHW. Also, it is flexible to develop components of differentmodels independently. Library based approaches enable ef-ficient utilization of heterogeneous multiprocessor system-on-chips (MPSoCs) due to the presence of hardware-awareimplementations.Currently, vendors maintain their own custom-built li-braries for their platforms. Most of them are inaccessibleto the public. There are no criteria for selecting componentsfor the library which is crucial for a common library.We believe that the standardization of the library and its(components) interfaces is necessary and will lead to thedevelopment of a waveform description language (WDL).This will enable vendors not only to describe the WFs usingthis library but also to provide efficient implementations.Some important aspects which have to considered whenbuilding such a library are highlighted in the next section.This paper proposes a new concept to enable WDL basedWF development offering the following contributions • An analysis is made on existing SDR WF develop-ment approaches to highlight portability and efficiencyissues. • A new concept is proposed for tool assisted, portableand efficient WF development. Details on processes ina WDE are also presented. • Challenges in envisioning the concept are highlighted.II.
RELATED WORK AND MOTIVATION
Various solutions have been existing for developingSDRs. Solutions differ in portability, efficiency, usage ofWDL, component granularity and reusability. This sectionprovides an overview of some of the solutions and motivatesthe need for our Nucleus concept.Many library approaches that exist for WF developmentare component based and/or model driven [4–7]. As il-lustrated in Figure 1, some of the approaches [5, 6] havedeveloped libraries for one particular HW platform (HW-specific). Others like [7, 9] have developed special librariesfor one WF (WF-specific). Some library approaches areeven both HW and WF specific. For example, the libraryin [7] has been designed to support one type of WF,WiMax (with several modes), for one fixed HW usinga TMS320TCI6482 DSP. The specifics of the above ap-proaches limits porting of WFs. Since the componentsthemselves and their interface are not standardized, imple-mentations from different vendors are not compatible inmost scenarios and therefore lead to high integration effort.Furthermore, the components of the library are functionalitybased (e.g. modulator/rake receiver). This results in limitedcommonality among WFs leading to a reduced reuse of components and a huge implementation effort for a newWF. For example, when a WF uses a different modulationscheme whose component is not present in the library, thecomponent has to be implemented. Such a functionalitybased library cannot be used for specifying a WF and willnot lead to a WDL. A library of algorithmic kernels, usingwhich the functionalities can be built, will improve usageamong WFs.The term WDL has been first introduced by E.D.Willinkin [10]. The need for a WDL arises from the specification-to-implementation problem. Specifying WFs using textualor mathematical/formal methods is not efficient enough forautomated implementation. A WDL aims at capturing theWF specification by a behavioral model and derive theimplementation automatically. Though a WDL library isdiscussed, details about the library and portability issuesare not provided.In [11], Gudaitis presents a WDL concept based onthe unified modeling language (UML), Matlab and theextensible markup language (XML). The FM3TR WF hasbeen used as an example to demonstrate the concept.Though language components of a WDL are presented,information about the WDL library, reusability, realizationand portability is not given.The radio description language developed by Vanu Inc,targets WF portability [12]. However, they have used C++as signal processing implementation language. It is alsomentioned that few components (referred to as modules)were reused unchanged from previously built WFs. But,information about the compute-intense (demanding) and thereused components is lacking. This is necessary becausehighly demanding components need to be optimized to meetthe WF requirements. The portability effort is highly influ-enced by demanding components. From our investigations([1, 3]), implementation efficiency is low when a high levelgeneral-purpose language is used even with good compilers.A methodology for selecting the components (referredto as common operators) for SDRs has been proposed in[13]. Similar to other existing library based approaches, theauthors concentrate on identifying the common parts thatexist in the implementation of functionalities and not onthe algorithms. Moreover, portability and mapping issuesare not considered.Few other important aspects have to be considered whentargeting a library based approach enabling WDL. The datarate of near-future mobile systems will be in the orderof few hundred Mbits/sec requiring a processing power ofhundreds of Giga operations per second. For such compute-intense systems, energy efficiency will be the key factor forthe system design. HW platforms made up only of PEs withgeneral purpose architectures cannot provide the required his work has been submitted to the IEEE milcom 2009 conference for possible publication. Copyright may betransferred without notice, after which this version may no longer be accessible.efficiency. Heterogenous MPSoC platforms with multipleprocessors having special architectures are better candidateswith limited HW flexibility in order to gain efficiency.In general, the selection of an algorithm has a hugeimpact on the performance. One algorithm that is good forone operational scenario might not be good for another.Hence, it is necessary for the WF developer to have theflexibility of exploiting different algorithms even with afixed HW platform.The granularity of the components is another importantaspect that heavily influences re-usability and efficiencyin a library based WDL. If the components are too fine-grained, like a subtractor in [10], it is inefficient to use themfor constructing a WF. If they are too coarse-grained, likea complete convolutional decoder in [12], it limits reuse.Also, providing optimized HW implementations based onsuch components is not efficient due to limited re-use.Therefore, the granularity should be between the two ex-tremes representing a substantial part of WFs (critical) andthe same time enabling re-use.Even with a competent library, spatial and temporalmapping of a WF on a HW platform is a key factor that de-termines overall system efficiency. For an efficient mapping,the WF description should encode the information about itsideal mapping. This information could be implementationproperties like bit-width, type of scaling, etc. which canprovide huge performance difference. The library and itscomponents should be build such that it provides theseproperties using a WDL in an abstract manner. Tools in thewaveform development environment (WDE) can use theseproperties to assist the developer for efficient mapping.New SDR design approaches, in addition to being neitherWF nor HW specific, should consider the above aspects dur-ing system design. Such approaches should enable (semi-)automatic generation of the implementation from the WFdescription that is not only efficient but also portable.III.
THE NUCLEUS CONCEPT
To overcome the drawbacks of traditional library basedapproaches, a new classification of library elements calledNuclei is proposed targeting reusability, portability and im-plementation efficiency. Considering the important aspectsfor a library based WF development, the Nucleus conceptapproaches system design by the following key principles: • Limit HW flexibility to the minimum required level(for example, architecture of PEs, communications andmemories) • Maximize area and energy efficiency • Manage/exploit flexibility by means of high level pro-grammability A. DEFINITIONS • Nucleus : A Nucleus is defined as a critical, demand-ing, flexible, algorithmic kernel that captures commonfunctionalities within and/or among WFs. • Genre : A Genre is defined as a set of algorithmscontaining the same Nucleus. An example for a Genreis illustrated in Figure 4. • Flavor : A Flavor is defined as an efficient and op-timized implementation for one Nucleus. There canbe several Flavors for one Nucleus. The Flavors canbe based on several algorithms. Each or all of theFlavor(s) can have tunable parameters. B. METHODOLOGY
As shown in Figure 2, the concept proposes to builda library of kernels from a class of WFs. A Nucleuskernel is shown as N in the figure. These kernels areof algorithmic nature and do not need to represent anyWF or implementation specific features. The library formsthe basis for constructing a WF from the specification(Figure 2). Figure 2. The Nucleus Concept
The key difference to the component-based WF develop-ment is that the Nuclei represent not only the functionalityof signal processing blocks on a different level of ab-straction, but also their properties required for exploration.Properties that affect the WF performance are essentialfor exploration. Therefore, information on the input datastructure, bit-width, type of scaling, usage of truncation orrounding etc. will be abstracted and provided to the WFdeveloper to aid exploration.A Nucleus does not necessarily represent functionalityof parts of the WF directly (e.g. equalizer or demodulator).The functionality is built using these kernels. Since themembers of the Genre have the same computation andcommunication pattern, they can be implemented usingtheir Flavors. But, this might need some pre or post- pro-cessing in addition (Figure 3). Since Flavors are optimizedimplementations, they can introduce additional constraints,e.g. requiring a certain input data format like Q15. Partof the pre-processing in this case would be the adoption his work has been submitted to the IEEE milcom 2009 conference for possible publication. Copyright may betransferred without notice, after which this version may no longer be accessible.of the data format. Flavors need to be flexible enough toimplement the extra processing in an efficient way.
Figure 3. Nucleus Genre Relationship
One important aspect of the proposed approach is thatdifferent vendors can provide Flavors of some or all ofthe Nuclei in the form of a board-support-package (BSP).Flavors could be assembly codes for an ASIP or DSP and/orIP cores in HW or on a reconfigurable FPGA. Therefore,a Flavor in general can be seen as a bundle of the PE andlow-level software (if applicable). Due to this bundling itwill be possible to capture the Nucleus functionality bymeans of a HW independent high level Nucleus applicationprogramming interface (API). This enables to describe aWF independently of the targeted MPSoC platform. Still,the WF can be mapped efficiently to the platform due to thebundled Nuclei low-level implementation. Participation ofdifferent vendors is also possible due to the standardizationof the functionality and the interface of Nuclei. Vendorscan also provide simulation models of the Nuclei e.g. inMatlab/Simulink.The Nucleus concept enables WF developers to programthe HW platform on a very high level (Nucleus level) asthe Nuclei are visible via algorithm factors (Genre, Flavors).The developer will still be able to explore among the exist-ing Flavors for WF implementation. Since the programmingis done at the Nucleus level hiding the underlying HWplatform, it is efficient and simple for the developers.Even though new WF implementations go through manyrounds of development and adjustment, the core algorithmickernels often evolve at a relatively slow rate [14]. Sincethe proposed concept exploits such core common structuresthat exist in receiver algorithms [15], various WFs can bebuilt even after the availability of the HW platform. Dueto existence of such kernels in general purpose applicationsresearch in the same direction is also done by computerscience experts [16]. C. AN EXAMPLE
FFT is an example of a Nucleus. FFT has been usedfor several decades in diverse applications. But the corealgorithm itself has not evolved in the same pace as theimplementations [17]. The granularity is at an optimumlevel that enables reuse in various applications. We are usingthe existing work based on the FFT algorithm as an examplefor explaining the definitions in our concept. The referencesto the existing work are given as the explicit proof for ourarguments. Since the motive is not to explain the example but to show the relationship between the definitions onlybrief comments are given for each Genre member.
Figure 4. Nucleus Example
Figure 4 depicts the relation between the definitions thatwere introduced in the concept. As illustrated in the figure,for one Nucleus (e.g. FFT) there could be several membersbelonging to its Genre. The Genre member fast Mellintransform (FMT) can be realized using the FFT kernel[18]. But this requires pre and post-processing as shown inFigure 5. Pre-processing in this case is re-sampling the inputand post-processing is the amplitude calculation. Flavorsneed to implement this extra processing also efficiently.Fast Hankel transform (FHT) is the (one dimensional)Fourier transform of the Abel transform [19]. Here, thepre processing portion is the Abel transformation. Also,FHT using fast cosine transform and fast sine transformcan be found in [20]. FFT can be used as a basis for doingfast wavelet transforms [21]. Discrete cosine transform andWalsh transform can also be realized with pre and post-processing [22]. Efficient implementations using an FFTkernel as basis for realizing Walsh-Hadamard transform,discrete cosine transform (DCT) and discrete Hartley trans-form exist in [23]. In addition to that, the inverses of someof the above transforms belong to the same Nucleus, e.g.IFFT and IDCT.
Figure 5. Nucleus Genre Example
Flavors for FFT have been existing using different al-gorithms and radices. For example, an FFT Flavor mightuse either a Cooley-Tukey or Sandey-Tukey algorithm de-pending on the decomposition of FFT stages. Flavors canbe available by using a single radix like radix-2 or radix-4.If the number of FFT points is not a multiple of the basicradices, combination of different radices is present in oneFlavor (Figure 4). The efficient implementations from the his work has been submitted to the IEEE milcom 2009 conference for possible publication. Copyright may betransferred without notice, after which this version may no longer be accessible.BSP could be assembly codes for an application specificinstruction processor (ASIP) or digital signal processor(DSP) (e.g. optimized FFT implementations from TI library[24]) and/or IP cores in HW or on a reconfigurable fieldprogrammable gate array (FPGA) (e.g. FFT intellectualproperty (IP) cores from Xilinx [25] and Altera [26]). TheTI library [24] even provides support for IFFT. Simulationmodels for Flavors are also provided by vendors [24–26].One Flavor might be different to another in algorithm, flex-ibility and performance. For example, a Flavor with radix-2has more FFT stages compared to radix-4. Therefore, it ismore flexible to scale the outputs in the intermittent stagesthan radix-4. Flavors can offer a wide performance rangewith respect to latency and throughput, e.g. [25].From the above references, it can be inferred that themembers in the Genre can be realized using the same FFTkernel. As a special case, an FFT kernel can be used forboth PHY layer (e.g. OFDM) and application layer (e.g.video/audio compression) [22] signal processing.IV.
WAVEFORM DEVELOPMENTENVIRONMENT CONCEPT
In general, a WDL forms the basis of a WDE. WDEdenotes a system-level tool suite for automated WFdevelopment for SDRs. The tool-suite should cover theentire WF development process of requirements, design,implementation, integration and testing for SW and HW[27]. Figure 6 depicts these processes with respect to ourproposed concept. While the WF description captures therequirements and design of the WF under consideration,implementation is provided by the BSP. Integration andtesting processes are done in the mapping and evaluationstage (Figure 6). NI represents the Nucleus implementationof one Nucleus kernel. The first subscript of NI denotesthe Nucleus API (NA) and second subscript denotes thePE for which the implementation is available in the BSP.Therefore, NI denotes the NI of Nucleus 2 on PE 3. A. WAVEFORM DESCRIPTION
The WF developer uses WDL for describing the WFusing the API on the basis of the Nuclei library. The WFdescription will then consist of Nuclei kernels and non-nuclei (NN) kernels connected by communication links(Figure 2). The description also contains information aboutcritical paths, constraints and control flow of the WF. TheNN kernels reflect the other computation-light functionali-ties of the WF. B. WAVEFORM IMPLEMENTATION
The BSP plays an important role in the WF implemen-tation. It provides efficient implementations of some orall of the Nuclei kernels. This can enable tool based WF
Figure 6. Waveform Development Concept development where the Nuclei kernels are replaced by theBSP and the rest of the WF (like NN kernels) is builtusing a conventional approach (e.g. C/C++ code). If theimplementation for a kernel that is in the WF descriptionis not available in the BSP, it also has to be built using theconventional approach. This is indicated by the dotted linein Figure 6 for NA1. However, depending on performancerequirements, Nuclei kernels for which the BSP is missingmay have to be optimized for a given platform.Since the software code of the NIs is highly optimized itachieves high performance, but it is bound to that particularPE. As the input data structure of a Flavor will be knownfrom the BSP, WDE can generate additional logic requiredfor gluing Flavors. This results in (semi-) automatic gener-ation of WF implementation. Some of the features of WDEconcept using the Nucleus approach are • The Flavors in different BSPs can use different algo-rithms to implement the same behavior while offeringvarious tradeoffs. • There can be several and different Flavors for oneNucleus in one BSP. This provides the flexibilityto the WF designer to choose among the existingimplementations according to the need. C. MAPPING
The WF description and the NI from the BSP form thebasis of WF mapping onto the HW platform. Even thoughFlavors are efficient, the overall system performance is notguaranteed and it is heavily influenced by the spatial andtemporal mapping. Figure 6 sketches the scenario of spatialmapping for a given HW platform. The key difference tothe traditional WF spatial mapping is that the kernel fromthe WF description is mapped not to the HW PE, but tothe available NI from the BSP. This is possible due to thebundling of NI to the PE. As shown in Figure 7, there might his work has been submitted to the IEEE milcom 2009 conference for possible publication. Copyright may betransferred without notice, after which this version may no longer be accessible.be several choices for selection depending on the BSP. • For one Nucleus, there can be only one NI (Figure 7a). • For one Nucleus, there can be several NIs available forone PE (Figure 7b). • For one Nucleus, there can be several NIs available forseveral PEs (Figure 7c). • On one PE, there can be several NIs available fordifferent Nuclei (Figure 7d). • NIs can come from different vendors (Figure 7d).The presence of several mapping choices advocate theneed for tool assistance. The choice of the NI will be basednot only on the performance but also on the data structureof the neighboring NI interfaces. Since the NN kernels arecomputationally light, they might be mapped to the generalpurpose core (PE5) as shown in Figure 6.
Figure 7. Flavor Selection Scenario
One or more Nuclei (and/or non-nuclei) kernels can bemapped onto a single PE. This requires temporal map-ping/scheduling of kernels based on the data dependencies.Evaluation is needed to make sure that the constraints ofthe WF are met. D. EVALUATION
A detailed evaluation of the mapping decisions is neces-sary primarily to check if the WF constraints are met. It willalso aid in finding a mapping that maximizes total systemperformance. The WF constraints need to be verified interms of latency, throughput, bit error rate and critical loops.To maximize total system performance, metrics are neededwith which different mapping decisions can be evaluated.The following metrics can be used: • Increasing data localization • Minimizing communication • Minimizing synchronization • Maximizing PE utilization • Maximizing energy efficiencyThe mapping exploration should be done in an itera-tive manner and at different abstraction levels to trade-offbetween simulation speed and accuracy. The WDE willprovide the infrastructure necessary for doing the explo-ration and simulation for evaluating the mapping decisions.The mapping challenge is to identify the right choice of NIs that are not only compatible to each other and meetthe requirements of the WF but also maximize the overallsystem efficiency. Since the mapping and evaluation willbe an iterative process making it tool assisted can ease thewhole process. E. ADVANTAGES
The WDE methodology using the Nucleus concept de-lineates WF requirements in a manner that is neither appli-cation specific nor HW specific. This leads to the followingmain advantages in realizing SDRs. • Portability : Since the WF description is not HWspecific, the same description can be ported to multipleHW platforms. • Efficiency : HW specific Flavors of the WF aids inefficient implementation. • Reusability : Since the approach is not WF specific thesame NAs can be used for describing several WFs andthis will enable WDL based radio development. • Flexibility : Since the interface and functionality of theNuclei will be known through API, different vendorscan provide different Flavors. • Future Use : This approach paves way for capturingfuture WFs. V.
CHALLENGES
For realizing the Nucleus concept, it is necessary toexplore the Nucleus design space in the algorithmic, HWand tools domain in order to identify a basic set of Nucleiwhich will allow the realization of a wide range of WFs.Furthermore, it is important to investigate the flexibilityrequired for each NI to allow the usage for multiple WFs.All these aspects always need to consider energy efficiency.The challenges that exist to realize the Nucleus concept aredescribed in this section.
Nuclei Identification
One big challenge is the identifi-cation of Nuclei kernels that exist among WFs. The goal isto modularize or reformulate the algorithm in such a waythat efficient implementation and reusability across multipleWFs is enabled. The energy efficiency of the Nucleusinterconnect structure will have a significant influence onthe whole SDR system. The interconnection issues aretightly coupled with the definition of a proper API for aNucleus library and therefore it will provide good hints forWDL specification.
Mapping
Mapping a portable WF onto a HW platformspatially and temporally meeting the constraints is one ofthe key challenges. This requires exact knowledge of theHW interfaces of the NIs in order to deal with the requiredadditional glue logic to connect the different HW blocksand manage their execution.
Waveform Development Environment
Providing easy-to-use programmability for complex receiver systems is his work has been submitted to the IEEE milcom 2009 conference for possible publication. Copyright may betransferred without notice, after which this version may no longer be accessible.essential to exploit efficiently the system resources. A pro-gramming model that can bridge the gaps between WF, HWplatform and mapping is needed. A fast system simulationenvironment is key in order to validate mapping decisions.
Cross Layer Optimization
For an efficient radio designit is mandatory to look at the PHY-media access control(MAC) interactions and enable cross-layer optimization.The focus should be not only on the modularization andreuse of higher layer functionalities but also on the inter-faces between the layers.
SCA Compliance
Supporting software communicationsarchitecture (SCA) compliant WF development is keyfor implementing military WFs. The proposed concept isaligned with several aspects from the JTRS SCA com-munity. For instance, the information that is fed into themapping process of the WDE resembles the software as-sembly descriptor which describes the assembly of softwarecomponents and HW devices. Furthermore, additional logicneed to be generated to glue NAs to the SCA compliantAPIs. Though the propinquity of the Nucleus conceptand JTRS SCA is visible in many ways, complete SCAcompliancy must be guaranteed.VI.
CONCLUSIONS AND OUTLOOK
A novel concept for developing tool assisted, portableand efficient WFs for SDRs targeting a WDL has been pro-posed in this paper. By identifying the common, processingintensive, algorithmic kernels a Nuclei library is built. WF isdescribed in a WDL using the Nucleus library. The optimalgranularity of the kernels enable efficient implementationsand reuse. The standardization of the library will lead tothe availability of Flavors from vendors. This providesalgorithmic and implementation trade-offs even in a fixedHW platform. The implementation related properties ispropagated to the Nucleus-API. Since the API has informa-tion for ideal mapping, efficient and tool assisted mappingcan be provided by the WDE. Key challenges that exist inenvisioning the concept were also presented in this paper.Future work will address these challenges by workingclosely in algorithm, HW and tools domain. The selectedapplication scenario for approaching and validating theNucleus concept is an iterative and flexible MIMO-OFDMtransceiver focusing on PHY layer, MAC layer and systemcognition. A part of the transceiver will be implemented asa proof-of-concept. Investigations will also be done to findthe properties that are needed for enabling (semi) automatictool assisted WF development.
REFERENCES [1] E. M. Witte, T. Kempf, V. Ramakrishnan, G. Ascheid, M. Adratand M. Antweiler, “SDR Baseband Processing Portability: A CaseStudy,” in , Germany, 2008.[2] “JTRS,” May 2009. [Online]. Available: http://sca.jpeojtrs.mil/ [3] T. Kempf, E. M. Witte, V. Ramakrishnan, G. Ascheid, M. Adratand M. Antweiler, “A practical view on SDR baseband process-ing portability,” in , Washington D.C, USA, 2008.[4] T. Langguth and H. Schober, “SDR based Waveform Development,”in
IEEE Communications Magazine
Proc. Military CommunicationsConference (MILCOM 2001) , vol. 1, 2001, pp. 208–212.[11] M. S. Gudaitis and R. D. Hinman, “A waveform descriptionlanguage for software defined radio,” in , 2002.[12] J. Chapin, V. Lum and S. Muir, “Experiences implementing GSMin RDL (the Vanu Radio Description Language),” in
Proc. MilitaryCommunications Conference (MILCOM 2001) , vol. 1, 2001, pp.213–217.[13] C. Moy, J. Palicot, V. Rodriguez and D. Giri, “Optimal Determina-tion of Common Operators for Multi-Standard Software-DefinedRadio,” in , Germany, 2006.[14] K. Fan, M. Kudlury, G. Dasika, S. Mahlke, “Bridging the com-putation gap between programmable processors and hardwiredaccelerators,” in
Proc. IEEE 15th International Symposium on HighPerformance Computer Architecture , 2009, pp. 313–322.[15] H. Meyr, “Re-configurable ASIPs : Is there any need for thesearchitectures?” in
Proc. IEEE International Conference on Acoustics,Speech and Signal Processing , vol. 2, 1998, pp. 629–632.[19] E. W. Hansen, “Fast Hankel Transform Algorithm,” in
IEEETransactions on Acoustics, Speech and Signal Processing , vol. 33,1985, pp. 666–671.[20] L. Knockaert, “Fast Hankel Transform by Fast Sine and CosineTransforms: The Mellin Connection,” in
IEEE Transactions onSignal Processing , vol. 48, 2000, pp. 1695–1701.[21] H. Sava, M. Fleury, A.C. Downton and A.F.Clark, “Parallel pipelineimplementation of wavelet transforms,” in
Proc. IEEE Vision,Image and Signal Processing , vol. 144, 1997, pp. 355–360.[22] E. Tell, O. Seger and D. Liu, “A converged hardware solutionfor FFT, DCT and Walsh transform,” in
Seventh InternationalSymposium on Signal Processing and Its Applications , vol. 1, 2003,pp. 609–612.[23] K. Kloker and B. Undsley, “Efficient FFT Implementation OnAn Floating-Point Digital Signal Processor,” in
Proc. InternationalConference on Acoustics, Speech, and Signal Processing , vol. 2,2002, pp. 1302–1305.[24] Texas Instruments, “TMS320C64x DSP Library Programmers Ref-erence (Rev. B),” October 2003.[25] Xilinx, “IP Release Notes Guide (XTP025 (v1.4),” September 2008.[26] Altera, “FFT MegaCore Function MegaCore User Guide (Version:8.0),” May 2008.[27] M. S. Gudaitis and R. D. Hinman, “Practical considerations for awaveform development environment,” in
Proc. Military Communi-cations Conference (MILCOM 2001) , vol. 1, 2001, pp. 190–194., vol. 1, 2001, pp. 190–194.