- Open Access
A frame-based domain-specific language for rapid prototyping of FPGA-based software-defined radios
© Ouedraogo et al.; licensee Springer. 2014
- Received: 11 March 2014
- Accepted: 20 October 2014
- Published: 18 November 2014
The field-programmable gate array (FPGA) technology is expected to play a key role in the development of software-defined radio (SDR) platforms. As this technology evolves, low-level designing methods for prototyping FPGA-based applications did not change throughout the decades. In the outstanding context of SDR, it is important to rapidly implement new waveforms to fulfill such a stringent flexibility paradigm. At the current time, different proposals have defined, through software-based approaches, some efficient methods to prototype SDR waveforms in a processor-based running environment. This paper describes a novel design flow for FPGA-based SDR applications. This flow relies upon high-level synthesis (HLS) principles and leverages the nascent HLS tools. Its entry point is a domain-specific language (DSL) which handles the complexity of programming an FPGA and integrates some SDR features so as to enable automatic waveform control generation from a data frame model. Two waveforms (IEEE 802.15.4 and IEEE 802.11a) have been designed and explored via this new methodology, and the results are highlighted in this paper.
Software-defined radio (SDR) is a flexible signal processing architecture with very high reconfiguration capabilities to adapt itself to various air interfaces. It was first introduced by Joseph Mitola and turned out to be a sustainable underlying structure for cognitive radio (CR) . An important research and development work has been done to release SDR solutions, and a survey of SDR platforms is given in [2, 3].
The mainstream approach to specify an SDR application has consisted in implementing the signal processing blocks on digital signal processors (DSP) coupled with hardware accelerators such as field-programmable gate array (FPGA) or application-specific integrated circuit (ASIC) fabrics . As a matter of fact, the reason why such heterogeneous DSP-centric SDR platforms have been popularized is mainly due to the fact that current DSPs offer some important reconfiguration capabilities while being programmed with software design flows. However, DSPs suffer from high power consumption as compared to hardware fabrics. Thus, FPGA turned out to be an interesting alternative by trading-off between energy consumption and high computation performances. Dynamic reconfiguration capabilities are also available on recent FPGAs which offer some reconfiguration delays of up to a few microseconds. Furthermore, FPGA programming model enables to leverage an important dataflow parallelism through its native parallel computational model in contrast to the sequential nature of DSPs. Thus, FPGA-based SDR is a quite old paradigm [5, 6], and most of the prototypes rely on intellectual properties (IP) described at the register-transfer level (RTL), therefore getting the SDR concept far away from its initial idea that is to say a software-only platform. Indeed, one of the issues related to FPGA-based SDR is the design flow, essentially based on hardware description languages (HDLs), which are used to program the applications. These languages, namely Verilog or VHSIC hardware description language (VHDL), represent an important burden and limit dramatically the programmability of the SDR platforms. In order tackle this issue, abstraction has been raised through software languages which were proposed to target FPGAs.
High-level languages (HLLs) are software languages that generate hardware description (RTL) from abstracted software specifications  for FPGA or ASIC targets. They raise the level of abstraction and bridge the gap between high-level algorithm designers and low-level circuit architecture designers. Their associated compiling frameworks generate RTL descriptions that fit the best to the specified application. We experienced with some of those high-level synthesis (HLS) tools and the flow depicted in this paper is essentially based on them.
In this paper, we are addressing the FPGA-based SDR and propose a methodology for rapid prototyping of the SDR applications. The main idea is to provide the SDR community with a design flow for specifying and implementing SDR waveforms fully running on FPGA-based platforms.
The major contribution of this paper is a design methodology consisting in a domain-specific language (DSL), which combines data frame information with dataflow computational model to synthesize an FPGA-SDR waveform. The aim is to hide the complexity of specifying an SDR waveform while automating all the control requirements from a high level data frame description. Furthermore, the HLS tools are employed to generate efficient signal processing blocks, at the RTL-level, while the compiling framework consistently builds the datapath and associates the control logic.
The rest of the paper is organized as follows. A discussion on the related work is given in Section 2. Subsequently, Section 2.3 states the problems which have motivated for this work. Section 3 details the methodology by first introducing the proposed DSL then describing each step of the language. Section 4 discusses the associated compiling framework, and Section 5 outlines some results. These results have been obtained on a Nutaq Perseus 6010 development board (Nutaq, Quebec, Canada) by prototyping both the PHY IEEE 802.15.4 and the PHY IEEE 802.11a. Finally, conclusions are drawn in Section 6.
2 Related work
2.1 Software-defined radio languages and middlewares
The main requirements in the SDR domain are essentially the reconfigurability of the underlying platform, the programmability of the platform, and the portability of the application over different platforms . Therefore, several proposals attempted to meet those requirements by using software-based approaches [8–14]. Indeed, software gives an abstraction level that enables more control over the hardware design flow. To this end, two complementary approaches have been proposed, namely the SDR-specific languages to design the waveform and the SDR middleware to provide the building environment. They both take advantage of the abstraction level given by the software.
The first approach consists in defining specific languages, (i.e., DSLs), which purpose is to simplify the prototyping process of an SDR waveform, that is to say the physical layer (PHY). Most of these languages proposed in the literature essentially target DSP-centric architectures through specific design flows [8–10]. The waveform description language (WDL)  enables implementing the overall PHY from a hierarchical decomposition. It is mixing graphical and state machine concepts to provide the user with facilities to specify a complete SDR-PHY. Processing elements are blocks within which a state machine locally handles both scheduling, thanks to handshake protocols, as well as the communication with the other blocks. SPEX  is another language developed to specify SDR PHYs on single instruction multiple data (SIMD) processor using vector data type such as Matlab and also data type borrowed from SystemC. It is declined into three sub-languages, namely the Kernel SPEX defining the processing algorithm, the Stream SPEX handling the dataflow and modules interconnections, and finally the Synchronous SPEX for real-time constraints consideration. DiplodocusDF  is a modeling language that was proposed for implementing SDR PHYs on software-based platforms. It leverages a unified modeling language (UML)-like representation to model the SDR PHY and generates an executable to run on a software-based platform.
The second approach can be defined as a set of proposals for SDR standardization. They consist essentially in defining middlewares as the interfaces between the hardware and the application [11–14]. The core idea is to provide an environment, based on application programmable interfaces (APIs), to specify an SDR application while giving an emphasis to both the portability and the programmability of the application. The Software Communication Architecture (SCA) , initiated by the Joint Tactical Radio System (JTRS), is a major contribution in the software radio domain. It is defined as both a framework and a common standard for software radio specifications, and it is based on three major elements. The Core Framework handles via a hardware abstraction the installation, the configuration, the control, and the management of the waveforms. The ORB middleware serves to ensure the communication between the entities through client/server-like architecture. Both the Core Framework and the ORB leverage a real-time operating system to get access to the hardware resources. The Prismtech Spectra Core Framework (PrismTech Group Ltd., Stirlingshire, UK)  is a SCA-compliant framework that supports the deployment of waveform components on any mix of general purpose processor (GPP), DSP microprocessors, and FPGAs. FPGA functions are essentially programmed in VHDL-RTL. In the same way, the Platform and Hardware Abstraction Layer (P-HAL)  aims at designing specific radio applications independently of the hardware context. The underlying approach consists in abstracting the hardware platform by software functional units. Thus, it manages radio process real-time constraints, processing elements and communication issues, and enables the software functional units to be configured. The P-HAL defines four services, namely the BRIDGE that handles real-time constraints, the SYNC that synchronizes the concurrent processes, the KERNEL that schedules the software functional units, and the STATS that analyses the statistics of the functional units.
The GNU Radio  provides both the signal processing primitives and the environment to implement software radio applications running exclusively on a host PC. The interconnections within the waveform are written in Python, and the signal processing blocks together with some of the critical datapath are implemented in C++. It is usually combined with an external RF chip to generate radio waveforms or simply used for simulation purpose.
In summary, it is important to note that managing an SDR from a higher level of specification is a key element since it would provide a complete overview over the application at the early stages of the design process. Most of the proposals that we have discussed in this section target either software-based platforms or heterogeneous platforms composed of mix of GPPs, DSPs, and FPGAs. FPGA uniprocessor platforms are a promising alternative for SDR. Indeed, some research work  have already addressed this issue by developing FPGA-based uniprocessor SDR platform where the signal processing is entirely done on an FPGA. However, such platforms lack of programmability since FPGAs are programmed with low-level languages. In this context, HLS turns out to be a good candidate to achieve such a high level of abstraction when FPGA-based SDR is addressed.
2.2 High-level synthesis tools and flow
A traditional implementation of a waveform intended to run on hardware processors such as FPGA or ASIC fabrics often requires a manual HDL description. Those HDLs appeared to be relatively fastidious, error prone, and hard to maintain when it comes to specify huge and complex applications. In the early 1980s, some new approaches/languages, most of them inspired from the C language, suggested a more abstracted way to specify and implement the hardware circuit architecture. Known as HLL, this trend is still on the mainstream, and an interesting survey was proposed in . One could make an analogy with software programming flows which employ the C language as entry point instead of pure assembly code. However, employing such high-level design flow still requires a good knowledge in hardware circuit architecture so as to achieve good design performance.
These high-level languages and their compilers give an emphasis to the timing, area, or throughput constraints while making it easier to explore a set of solutions throughout design space exploration (DSE). Thus, HLS enables skipping several manual steps and gives an error-free path from abstract specification down to RTL description. In effect, by bypassing those steps, an important workload is being transferred to writing good specifications. A set of design optimization techniques such as loop pipelining or loop unrolling, which can be triggered from the specification, is also proposed by the HLS tools to achieve better design performance.
2.3 Problem statement and motivations
Summary of state-of-the-art SDR languages
Subset of the C++
DSP (VLIW and SIMD)
GPP and DSP
GPP and DSP and FPGA
GNU Radio 
C++ and Python
Prismtech Spectra Core 
Model-based design and RTL IP cores
GPP and DSP and FPGA
As mentioned previously, HLS is a powerful means to prototype and synthesize waveform specifications down to circuit architecture. However, HLS has been thus far specialized in datapath designing rather than control. Indeed, complex control structures might require to be written entirely in HDL. Actually, HLS has been employed as a processor generator intended to be used as hardware accelerators. For instance, it does not properly address the specification and the implementation of state machines that are the mainstream approach for specifying complex control system. Thus, in the context of full FPGA-based SDR, HLS can be leveraged to increase the programmability of each signal processing block composing the SDR PHY dataflow graph whereas control requirements could be handled separately. In addition to this, employing different HLS tools so as to achieve various performance in a target design is a situation in which the control structure could be handled separately, as well. In the following sections, the authors propose an SDR PHY design methodology combining the model-driven engineering (MDE) for high-level description and the HLS for datapath designing.
3 DSL-based SDR waveform specification
3.1 Model-driven engineering for FPGA-SDR
The growth of the platform complexity exhibits the limitations of current programming languages. Furthermore, these platforms evolve rapidly while the application codes are still written and maintained manually. A mainstream approach to handle such platform evolution is the MDE . It comprises both a DSL, which formalizes the application structure, behavior, and requirements in a declarative way, and a set of transformation engines and generators to generate multiple artifacts such as source code. The MDE approach ensures a 'correct-by-construction’ development of an application.
The spearhead of the proposed methodology is the definition of a DSL to implement SDR waveforms running on FPGA uniprocessor platforms. A DSL, as opposed to the general-purpose languages (GPLs), is a computer programming language of limited expressiveness focused on a particular domain [21, 22]. In , they are declined into two variants, namely the internal DSL and the external DSL. Internal DSLs are languages that depend on a host language (generally a GPL). Their syntax is derived from the host language syntax and they benefit from the existing GPL compiling frameworks. An external DSL denotes a language with a custom syntax not depending on any GPLs. They are generally developed from scratch and require defining a specific compiling framework. Finally, the advantages of implementing a DSL are the improvement of the development productivity, the fact of facilitating the communication between domain expert through an explicit syntax, and above all, the usage of an alternative computational model.
3.2 DSL-based frame specification
3.2.1 Field specification
In the DSL, the declarations of constant and variable fields are done with the key words #fieldC and #fieldV, respectively. They are followed by an arbitrary identifier that represents the field in the rest of the DSL source code. Following that, field-specific information such as data redundancy, size, and duration are defined within curly braces. These definitions enable to adapt the control when each field is transmitted or received.
3.2.2 Data frame specification
A data frame is specified out of the instantiated fields with the key word frame followed by a frame identifier. Within curly braces, the set of fields composing the frame are listed. A frame can be either complex or real. Complex frames imply both an in-phase and a quadrature phase projection of the signal. Once a frame is specified, a Start-Of-Frame (sof) is designated among the constitutive fields. It denotes essentially a synchronization moment at the receiver. Thus, it enables to sketch the control of the waveform at the receiver.
The purpose of a frame declaration is twofold. On one hand, computation resources are optimized away in regard with the nature of the field. For instance, constant fields are one time computed and mapped to memory. The actual frame is built by consistently multiplexing those fields to the rest of the frame during transmission. On the other hand, the attributes of each field enable to dimension the appropriate control logic required in the waveform. This logic aims at sketching the datapath with energy efficiency considerations.
3.3 DSL-based dataflow
3.3.1 The underlying model of computation
3.3.2 DSL-based dataflow description
The proposed design flow is here to synthesize SDR waveforms. To this end, aiming at anticipating on the flexibility requirements, when adaptive coding modulation is implemented for instance, a flexible FB is declared adaptive within the DSL source code. In Figure 7, both the fast Fourier transform (FFT) and the Demapper blocks are declared adaptive. Indeed, these two blocks work in multi-mode, and it is often required to reconfigure them on the fly in order to work in a given mode. Thus, block-level reconfiguration is addressed early in the design process. For a complete waveform to be synthesized, both the transmitter (TX) and the receiver (RX) have to be described.
A DSL compiler has been implemented to parse the entire waveform description and synthesize all the artifacts required to implement the waveform. This compiler is introduced and detailed in the next section.
4 DSL compiler
4.1 Compiling framework
4.2 Verification and validation framework
Verification and validation (V&V) processes are very important in a design flow because they ensure that the final design meets with the requirements. They can be time consuming to be performed, but they enable to prove correctness and reliability in the various steps of design and implementation. In the proposed design as illustrated in Figure 8, the V&V is declined into three steps, namely the Model-Based Verification, the Functional Verification, and the Waveform Validation. The Model-Based Verification relies on the MDE concept and includes formal verification, dataflow analysis, and model checking. The Functional Verification relies first on the verification provided by the HLS tools which enables to verify each generated FB from a C/C++ test bench. The data frame specification is used to generate the stimuli for the test bench. The final waveform is verified from a generated VHDL test bench whose outputs are compared with predetermined golden outputs. Finally, the Waveform Validation takes place after bitstream synthesis. It consists essentially in testing the waveform on the platform so as to analyze its performance. Contrary to the first two steps that are performed automatically, this step is by now performed manually, and the authors are investigating on how to automate such validation process from the high-level specifications.
4.3 Frame-based SDR waveform controller
A frame is generally considered at distinct levels, namely the bit level, the symbol level, and optionally at the sample level. It is mainly characterized by its duration, its source (e.g., a FB), and its composition (a set of fields). This structure gathers exploitable information that are leveraged to achieve better waveform control performance. The duration of each field for instance can help generate the read and write clock signals during the appropriate slot of time. In addition, each block within the flow graph is meant to perform a given action on a specific set of fields. Once this action terminates, the block may no longer be required, then disabled. For instance, some FBs may address only synchronization and some others address only data decoding. It is then convenient to control the activation and deactivation of each FB.
In the RX mode, the FSM is composed out of the three super-states. An IDLE state, as in TX mode, denotes the inactive state of the receiver. In this state, the receiver monitors the environment seeking for an incoming signal. Once a signal is detected, through an received signal strength indicator (RSSI) for instance, the receiver switches from the IDLE state to the PRE-SOF state. The PRE-SOF state consists essentially of synchronization tasks as imposed by most of the standards. Once the system enters the PRE-SOF state, a set of synchronization elements has to be detected and computed within a certain delay. If not, the system returns in the IDLE state. These synchronization element detection and computation are associated to the sof event which is defined in the DSL-based frame specification that was lately introduced. An sof detection makes the system switch from PRE-SOF to POST-SOF where a coherent data decoding is sketched. The POST-SOF state is declined into three parallel sub-states, namely the DECODING state where most of the signal processing is required, the SYNC-TRACK state in which the system keeps on tracking synchronization elements, and finally the BL-RECONF state to handle the run-time block-level reconfiguration like in TX mode.
Thus, each block is affected a time slot to process a field when this field is traversing the graph. They are then activated depending on the ongoing field. To achieve this, the controller decides a starting moment for each block in the graph. This starting time is computed by considering both the graph structure and the properties (latency and throughput) of each block composing it. Indeed, each state is associated to a datapath, and once the system enters a state, the processing starts with a specific block that is tagged as a reference block. The activation moment of the remaining blocks in the datapath is then estimated by computing their distance to the reference block based on the latency and the throughput of the blocks preceding them. This algorithm has been integrated into the presented SDR PHYs design flow.
5 Experimentation and validation
5.1 Testbed description and waveform implementation results
The experimentation of the proposed DSL-based design methodology was carried out on an FPGA-based platform. It consisted in describing and automatically implementing both IEEE 802.15.4 and IEEE 802.11a transceivers.
The testbed is composed of a Nutaq (ex-Lyrtech) Perseus 6010 development board. Perseus 6010 is an advanced mezzanine card designed around a Virtex-6 FPGA with fabrics flexibility and an external memory. It also benefits from multiple high-pin-count add-on FPGA mezzanine card (FMC)-based cards. An FMC-based Radio 420x daughter board is used as full duplex SDR agile RF front-end with 12 bits ADC and DAC at up to 40 mega-samples per second.
5.2 DSL complexity
A waveform specification with the proposed DSL is done with a few hundreds of lines of source code. In the examples depicted in this paper, less than 150 of lines of source code was used to model the PHY IEEE 802.11a and less than a hundred for the PHY IEEE 802.15.4. The flow also relies on a set of constantly evolving FB libraries, hence reducing considerably the development time. As previously explained, most of the steps in this flow are made automatic through the .tcl scripting language. The DSL compiler handles the implementation of the waveform by connecting the FBs and generating the waveform controller introduced previously in this paper. The resulting RTL source code for a given waveform consists of a few thousand of lines of source code entirely generated by both the DSL compiler and the HLS tools.
5.3 Synthesis results and design space exploration
Resource estimation for the IEEE 802.15.4 and IEEE 802.11a receivers
To conclude, the current version of the flow handles block-level configuration; it enables to select the architecture of a adaptive block depending on the constraints. This compile-time reconfiguration takes advantage of the HLS capabilities. An extension would be to make the generated controller able to manage at run-time the handover between two configurations of an adaptive block. In practice, it could leverage the dynamic and partial reconfiguration features available on recent FPGA devices. To this end, each adaptive block could be interfaced with large memory resources to store the streaming data when a reconfiguration is required.
In this paper, we have discussed a design flow which purpose is to enable rapid implementation of SDR applications on FPGA-based platforms. The proposed flow relies upon a DSL which provides a software abstraction to model the waveform. The specified waveform generation results from the analysis of their associated data frame and dataflow structure. Moreover, HLS capabilities are also featured with this flow, aiming at shortening design implementation time.
A case study has been performed through two examples, namely a PHY IEEE 802.11a transceiver and a PHY IEEE 802.15.4 transceiver. It results in a fast method for prototyping SDRs on FPGA devices with considerable flexibility to achieve different design goals. The current perspectives aim at enriching the processing block libraries and integrate different HLS tools within the flow. Another aspect that we will investigate is the use of dynamic and partial reconfiguration features on FPGA which are now missing in the depicted flow.
The authors would like to thank the anonymous reviewers for their comments and suggestions which helped improve this paper.
- Mitola J: Software radios: survey, critical evaluation and future directions. IEEE Aerospace Electron. Syst. Mag 1993, 8(4):25-36.View ArticleGoogle Scholar
- Dardaillon M, Marquet K, Risset T, Scherrer A: Software defined radio architecture survey for cognitive testbeds. In IEEE International Wireless Communications and Mobile Computing Conference (IWCMC). Limassol, Cyprus; 2012:189-194.Google Scholar
- Anjum O, Ahonen T, Garzia F, Nurmi J, Brunelli C, Berg H: State of the art baseband DSP platforms for software defined radio: a survey. EURASIP J. Wireless Commun. Netw 2011, 2011: 5. 10.1186/1687-1499-2011-5View ArticleGoogle Scholar
- Jondral JF: Software-defined radio: basics and evolution to cognitive radio. EURASIP J. Wireless Commun. Netw 2005, 2005: 275-283.View ArticleMATHGoogle Scholar
- Cummings M, Haruyama S: FPGA in the software radio. IEEE Commun. Mag 2010, 37(2):108-112.View ArticleGoogle Scholar
- Stefano AD, Fiscelli G, Giaconia CG: An FPGA-based software defined radio platform for the 2.4 GHz ISM band. Res. Microelectronics Electron. 2006, 73-76. doi:10.1109/RME.2006.1689899Google Scholar
- Edwards SA: The challenges of synthesizing hardware from C-like languages. IEEE Des. Test Comput 2006, 23(5):375-386.View ArticleGoogle Scholar
- Willink ED: The waveform description language: moving from implementation to specification. IEEE Mil. Commun. Conf. (MILCOM 2001) 2004, 1: 208-212.Google Scholar
- Lin Y, Mullenix R, Woh M, Mahlke S, Mudge T, Reid A, Flautner K: SPEX: a programming language for software defined radio. In Software Defined Radio Technical Conference and Product Exposition (SDR-Forum 06). Orlando, FL, USA; 2006.Google Scholar
- Gonzales-Pina J, Ameur-Boulifa R, Pacalet R: DiplodocusDF, a domain-specific modeling language for software defined radio applications. In 38th EUROMICRO Conference on Software Engineering and Advanced Applications (SEAA). Cesme, Izmir, Turkey; 2012:1-8.Google Scholar
- Jianxin G, Xiaohui Y, Jun G, Quan L: The software communication architecture specification: evolution and trends. In IEEE Conference on Computational Intelligence and Industrial Applications (PACIIA). Wuhan, China; 2009.Google Scholar
- Gelonch A, Revès X, Marojevik V, Ferrús R: P-HAL: a middleware for SDR applications. In SDR Forum Technical Conference. Orange Country, CA, USA; 2005.Google Scholar
- GNU Radio: The free and open software radio ecosystem. http://www.gnuradio.org
- PrismTech Corporation: Prismtech spectra SDR: spectra CF high performance low footprint SCA core framework. PrismTech Corp., France; 2014.Google Scholar
- The WARP Project http://warp.rice.edu
- McCloud S: Catapult-C, synthesis-based design flow: speeding implementation and increasing flexibility. White Paper, Mentor Graphics; 2004.Google Scholar
- Altera: Implementing FPGA design with the OpenCL Standard. White Paper, Altera Corporation; 2013.Google Scholar
- Shagrithaya K, Kepa K, Athanas P: Enabling development of OpenCL applications on FPGA platforms. In IEEE 24th International Conference on Application-Specific Systems, Architectures and Processors (ASAP). Washington, D.C., USA; 2013:26-30.Google Scholar
- Economakos G: ESL as a gateway from OpenCL to FPGAs: basic ideas and methodology evaluation. In 16th Panhellenic Conference on Informatics. Piraeus, Attica, Greece; 2012:80-85.Google Scholar
- Schmidt DC: Model-driven engineering. IEEE Comput 2006, 39(2):25-31. 10.1109/MC.2006.58View ArticleGoogle Scholar
- Fowler M, Parsons R: The Addison-Wesley Signature Series: Domain-Specific Languages. Pearson, Indianapolis; 2011.Google Scholar
- Pasha A, Derrien S, Sentieys O: System level synthesis for wireless sensor node controllers: a complete design flow. ACM Trans. Des. Automation Electron. Syst. (TODAES) 2011, 17(1):2-1224.Google Scholar
- IEEE: IEEE Std 802.15.4: IEEE Standard for Information Technology: Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for Low-Rate Wireless Personal Area Networks (WPANS). IEEE, Piscataway; 2006.Google Scholar
- IEEE: IEEE Standard for Local and Metropolitan Area Networks: Part 16: Air Interface for Fixed Broadband Wireless Access Systems. IEEE, Piscataway; 1999.Google Scholar
- IEEE: Supplement to IEEE Standard for Information Technology: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications. IEEE, Piscataway; 2001.Google Scholar
- Lee EA, Messerschmitt DG: Synchronous data flow. Proc. IEEE 1987, 31(1):24-35.Google Scholar
- Eker J, Janneck J, Lee EA, Liu J, Liu X, Ludvig J, Sachs S, Xiong Y: Taming heterogeneity - the Ptolemy approach. Proc. IEEE 2003, 91(1):127-144. 10.1109/JPROC.2002.805829View ArticleGoogle Scholar
- Bahtnagar V, Ouedraogo GS, Gautier M, Carer A, Sentieys O: An FPGA software defined radio with a high-level synthesis flow. In IEEE Vehicular Technology Conference (VTC-Spring13). Dresden, Germany; 2013:1-5.Google Scholar
This article is published under license to BioMed Central Ltd. This is an Open Access article distributed under the terms of the Creative Commons Attribution License (http://creativecommons.org/licenses/by/4.0), which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly credited.