1 / 26

Virtual Machine for Software Defined Radio: Evaluating the Software VM Approach

2012.08.27. Virtual Machine for Software Defined Radio: Evaluating the Software VM Approach. 黃喬楷 Dept. of Electrical Engineering National Cheng Kung University Tainan, Taiwan, R.O.C. Outline. Abstract Introduction Existing SDR Platforms Radio Virtual Machine Proposal

coby
Télécharger la présentation

Virtual Machine for Software Defined Radio: Evaluating the Software VM Approach

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 2012.08.27 Virtual Machine for Software Defined Radio:Evaluating the Software VM Approach 黃喬楷 Dept. of Electrical Engineering National Cheng Kung University Tainan, Taiwan, R.O.C

  2. Outline • Abstract • Introduction • Existing SDR Platforms • Radio Virtual Machine Proposal • Implementation Choices • Experiments & Results • Conclusion

  3. Abstract • We study the impact of using a virtual machine for the configuration of radio physical layer protocols on a real hardware platform: the Magali chip. • We evaluate the additional cost of the virtual machine layer on the effective implementation of telecommunication physical layer protocols. • The results, using the mixed System C/VHDL cycle accurate simulator of the Magali platform, show that, although the proof of concept is valid and functional, extra optimizations, such as additional hardware mechanisms, will be necessary to obtain real-time performance.

  4. Introduction(1/4) • Software defined radio (SDR) has been “de facto” defined as the ability to program the physical layer of the radio protocol used for wireless communication.This does not mean, of course, that the protocol is fully realized in software. • High bandwidth telecommunication protocols require hardware components for a real-time implementation. However, the same hardware components (e.g., a FFT component) are used in several different protocols with different parameters.What must be done in software is the configurationand control of these hardware components.

  5. Introduction(2/4) • As soon as a SDR platform is programmable, its programs (sometimes called waveform programs) should be easy to develop, parameterisableand reusable.The reasons for that are : • Programmability very quickly leads to intractable complexity and time-consuming debugging process. • The vast quantity of hardware platforms makes it impossible to develop one waveform program per hardware platform. • This is the basic motivation for the use of a virtual machine for SDR: a dedicated virtual machine available on each hardware platform would be a solution to the “program once run everywhere” ideal scheme for waveform programs.

  6. Introduction(3/4) • A typical usage of a virtual machine in SDR would be as shown in figure1:telecom operators provide to their customers an unified platform-independent bytecode to reconfigure their mobile device. Fig. 1. RVM use case

  7. Introduction(4/4) • In this work, we investigate a proof of concept to implement a software RVM: we reuse an existing SDR platform without any additional dedicated hardware for the virtual machine by itself. • Our experiments have been done with a port of the Lua virtual machine on the ARM processor present on Magali. • These experiments show that our software RVM implementation is approximately 2 to 6 times slower than native implementation which tends to prove that the overhead introduced can be managed and that more optimized VM should be used and investigated.

  8. Existing SDR Platforms • SDR offers faster time to market and shortens development cycle of new products.In the following, we briefly present a representative sampling of SDR platforms. • DSP-centric platforms : SDR platforms allowing to implement full-software signal processing modules are highly flexible. • Heterogeneous platforms : These platforms are mainly composed of dedicated hardware processing units. At least one CPU is usually required for the platform to control hardware operators. • DSP-centric platforms offer high flexibility but are limited in terms of performance (computation speed and energy consumption) compared to platforms with dedicated hardware accelerators. We also notice that a centralized CPU is always present for platform control.

  9. Radio Virtual Machine Proposal(1/3) • In our case, the execution model is a set of IPs interconnected by an efficient communication mechanism. These IPs can be software or hardware blocks, they are reconfigurable and can accept runtime parameters. • The platform reconfiguration management using a virtual machine can preserve genericity of implantation until the last moment: downloading the bytecode program on the device. (?)Once the bytecode is downloaded to the target RVM several runtime steps still need to be done. • Allocation and resource sharing can and should be associated with the virtual machine to increase the portability of the code and go through the mechanism of operators virtualization. • Just in time compilation techniques can be used on the configuration bytecode to increase the virtual machine efficiency and make use of the the platform specific optimization opportunities. These steps are not discussed here.

  10. Radio Virtual Machine Proposal(2/3) • In this paper, we place ourselves in the case where the allocation of resources maybe made by simple association between the blocks available on the system composed of the hardware IP and the virtual machine process. • Calculations used in the computation stream can be instantiated by hardware or software. • The hardware blocks are seen as hardware accelerators for the computations. • The software blocks can be instantiated on general purpose processors, DSP or in our case within the virtual machine itself.

  11. Radio Virtual Machine Proposal(3/3) • Our RVM does not make any strong assumptions about how the platform should implement the communications.However , data integrity during transfers between blocks must be guaranteed by the platform.The absence of communication deadlocks among blocks must be ensured at compile time or during bytecode validation into the VM. • Once configured the IPs should be able to receive their data without intervention of the virtual machine.

  12. Implementation Choices(1/3) • In order to have rapidly a RVM prototype we chose to not start from scratch.Then we selected one suitable VM and extended it with a RVM API implementation on the Magali chip. • We consider that a relevant candidate virtual machine for our experiment should meet a set of criteria: • Small memory footprint and high performance (“lightweight”). • Well documented, and possibly with an active development community, in case of needs for important modifications of the VM core. • Easily extensible, at least through interfacing with libraries developed in native CPU bytecode.

  13. Implementation Choices(2/3) • We have selected the Lua VM mainly because of its design principles: it is built to be fast, lightweight and easilyextensible. Table 1. RVM Candidates

  14. Implementation Choices(3/3) • On each platform, the RVM also requires a platform specific software layer to access the hardware. • In this section, we show how telecom components are controlled by the VM. This control is done with four basic RVM primitives explained hereafter: • RVM_ALLOCATE primitive : Instantiates a telecom component and returns a HANDLE required for the management of the component. After that, the RVM is able to configure the component in order to make it ready for processing (e.g., loading software code into DSP memory, IP registers setting,...). • RVM_CONFIGURE primitive : It is applied on a component HANDLE. It sends a configuration to dedicated memory slots available on the Magali components. In the case of a software component, we implemented this primitive by loading the module bytecode into the VM memory. • RVM_CONNECT primitive : It using communication configuration driver functionalities. In the case of H/W blocks, it consists in configuring both source and destination components CCC controllers. • RVM_WAIT primitive : RVM executes a RVM_WAIT primitive and waits until it receives a notification from the configured unit.

  15. Experiments & Results(1/11) • In this section we present the experiments we have realized in order i ) to functionally validate the RVM concept and ii ) to study the real time behaviour of our specific implementation on the Magali chip. • We deduce from experimental results which part of a RVM implementation are the most limiting in terms of flexibility and computation efficiency. • Finally, we discuss different possibilities to cope with these hard points and propose further improvements to our RVM.

  16. Experiments & Results(2/11) A. Experimental Setup • We used two different test benches for our experiments. • The first test bench, presented in section A_1, highlights the cost of component reconfiguration with and without RVM. • The second test bench (section A_2) shows the performances of the system when the RVM is used to access and do computations on the stream of data.

  17. Experiments & Results(3/11) A_1 . First test bench: single operator application • The first test bench (figure 2) performs FFT operations on a variable number of data with three different configurations of our SDR platform: • in a native mode (fully optimized using Magali specific mechanisms), • using the previously described RVM programming model without the VM interpretation layer (i.e. simply using RVM primitives), and • using the full RVM concept (VM and programming model). Fig. 2. Applying FFT on a variable number of data: the three configurations of test bench 1

  18. Experiments & Results(4/11) A_2 . Second test bench: IEEE802.11a CFO estimation and correction • In telecommunication systems, Carrier Frequency Offset (CFO) refers to the carrier frequency mismatch between a transmitter and a receiver, due to hardware imperfections. • Our second test bench implements CFO estimation and correction for the IEEE802.11a protocol in pure software. Fig. 3. CFO estimation implementation: native implementation (config. 1)

  19. Experiments & Results(5/11) B. Results(1/4) • The experiments described in the following paragraphs have been realized on the Magali chip simulation platform with a cycle-accurate ARM1176JZFS core VHDL model. • Results of test bench 1:Figure 4 shows that the total execution time linearly depends on the number of processed data.Using linear regression algorithm we can model the three curves by the linear function y= ax+b where x is the number of data flit to be processed and y is the simulated execution time. Couples of parameters (a,b) are listed in the following table: Table 2. Overhead Regression Parameters

  20. Experiments & Results(6/11) Fig. 4. Simulated total execution time

  21. Experiments & Results(7/11) Fig. 5. Chronograms for the CPU and the FFT IP for the three configurations: (a)native ,(b) RVMAPI ,(c) full RVM.

  22. Experiments & Results(8/11) B. Results(2/4) • For configuration 1 permits to have a single IT signal, no matter how many data are processed. This also permit to overlap communication and computation in the FFT IP. Once, initialization of the CPU is done, the time is spent in the FFT computation, hence we have: anative ≈ aFFT where aFFT is the time to process one data flit. • For configuration 2, the IT has to be sent at the end of each FFT computation, hence computation and communication cannot be overlapped which lead to a total computation time of Trvm_model = N *(tload +tFFT +tsend +trestart) for N FFT. arvm_api ≈ (tload +tsend+trestart)/sizeFFT + aFFT

  23. Experiments & Results(9/11) B. Results(3/4) • For configuration 3,the time spent in RVM primitive is more important than the time spent for executing the FFT on the IP. Hence the slope afull_rvm of the line on figure 4 is only dependent of the time spent in the VM. afull_rvm ≈ ( twait_IT +trestart)/ sizeFFT Fig. 6. Decomposition of the time spent in test bench 1 for the three configurations.

  24. Experiments & Results(10/11) B. Results(4/4) • IEEE802.11a CFO estimation: We notice an increasing overhead in processing time with each added layer. If we do not take into account the time spent in the CPU initializations (program load, boot, OS initialization, etc.). We find that RVM programming modelimplementation has approximately 25% overhead compared to the native implementation, whereas full RVM implementation is approximately 6.5 times slower than RVM programming model version. Table 3. Programs sizes

  25. Experiments & Results(11/11) Fig. 8. CFO application execution phases

  26. Conclusion • The different experiments introduced in this paper allows to evaluate the overheads due to the RVM concept.As a conclusion, even if our implemented software RVM does not meet the hard real time constraints of 3/4G (?) , its adequacy to describe advanced telecommunication standards is proven and several optimizations, starting with JIT, are still to be developed to check whether sufficient performances can be achieved.

More Related