OFDM-MIMO接收器的SDR实现与算法优化

ofdm

mimo

需积分: 9 128 浏览量更新于2024-07-31 收藏 5.01MB PDF 举报

身份认证购VIP最低享 7 折!

领优惠券(最高得80元）

本硕士论文报告名为《SDR实现OFDM-MIMO接收器》（SDRImplementationofaOFDM-MIMOReceiver），由2008年10学期AAU应用信号处理与实现（ASPI）小组的项目组1046完成，主要作者为Morris Filippi。论文主题聚焦在现代通信领域中的多输入多输出（MIMO）系统及其在离散傅立叶变换多载波（OFDM）接收器中的应用。在通信工程中，多样性是一种关键概念，特别是通过多个天线同时传输信号，即空间分集或多输入多输出（Spatial Diversity）。MIMO技术通过同时在多个天线上传输数据，实现了空间复用（Spatial Multiplexing）和空间时间编码（Space-Time Coding），从而在保持硬件实现约束、功率和带宽可用性的同时，提高了数据速率。这种技术利用了多天线传输的冗余，允许接收端通过精确算法进行解码。项目的核心目标是研究哪种算法改进可以提升OFDM/MIMO接收器的频谱效率，同时确保其硬件可行性。设计师在报告中提出了针对这一问题的解决方案，着重介绍了两种新型技术。这些技术旨在解决当前接收器在处理OFDM信号时可能面临的挑战，例如信号干扰、信道估计和多径效应，通过优化解调算法、降低噪声性能的影响，以及可能的信道编码和解码策略的创新，以提高整体系统的性能。具体来说，这两种新技术可能涉及： 1. **高效信道估计方法**：OFDM-MIMO系统中，信道估计至关重要，新的算法可能采用更先进的压缩感知（Compressive Sensing）或深度学习技术来估计多径衰落，减少误码率并提升信号质量。 2. **智能解调技术**：可能设计出基于机器学习的自适应解调器，能够根据实时信道条件调整解调策略，比如联合检测（Joint Detection）或迭代解调（Iterative Detection），提高数据传输的可靠性。 3. **编码和交织技术的改进**：可能引入新的编码方式，如低密度奇偶校验码（LDPC）或者卷积码的优化，结合MIMO系统的特性，以进一步提升系统的信息传输效率。 4. **软判决合并（Soft-Decision Combining）**：利用软信息来合并来自不同天线的数据，这有助于在多径环境中改善信号融合，增强抗干扰能力。 5. **硬件效率的优化**：在算法实现层面，可能会探讨如何在保证性能的同时，降低硬件复杂度，比如通过硬件加速器、低功耗设计或并行处理技术。这篇论文不仅探讨了OFDM-MIMO接收器的基础理论，还深入到实际应用层面，提供了对现有技术的改进和创新，对于理解和优化无线通信系统的性能具有重要的实践价值。

资源详情

资源推荐

The activity starts from the extreme of the Behavioural axis, the designer translates the

expressions by using hand or automatic synthesis, obtaining the first step of the Structural

domain. These actions by connecting archs is represented, creating a circular trend around the

Y-Chart. Note that at the end of every synthesis, a verification is done, as shown in Figure 2.3.

The Y-Chart can be fitted to this project identifying the possible steps on the three

domains. The result is the scheme in Figure 2.4, where the various synthesis archs have been

omitted for graphical reasons.

Figure 2.4: Y-Chart

Methodology adapted to this projec, with the various levels. Inspired by

Figure 2 [3] and Figure 1 [4] .

The adapted Y-Chart shown in Figure 2.4 has additional levels on its axes, necessary to

split in variouos implementation steps. The first level of the Behavioural domain indicates the

OFDM-MIMO functionalities, followed by the modulations and the multiple antennas

systems, the algorithms which describes the whole system and the lower boolean functions.

Finally the transistor physical equations.

The Structural domain reports the components at various abstraction levels with the

functional connections. Note that the number of unities considered increases towards the

center of the Y.

The Geometrical representation reports the physical connections at the respectives level

of components considered. From the highest level there are Layout Planning, Clusters, Floor

Plans, Mask Geometries and Physical Layout. But note that in this project the FPGA is

already manufactured and it is programmed through automatic mapping, place & route and

bit-stream generation.

STUCTURAL BEHAVIOURAL

Xilinx FPGA,

Memory OFDM

MIMO

HW modules 4x4, modulations

Operators Algorithms

ALUs, MUXs, Reg

Slices, LUT Boolean Function

Circuit Transistor Equations

Physical Layout

Mask Geometries

Floor Plans,

Connections

Clusters

The FPGA is already manufactured

programmed by atomatic compiler

Layout

Planning

GEOMETRICAL

2.3. ATtACk Methodology

Attack [5] is a methodology based on the Rugby Meta-Model [6], discussed in 2.4,

conceived to extend this model to dynamic partially reconfigurable systems on FPGA. The

name ATtACk derives from the four domains which compose the methodology: Algorithm,

Time, Architecture and Communication. A second flow specifies the four phases, common

for each domain: Specification and Requirements, System Model, Design and

Implementation. Figure 2.5 shows the methodology graph, with an overview of the domain

levels.

Figure 2.5: ATtACk Methodology, a generic case of implementation, with the four domains

and four phases. Inspired by Figure 2 [5].

The four domains which compose the Attack methodology are now described.

 Algorithm, specifies the various mathematical expressions and correlations. Note

that for the partial reconfiguration these algorithms must be two or more. The

first step is to analyze the documentations and background in order to identify the

subjects, second translate them to Control Data Flow Graphs (CDFGs) to list the

execution steps. By examining the CDFGs it is possible to identify the two

modules, static and dynamic, for the partial reconfiguration.

 Architecture, defines the hardware platform where the algorithms have to execute.

At first it is necessary to identify the possible device analyzing the various

features, as i.e. the FPGA chip, the In/Out ports, memory and interface devices

(i.e. ADC/DAC, audio ports, etc.). The second phase is to identify the parts of the

platform which compute the algorithms. Third, the FPGA can be divided in static

and dynamic areas to perform the eventual partial reconfiguration, so it is

necessary to use special tools provided by the FPGA producers, such as PR flow

from Xilinx [36].

 Communication, treats every signal that transfers data, address and control

information, considering the connections and the data format. This domain allows

TIME COMMUNICATION

Constraints Input & Output

Causality Entity Interface

Configuration Time Inter module comm.

Physical Clock Busses

Target

Programming Pin out config.

IMPLEMENTATION

Modules PE partitioning

DESIGN

Flow Chart Entities

SYSTEM MODEL

Functionality Platform

ALGORITHM ARCHITECTURE

SPECIFICATION AND

REQUIREMENTS

to identify the links on the platform, inputs and outputs. Second step is to connect

the functional blocks having a look on the static and dynamic areas. Finally the

platform has to be linked to the testing environment, that could be a tool for co-

simulation running on a computer.

 Time, treats all the information regarding the execution time of the system at the

various abstraction levels. Initially there are generic constraints only, the next

level expresses causality between the steps of the CDFG. At the third level the

operators and the connections can introduce delays that have to be considered.

Finally the delays of the physical components and wires, but also the

reconfiguration time to change between dynamic blocks are expressed.

The Attack methodology has been conceived for dynamic partial reconfiguration, but can

be adapted to this project, considering that this FPGA’s functionality is not used. Figure 2.6

shows a possible fit for this project.

Figure 2.6: ATtACk Methodology applied to this project, with the four domains and an

additional phase (Xilinx design) in the design step. Inspired by Figure 2 [5].

Some part of the scheme shown in Figure 2.5, for this customized version are maintained.

As already reported, adapting the Attack methodology to this project requires a modification

of the design phase. Figure 2.6 shows that the third phase has been split in two phases, in

Figure 2.5, Matlab Simulink design and Xilinx System Generator (SysGen) oriented design.

In fact, even if the development environment is the same, Matlab Simulink, the libraries

changes, and that means the operators change. In the Simulink Design phase the operators are

standard blocks, S-functions and Matlab-functions, and for the following phase the

components are Xilinx blocks at lower abstraction level. So, some part of the project scheme

have to be translated manually using basic operators.

In Figure 2.6 for the two design phases, the same level on the four domains is shown, but

note that both of them can have different Operators, Inter module communications, and

Sample Times. On the other hands, the Operations must remain the same.

TIME COMMUNICATION

Constraints Input & Output

Causality Unit interfaces

Sample Time Inter module comm.

Physical Clock Links

Target

Programming Pin out config.

IMPLEMENTATION

Operations

XILINX SYSGEN DESIGN

Operators

SIMULINK DESIGN

Flow Chart Performing units

SYSTEM MODEL

Modulations Target Platform

[2x2, 4x1,4x4] Xilinx Virtex 5

ALGORITHM

SPECIFICATION AND

ARCHITECTURE

REQUIREMENTS

2.4. Rugby Meta-Model

The Rugby Meta-Model [4] and [6] is a methodology for electronic system design based

on the Y-Chart [3] and [4], but it extends the domains in order to manage more complex

systems, as those which present hardware and software implementation. Rugby is divided by

four domains, Computation, Communication, Data and Time, each split into phases. These

phases correspond to different levels of abstraction. The Rugby methodology can consider

split or mixed HW/SW implementation, in this report, only the mixed version is explained.

An important comparison between two similar concepts are treated:

 Hierarchy, which is the subdivision of the design models in steps. Each step

indicates the amount of information used to describe the system, while other

details are hidden.

 Abstraction, which specifies the models and the semantics used in a project at

various steps. These models represent the behaviour of the components used to

describe the system, and at each level information are respectively detailed.

While the abstraction levels are pre-defined for every HW/SW implementation, the

hierarchy is a designer choice, for instance each abstraction level and domain can represent a

hierarchical step. Because of this general concept, Hierarchy is not explicitly specified in the

Rugby Meta-Model.

Figure 2.7: The Rugby Meta-Model, a generic scheme that shows the starting point (initial

idea), the arrival point (physical system), four domains (computation, communication, data,

time), and the two trend lines (abstraction and time). Inspired by Figure 4 [4].

As already mentioned, Rugby is based on the Y-chart, but is extended in the domains. In

fact in this methodology the domains are four instead of three, and treat different fields:

 Computation, which indicates the mathematical expressions and relations

between data inputs and outputs. For each abstraction level, these computations

assume different descriptions, which are related to the considered component. For

instance at physical level, as the interactions between transistors, resistors,

capacities, the computations are differential equations that indicate the behaviour

of the electric current in relation to the voltage. Another example, at high

abstraction level, is the algorithm that a block can perform considering analog or

digital components, as amplifiers or modulators, etc.

 Communication, which specifies the links between the various components of the

design. These connections can be a functional link between main blocks or, for

instance, physical wires from a resistence to the gate of a silicon transistor,

considering a very low abstraction level. Moreover, these connections can

support various types of information, as controls, data, addresses.

 Data, which reports the types of data and the quantities that are computed. At an

intermediate abstraction level, the data can be real or imaginary numbers, defined

in time or frequency domain. Considering logical level, data are boolean values,

and at transistor level are real numbers which indicate the voltage or other

physical quantities.

 Time, which indicates the time-relation between components and, as in the others

domains, for the various abstraction levels is defined. In fact, every component

needs its computation time and every connection its delay, so these behaviours

have to be considered in the design. Note that at software level, the causality

relation only is treated.

The Rugby Meta-Model can be adapted to this project as for the previously considered

methodologies (Attack, Y-Chart). As already indicated, the Rugby mixed HW/SW only is

treated, because this project has not split implementation but a sequential software-hardware

flow.

Figure 2.8: Rugby Meta-Model, the scheme adapted for this application. The Abstraction line

has been divided in eight levels. Inspired by Figure 4 [4].

Figure 2.8 represents the scheme of Rugby fitted to this project. There is a sub-division of

the abstraction line in eight steps, starting from the initial idea to the physical implementation.

In Constraints & Requirements there is an indication about the main contents, the target

Xilinx FPGA and the various SIMO/MIMO schemes. The same goes for System Analysis &

Modeling, where the main parts of the system are shown. The fourth step consists in the

implementation of the system by using the development program Matlab and the grafic tool

Simulink, with the standard libraries provided by Mathworks. This step has been split from

剩余115页未读，继续阅读

xgod1973

粉丝: 0
资源: 2

OFDM-MIMO接收器的SDR实现与算法优化

软件无线电OFDM收发技术实现

SDR_Matlab_OFDM_802.11n：使用软件设计的无线电以5 GHz的频率发送MIMO-OFDM QPSK信号

4G通信系统中OFDM技术的分析

matlab simulink QPSK信号接收解调中RTL-SDR Receiver模块的作用

使用RTL-SDR Receiver为什么有固定频偏

matlab simulink中RTL-SDR Receiver模块的作用

使用RTL-SDR Receiver为什么需要调节固定频偏

plutosdr-m2k-usb-drivers.exe

make menuconifg中的 SDR tuner chips ---> 介 绍

plutosdr-m2k-usb-drivers.exe - v0.9

介绍一下multi-sdr-gps-sim项目的用法

rtl-sdr*ads-b*matlab

sdr ofdm 解调 c++

multi-sdr-gps-sim

plutosdr-m2k

c++ gnss SDR

极化码在5G通讯中的应用

gnss-sdr loss of lock in channel

SDR NB-IoT

half-logSNR概念，sdr是什么

最新资源

make menuconifg中的 SDR tuner chips ---> 介绍

rtl-sdrads-bmatlab