SOFTWARE DEFINED RADIO IMPLEMENTATION CONSIDERATIONS AND PRINCIPLES USING THE SANDBLASTER™ SDR BASEBAND PROCESSOR Babak D. Beheshti, (B.Beheshti@ieee) , Tanuj Raja (Tanuj.), Sandbridge Technologies Inc.
ABSTRACT The design flow and methodology for hardware centric radio baband processors is well established and understood. However, migration to a software centric baband processor approach is still new to many designers. The paradigm shift of viewing real time events from the point of view of gates and registers to pointers and memory offts is not often easily grasped. This paper covers a new design flow appropriate for a complete software driven baband processor using the Sandblaster™ SDR baband processor. Topics covered in this paper include programming for the RF-Baband Interface, Programming the entire physical layer processing in C, handling TDMA/CDMA time-critical events, Code/Data memory considerations and layout, Multi-program support for multimode radios, System Software Pudo-code, Terminal Reconfiguration Management, and Taking advantage of Low Power Architectural features. 1. INTRODUCTION Software Defined Radios (SDRs) offer a dynamically reprogrammable method of reusing hardware to implement the physical layer processing of multiple communications systems and applications. SDRs can dynamically change protocols and accept communications systems and applications updates over the air as quickly as a 英语四级培训
rvice provider requires this update. Rapid implementation of numerous multimedia applications and multiple wireless communication protocols is easily accomplished on a single programmable platform utilizing an SDR baband processor. Furthermore, enhancing the terminal capabilities with new protocols, applications, and functions is achieved through over-the-air dynamic software downloads. This capability reduces product feature support cost, time-tomarket, and risk while increasing handt OEMs and ODMs R&D and manufacturing productivity. The basic terminal model assumed in this paper is one with a block diagram shown in Error! Reference source not found.. The interface between the RF front end and the baband processing is a parallel n-bit or a rial digital interface. The sample word size, in bits, is determined bad on BER and channel requirements. Extra bits increa the overall dynamic range of the sampled data. It is assumed that the RF front end block includes the down conversion and the A/D and D/A circuitry to provide a purely digital interface to the baband processor. It is furthermore open to implementation whether this digital interface is DMA driven or directly controlled by the processor. In this discussion, a DMA driven interface is assumed. The Sandbridge baband processor, SB3010 provides a 16-bit parallel, DMA bad I/Q interface for transfer of digital Baband data to/from the RF front end. 2. DESIGN FLOW The design flow for a SDR bas baband processor is somewhat different from the traditional hardware bad designs. This design flow relies heavily on host bad development throughout the
development cycle removing the quential nature of dependency on the hardware platform availability to make fine-tuning of system performance. The general steps in the development of any air interface waveform using this methodology are listed below: 1. Physical Layer Algorithm Development (floating point) using MatLab, … 2. Translation to fixed point ANSI C 3. Simulate for algorithm accuracy in fixed point/ u debugger to debug code 4. Modify code as necessary 5. Profile code for MIPS/MHz requirements 6. Optimize specific functions as necessary (only in C) 7. High level partition the code into software threads (tasks) using the API provided by the operating system ud. 8. Using the simulator supplied with the tool chain, and possibly an event viewer examine latency requirements 9. Repartition threads as necessary - balance system load 10. Final system integration and hardware testing
interest是什么意思Proceeding of the SDR 05 Technical Conference and Product Exposition. Copyright © 2005 SDR Forum. All Rights Rerved
As召回是什么意思
can
be
en
繁体字在线翻译
in
Figure 1 below the development effort is front loaded, where the cost and risk to system changes are significantly lower than the back end. This significantly reduces risk and development time as well as allowing for tremendous visibility into the implementation becau of the host ba development environment.
disappointed翻译multiple possible implementations specified in SaDL and produce an object file for each implementation. The platform also supports many standard libraries (e.g. libc, math, etc.). The tools are then capable of producing dynamic and static simulators. A binary translator/compiler is invoked on the host simulation platform. From the inputs, it is possible to produce a statically compiled simulation file. If the host computer is an x86 platform, the translator may directly produce x86 optimized code. If the host computer is a non-x86 platform, the binary translator produces a C file that may subquently be procesd using a native compiler (e.g. gcc).
Figure 1 – SDR Bad terminal Design Flow 3. PROGRAMMING THE ENTIRE SYSTEM IN C
大学英语四级全部词汇
Figure 2 - Sandbridge Software Development Tool Chain For the dynamically compiled simulator, the object file is translated into x86 asmbly code during the start of the simulation. In single-threaded execution, the entire program
Dynamically compiled single threaded simulation translation is done at the beginning of the execution pha. Regions of target executable code are created. For each compound instruction in the region, equivalent host executable code is generated. Within each instruction, sophisticated analysis and optimizations are performed to reorder the host instructions to satisfy constraints. When changes of control are prent, the code is modified to the proper address. The resulting translated code is then executed.
Figure 2 shows the Sandblaster® tool chain. The platform is programmed in a high-level language such as C, C++, or Java. The program is then translated using an internally developed supercomputer class vectorizing, parallelizing compiler. The tools are driven by a parameterized resource model of the architecture that may be programmatically generated for a variety of implementations and organizations. The source input to the tools, called. the Sandbridge architecture Description Language (SaDL), IS a collection of python source files that guide the generation and optimization of the input program and simulator. The compiler is retargetable in the s
en that it is able to handle
noctua4. CODE/DATA MEMORY LAYOUT With the non-volatile memory size of most 2.5G mobile phones in the veral megabyte range, the code size for any of the individual waveform physical layers, the constraint is not the code size itlf rather the cache hit rate. The cache hit rate indicates how often the code is available in the instruction cache of the baband processor, eliminating wait states to fetch the instructions from the external flash memory.
Proceeding of the SDR 05 Technical Conference and Product Exposition. Copyright © 2005 SDR Forum. All Rights Rerved
As for volatile memory (for scratch pad data memory), the physical layer demands on the data storage needs to be analyzed to assure that the needs of the program do not exceed the handt’s available RAM. On the other hand, the RAM requirements are to be kept at a reasonable level not to exceed the budgeted power consumption for the handt. As two examples, the Sony Ericsson P900 GPRS, HSCSD, WAP, Java, MMS, HTML browr, email client, built-in digital camera, touch-nsitive display, polyphonic ringtones, MP3 player, MPEG 4 video, handwriting recognition, Bluetooth, infrared, USB port and many more. The phone is equipped with 48MB of RAM. The Nokia
9300 supports following bearers: CSD, HSCSD, GPRS multislot class 10, class B, EGPRS class 10 Bluetooth, IR (115 kbps). It has 64 MB SD RAM, 128MB Flash. Out of the on-baord RAM, the free ur memory is 80MB, indicating amount ud by the physical layer and the protocol stack). 5. PROGRAMMING FOR THE RF-BASEBAND INTERFACE There is a significant paradigm shift in thinking of and implementing the real-time data flow in a software bad transceiver. The offts in time are to be thought of as offts in memory buffers. Activation of specific events at specific time instances are then computed in software and then implemented using on-board timers. For example in a TDMA bad system, the time slots received in the receive buffers are collected. Subquently “cell-arch” is performed on the collected data, determining the start position of the time slots and the transmission frame. Now the indicator for the start of frame is simply a memory pointer. Since the control software is aware of the correspondence of the actual time of arrival of the data and its location in the receive buffer, an offt into the buffer can simply be converted to a calculated offt in time. This offt in time is ud to turn on an on-board timer. This timer is programmed to initiate transmit of a frame to the ba station at the preci instant governed by the receive frame start time. As software adjusts timing during operation, the transmit time will also be adjusted to maintain the critical strict timing relation between receiving and transmitting. This idea is further developed later in this paper. 6. MULTI-PROGRAM SUPPORT The Sandbridge software tools have the ability t
o combine multiple executables together, without going through the difficult task of manual name mangling of conflicting names in the two executable files. The ur has to follow the following steps to combine two executable files into a single executable file.
Compile all the object files for a program (say 'prog1') and gather them into an archive (say ‘prog1.a’} 2. This will put all the prog1.o files in to the archive 'prog1 a', instead of into an sbx file. 3. Repeat the above steps for all programs so that you have archives 'prog1 a', 'prog2.a' etc. 4. Indicate the main functions for the programs. For example, prog1 0, prog2 () etc. 5. Write a program that will invoke the (t of main functions) as and when needed, say driver.c Link them together. As a result, the executables for veral waveforms can be combined into a single executable which will be resident in the flash memory of the wireless terminal. This convenient arrangement reduces the task of invoking different waveforms to simply “calling a function” associated with that waveform. Therefore even though traditional approaches such as marking a flag in the non-volatile memory and “re-booting” to the new waveform are still possible and available, the process can be streamlined significantly by this technique. 7. SYSTEM SOFTWARE PSEUDO-CODE Using the convenient multi-program support of the tools, one possible pudo-code for the main operational quence of the handt software can be compod as follows. It is noteworthy tha
t in the following quence, ur input via a key press or menu lection would result in the reconfiguration of wireless terminal into a new waveform. Power on/Ret For all supported waveforms Perform cell arch Mark waveform as detected Display all detected waveforms Perform sky arch Display GPS data Wait for ur input for waveform lection Do forever If waveform lected Call the routine for the lected waveform physical and protocol stack If different waveform lected by the ur Perform cell arch If detected Call the routine for the lected waveform physical and protocol stack El Display error
1.
Proceeding of the SDR 05 Technical Conference and Product Exposition. Copyright © 2005 SDR Forum. All Rights Rerved
A typical startup of a detected waveform could be as follows: Select a ba station Activate upper layers/protocol stack Decode broadcast channel information Enter idle mode Monitor paging channel for incoming calls Monitor keypad for ur initiated out-going calls
•
Etc.
9. PROJECTION OF POWER CONSUMPTION FOR A PARTICULAR WAVEFORM Bad on the average power consumption derived for a single core of a multi-core device, such as the Sandbridge SB3010, one can estimate the expected power consumption of any waveform once its MHz (or MIPS) requirements are determined. This calculation is very simple in that the total MHz is converted to the number of DSP cores required to run the waveform in real-time (keeping the fractional part). The number of cores is then multiplied by the nominal figure for the average power consumption for the waveform. The following example illustrates the power consumption calculations for the 384kbps WCDMA physical layer. Total MHz demand = 1800MHz 1800 / 600 = 3 Cores Average Power consumption = 3 Cores * N mW/Core The following considerations are noteworthy in power consumption calculations: 1. The calculated power is average. It can be further lowered by taking into account duty cycle of the running code as per sleep mode and discontinuous reception/transmission specifications of a standard waveform. 2. Many power management techniques can be employed to significantly reduce the projected power number derived above. The techniques include frequency and voltage scaling, operating system bad core/thread clock gating etc. 3. The power consumption discussion above pertains to baband only and therefore excludes RF ction power consumption.
华尔街英语
8. TERMINAL RECONFIGURATION MANAGEMENT Implementation of the terminal reconfiguration management, control through “privileged over the air command”, or local command or event triggered command can all be easily implemented in software as the SandBlaster™ SDR baband Processor is capable of supporting any control program as well as DSP algorithms. A typical protocol stack configuration is shown below:
Figure 3 - Typical Protocol Stack with O&M
O & M (Operations and Maintenance) is a protocol specific to any particular implementation whereby specific logical channels carry commands and information for maintenance of the wireless terminal. As en in figure above, the O&M protocol relies on the layers 2 and 3 that carry the signaling for call processing. Proprietary commands such as the following are typical O&M commands that can be relayed to the wireless terminal over the air: • • • • Status Request Reconfiguration Request Firmware Update Request Restart Request
12. CONCLUSION Several techniques and approaches to implement SDR bad terminals were discusd in this paper. As can be en, the techniques are evolving to be significantly different from the “logic gate” approach. The success of a SDR bad terminal mostly depends on a powerful SDR
processor platform and the software development tools that enable the designers in a timely design/implementation/debug cycle. The Sandblaster™ platform along with its software development environment ud as an example in this paper provide such a platform.
Proceeding of the SDR 05 Technical Conference and Product Exposition. Copyright © 2005 SDR Forum. All Rights Rerved
cgu
13. REFERENCES [1] B. Beheshti, J. Glossner, D. Routenberg, L. Zannella, and P. Steensma, “Evaluation of Military Waveform Processing on a COTS Reconfigurable SDR Processing Platform“, Proceedings of Software Defined Radio Technical Forum, Volume A, pp. 147-151, 16-18 November, 2004, Scottsdale, Arizona. [2] B. Beheshti, “A Study of the Technology Migration Path of the Cellular Wireless Industry from 3G to 3.5G and Beyond”, Proceedings of 2005 IEEE Long Island Systems, Applications and Technology Conference (LISAT2005), May 2005, Farmingdale, New York.www.sdrforum [3] D. Iancu, J. Glossner, V. Kotlyar, H. Ye, M. Moudgill, and E. Hokenek, “Software Defined Global Positioning Satellite Receiver”, Proceedings of the 2003 Software Defined Radio Technical Conference (SDR’03), HW-2-001, 6 pages, Orlando, Florida, 2003. [4] J. Glossner, D. lancu, J. Lu, E. Hokenek, and M. Moudgill, “A Software Defined Communications Baband Design”, IEEE Communications Magazine, Vol. 41, No.1, pp. 120-128, J
an., 2003.
[5] D. lancu, J. Glossner, E. Hokenek, M. Moudgill, V. Kotlyar, “Software GPS receiver”, Accepted for publication is the 2003 Software Defined Radio Technical Conference and Product Exposition November 17-19,2003 - Orlando, Florida. [6] J. Glossner, S. Dorward, S. Jinturkar, M. Moudgill, E. Hokenek, M. Schulte, and S. Vassiliadis, “Sandbridge Software Tools”, in Proceedings of the 3rd International Worksop on Systems, Architectures, Modeling, and Simulation (SAMOS.p3), July 21-23,2003, pp. 142-147, Samos, Greece. [7] J. Glossner, T. Raja, E. Hokenek, and M. Moudgill, “A Multithreaded Processor Architecture for SDR”, The Proceedings of the Korean Institute of Communication Sciences, Vol. 19, No. 11, pp. 70-84, November, 2002. [8] J. Glossner, E. Hokenek, and M. Moudgill, “Multithreaded Processor for Software Defined Radio”, Proceedings of the 2002 Software Defined Radio Technical Conference, Volume I, pp. 195199, November 11-12, 2002, San Diego, California.
Proceeding of the SDR 05 Technical Conference and Product Exposition. Copyright © 2005 SDR Forum. All Rights Rerved大连培训网
