Kiến trúc phần mềm Radio P6

Chia sẻ: Tien Van Van | Ngày: | Loại File: PDF | Số trang:8

Thêm vào BST

Báo xấu

99
lượt xem 9
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

Segment Design Tradeoffs I. OVERVIEW The six steps in the systems-level design process associated with the software radio are illustrated in Figure 6-1. The tradeoffs proceed from front end to back end. The choice of antennas (step 1 in the figure) determines the number and bandwidth of RF channels (step 2). This, in turn, constrains the numbers and bandwidths of ADCs (step 3). Some waveforms may require dedicated ASICs (e.g., W-CDMA despreaders) in front of the ADCs. Additional parallel IF processing and ADC paths may be necessary to support multiple-service bands simultaneously....

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Kiến trúc phần mềm Radio P6

Software Radio Architecture: Object-Oriented Approaches to Wireless Systems Engineering Joseph Mitola III Copyright !2000 John Wiley & Sons, Inc. c ISBNs: 0-471-38492-5 (Hardback); 0-471-21664-X (Electronic) 6 Segment Design Tradeoffs I. OVERVIEW The six steps in the systems-level design process associated with the software radio are illustrated in Figure 6-1. The tradeoffs proceed from front end to back end. The choice of antennas (step 1 in the figure) determines the number and bandwidth of RF channels (step 2). This, in turn, constrains the numbers and bandwidths of ADCs (step 3). Some waveforms may require dedicated ASICs (e.g., W-CDMA despreaders) in front of the ADCs. Additional parallel IF processing and ADC paths may be necessary to support multiple-service bands simultaneously. The ADCs provide high-speed streams for heteroge- neous multiprocessing (step 4). Digital interconnect fans these streams out to digital-filter ASICs. The resulting narrowband streams then interleave among DSPs, medium-speed interconnect, and general-purpose processors yielding a multithreaded, multitasking, multiprocessing operating environment. Software objects must be organized into real-time objects (step 5). The effective hosting of these objects onto this complex operating environment requires a refined set of techniques unique to this text called SDR performance management (step 6). These six tradeoff steps are introduced in this section and discussed in depth in the subsequent chapters. Figure 6-1 Six-step segment design-tradeoff process. 236
ANTENNA TRADEOFFS 237 Figure 6-2 Antenna tradeoffs. II. ANTENNA TRADEOFFS The first tradeoff defines the structure of the antenna segment and implicitly the RF conversion segment. Maximum system performance requires resonant narrowband antennas. As illustrated in Figure 6-2a, this approach typically re- sults in multiple parallel antenna/RF conversion channels. In the specific case illustrated in the figure, an advanced PDA needs to operate in first-generation cellular (AMPS), and second- or third-generation digital cellular (PCS) bands. In addition, for location-aware services, the PDA has a GPS receiver. Finally, in order to operate on the corporate RF LAN, it supports a LAN band. One could fabricate such a PDA with parallel RF channels. The physical inte- gration of the disparate RF devices presents challenges. Given a commodity GPS chip and a Bluetooth-class RF LAN, however, the parts costs could be low. The broadband approach illustrated in Figure 6-2b simplifies the antenna and RF design to only two parallel channels. Finally, Figure 6-2c illustrates the spectral coverage of a single wideband antenna. Note that the antenna response is not uniform across such a broad range. The broad spectral cov- erage needed for SDR flexibility therefore can drive one toward many par- allel overlapping narrowband channels. This can be an effective approach if cost is not a major consideration. Alternatively, the design may employ fewer channels with wider RF coverage per channel. Transmission efficiency and matching voltage standing wave ratios (VSWR) are more challenging as band- width increases. Below 100 MHz, multi-octave antennas and RF segments are
238 SEGMENT DESIGN TRADEOFFS well-established products. As frequency increases, wavelengths approach the physical dimensions of the RF devices, making it more difficult to exceed an octave of RF coverage. Since antennas, RF conversion, and IF processing through the first ADC can account for over 60% of the manufacturing cost of an SDR node, reducing the number of RF channels is a significant design tradeoff. III. RF AND IF PROCESSING TRADEOFFS The second tradeoff concerns RF and IF conversion. Multichannel transceivers in TDD bands require an interference-suppression architecture that could in- clude antenna isolation, programmable analog filters, and/or active cancella- tion. The transmitter may require both linear operation (e.g., for W-CDMA and QAM waveforms) and nonlinear operation (e.g., class-C amplifier for high- power efficiency with FSK or PSK waveforms). Single-channel receivers may resort to nonlinear distortion of the incoming waveform (e.g., for a narrow- band direct-conversion architecture). Multichannel receivers, on the other hand, must match the RF and IF con- version parameters to the ADC, digital filtering, and signal recovery algo- rithms of the back-end. The goal of this tradeoff is to balance the noise, spurious components, intermodulation products, and artifacts as illustrated in Figure 6- 3. The receiver may include multiple RF/IF conversion stages (e.g., a superheterodyne—“superhet”—receiver). Alternatively, a single stage may convert the RF signal directly to baseband (the direct-conversion or “homo- dyne” receiver) [241]. Since the direct-conversion receiver has fewer parts, its manufacturing costs may be less than the superhet, which may have better performance. The thermal noise floor will be determined by the total band- width (e.g., in interference-limited bands below 400 MHz), or by the first LNA (e.g., in cellular and microwave bands). The thermal noise will be processed through the RF and IF conversion stages, resulting in noise shaping across the passband. Spurious responses (“spurs”) and LO leakage can mask subscriber signals if ineffectively filtered. LO leakage can be particularly problematic in homodyne receivers [245]. A well-balanced architecture keeps the peak en- ergy of all noise, spurs, and artifacts at about half of the least significant bit (LSB) of the wideband ADC. IV. ADC TRADEOFFS The third tradeoff is the design of the ADC segment. Maximum sampling rate is obtained for a given clock technology in a quadrature-sampling ADC architecture. Such ADCs can introduce nonlinearities due to mismatching be- tween the in-phase (real) and quadrature (imaginary) conversion channels. Real oversampling with digital quadrature provides a lower-complexity alter-
DIGITAL ARCHITECTURE TRADEOFFS 239 Figure 6-3 RF tradeoffs include staging, conversion frequencies, and filtering. native. In addition, one must match the ADC architecture to the structure of the service bands being supported. If two or three 25 MHz bands spaced hundreds of MHz apart are to be supported, one may have more total dy- namic range using multiple medium-bandwidth ADCs instead of one su- perwideband (e.g., 500 MHz) ADC. Each medium-bandwidth ADCs access band may be programmable by tuning the final LO. Such an approach there- fore complicates the RF architecture, but reduces the interconnect band- width and processing capacity of the next stage. The set of ADC architec- ture alternatives is similar to the RF access alternatives illustrated in Figure 6-2. V. DIGITAL ARCHITECTURE TRADEOFFS The fourth tradeoff concerns the mix of parallelism and pipelining of the digital signal processing hardware from ASICs and FPGAs to DSPs and general-purpose processors. Figure 6-4 illustrates the processing flow among wideband ADCs, DACs, and reconfigurable ASICs or FPGAs. High-speed (gigabyte-per-second) digital interconnect is necessary to fan wideband ADC streams out to digital filtering FPGAs or ASICs. Reconfigurable processors and despreader ASICs may reduce or eliminate the need for wideband dig-
240 SEGMENT DESIGN TRADEOFFS Figure 6-4 Digital architecture tradeoffs. ital interconnect by either embedding the interconnect on-chip or producing baseband streams directly. Digital filtering of high-data-rate ADC streams yields much lower data rate subscriber baseband channels. Medium bandwidth digital interconnect (hun- dreds of megabytes per second) then provides flexible paths among DSPs and general-purpose processors. The architecture of local and global mem- ory among the processors also can be a significant contributor to algorithm performance. Balancing these high-speed data flows and bandwidth reduction steps against clusters of processing capacity and memory is a central con- cern of the digital architecture tradeoffs. The selection of an appropriate ISA is part of this step that determines the availability and maturity of software tools. VI. SOFTWARE ARCHITECTURE TRADEOFFS The fifth tradeoff concerns the organization of the radio software into appro- priately packaged data structures and real-time algorithms. Figure 6-5 sum- marizes software design tradeoffs as a function of the level of abstraction of the capability. At the highest level, interfaces among applications and services need to be radio-aware so that the radio’s low data rates, high variability in data transfer times, and occasional outages do not severely curtail user satis- faction with the services. In the radio applications layer, object-oriented de- sign techniques help group related data structures with appropriate algorithm methods. This simplifies detailed design, development, testing, deployment, and evolution of the software architecture. The terminology and approaches of object-oriented design may be applied to all the functions of the radio. This facilitates the realization of those functions in hardware, firmware, or software, as a function of technology and project needs.
PERFORMANCE MANAGEMENT TRADEOFFS 241 Figure 6-5 Overview of software architecture tradeoffs. Projects may be implemented using conventional software techniques. With such approaches, the radio applications and infrastructure software elements are intricately interwoven. Open-architecture approaches now favor the use of the industry-standard CORBA [216] in radio infrastructure middleware. Such middleware reduces the coupling between radio functions and distributed pro- cessor hardware. This adds flexibility but requires processing capacity above that which is needed for a closed architecture. Accurate characterization of the processing requirements of modular collections of open-architecture software can be challenging. At the lowest level of abstraction is the real-time interface to the hardware platform. This includes not just the processors, but the many computer-controlled features of the analog radio platform. Software design tradeoffs, then, include both top-down application of open-architecture princi- ples and bottom-up integration of existing hardware, firmware, and software components. VII. PERFORMANCE MANAGEMENT TRADEOFFS The final major tradeoff concerns the management of processing demand of- fered by the software against the resources provided by the hardware platform. Accurate characterization of processing demand requires benchmarking. Ac- curate prediction (e.g., at proposal time), can be accomplished using queuing theory techniques that have been refined and reduced to the structured method described in the corresponding chapter of this text. A sustained measurement and instrumentation campaign to monitor performance implications of de- velopment decisions reduces development risk. Performance prediction and management steps add cost to a software radio development program. One therefore must balance the cost of performance management against the bene- fits of reduced development risk. This text shows how to manage performance affordably.
242 SEGMENT DESIGN TRADEOFFS VIII. END-TO-END TRADEOFFS Other important tradeoffs include end-to-end tradeoffs. One of the most im- portant in the software radio is the allocation of dynamic range among RF, IF, ADC, DSP hardware (e.g., FPGAs and ASICs), and algorithms. Another is the allocation of software objects to hardware components. After considering the antenna segment, the RF, ADC/ DAC, DSP, software, and integration aspects are considered in turn. IX. EXERCISES The following questions review the material in the first part of the text. They also motivate the subsequent chapters. 1. Review the disaster-recovery case study. List the RF bands that need to be addressed. What antennas are needed? Search the web for COTS antenna products. List antenna products that you would employ in a contemporary design. Which of these antennas are programmable? Is there any flexibility that could be software-defined? What about a next-generation product? 2. Continuing with the case study, list the RF conversion components that are needed in a conventional design. What is the modularity of these compo- nents? What fraction of these components are integrated transceivers, and what fraction are modular at some other level of granularity? Is the data processing in devices physically separate from the RF access? Could the baseband streams (e.g., voice and data) be switched in software on LANs and workstations? How much work is it to determine the answer to this question? Did you use a systematic method to address this question? Do you know of one that you could have used? 3. Also in the case study, from the bandwidths of the RF access bands derive the bandwidths of the ADCs necessary to access these bands digitally. What are the output bandwidths of these ADCs in MBps? 4. Suppose narrowband channels (e.g., AM and FM push-to-talk) require 10 MFLOPS and second-generation standards like GSM require 30 MFLOPS per channel. How much digital signal processing capacity is required for the disaster-recovery application? How many vans are in your system? If you do not know, assume there are five. Can the channel capacity be partitioned among these vans? How many of what kinds of processors do you need? You could multiply the number of channels times the processing requirements per channel and then divide by the capacity of a processor. You could also apply some factors for realism, such as multiplying the number of processors by two so that each has 50% spare capacity. Does this yield an adequate sizing of the processors? Are they dedicated or pooled?
EXERCISES 243 5. What software is needed for the disaster-relief case study? Of this software, which modules are in the front-end, which are in the back-end, and which are distributed across the system? How many lines of code will be in the system? How can you estimate this parameter? 6. What are the end-to-end issues in this case study?