Cleiber Marques da Silva
Uma Arquitetura Reconfigurável Heterogênea para
Rádios Definidos por Software utilizando uma
Rede-em-Chip
FLORIANÓPOLIS
2012
UNIVERSIDADE FEDERAL DE SANTA
CATARINA
PROGRAMA DE PÓS-GRADUAÇÃO EM
AUTOMAÇÃO E SISTEMAS
Uma Arquitetura Reconfigurável Heterogênea para
Rádios Definidos por Software utilizando uma
Rede-em-Chip
Dissertação submetida à
Universidade Federal de Santa Catarina
como parte dos requisitos para a
obtenção do grau de Mestre em Engenharia
de Automação e Sistemas.
Cleiber Marques da Silva
Florianópolis, Julho, 2012.
Uma Arquitetura Reconfigurável Heterogênea para
Rádios Definidos por Software utilizando uma
Rede-em-Chip
Cleiber Marques da Silva
Esta Dissertação foi julgada adequada para a obtenção do tı́tulo de “Mestre” em
Engenharia de Automação e Sistemas, Área de Concentração em Controle,
Automação e Sistemas, e aprovada em sua forma final pelo Programa de
Pós-Graduação em Engenharia de Automação e Sistemas da Universidade Federal de
Santa Catarina.
Leandro Buss Becker, Dr.
Orientador
Antônio Augusto M. Fröhlich, Dr.
Co-orientador
Prof. Jomi Fred Hubner, Dr.
Coordenador do Curso
Banca examinadora:
Prof. Mario de Noronha Neto, Dr.
Instituto Federal de Santa Catarina
Prof. Carlos Aurélio Faria da Rocha, Dr.
Universidade Federal de Santa Catarina
Prof. Marcelo Ricardo Stemmer, Dr.
Universidade Federal de Santa Catarina
iii
Aos meus pais e amigos.
v
AGRADECIMENTOS
Em primeiro lugar, gostaria de agradecer aos meus amigos e familiares pelo apoio,
confiança e incentivo.
Um especial agradecimento ao meu orientador professor Leandro Buss Becker pelo apoio
em todos os momentos do desenvolvimento do trabalho.
Ao professor Antônio Augusto Fröhlich, pelas oportunidades dadas para realização
deste trabalho e a equipe do LISHA por todo o apoio durante a execução do projeto eSDR.
vii
Resumo da Dissertação apresentada à UFSC como parte dos requisitos necessários
para obtenção do grau de Mestre em Engenharia de Automaçãoo e Sistemas.
Uma Arquitetura Reconfigurável Heterogênea para
Rádios Definidos por Software utilizando uma
Rede-em-Chip
Cleiber Marques da Silva
Junho/2012
Orientador: Leandro Buss Becker, Dr.
Co-orientador: Antônio Augusto M. Fröhlich, Dr.
Área de Concentração: Controle, Automação e Sistemas
Linha de Pesquisa: Arquitetura de Computadores
Palavras-chave: Rádios Definidos por Software, Redes-em-Chip e Arquitetura
Número de Páginas: xxvi + 86
Rádio definido por Software (SDR) é uma tecnologia que permite a reconfiguração de
um sistema de comunicação sem a necessidade de alterar qualquer elemento de hardware utilizando uma abordagem baseada em software. Entretanto o crescimento da
complexidade dos novos padrões de comunicação juntamente com a necessidade da
redução do consumo de energia são os desafios para as arquiteturas de SDRs. Abordagens utilizando computação reconfigurável com granularidade grossa são bons candidatos para solução dos problemas, pois possuem alta performance e baixo consumo
de energia. Neste contexto esse trabalho propõe uma arquitetura heterogênea e reconfigurável para o desenvolvimento de SDRs com FPGAs utilizando uma Rede-em-chip
(NoC) para a infraestrutura de comunicação e aceleradores em hardware para o processamento dos principais algoritmos de processamento de sinais. NoC é uma tecnologia
emergente para a interconexão em-chip que propõe a solução de problemas de escalabilidade, reuso e controle dos parâmetros elétricos. A arquitetura proposta é basicamente
composta por uma interface RF, acelaradores, um bloco de controle e uma interface de
comunicação de alta velocidade com um host. Para validar a arquitetura proposta foi
desenvolvido um protótipo em FPGA utilizando um PC com GNU Radio como host.
Os testes demonstraram uma melhora significativa no desempenho global do sistema
em termos de uso de CPU e latência quando comparado com a plataforma USRP.
ix
Abstract of Dissertation presented to UFSC as a partial fulfillment of the requirements for
the degree of Master in Automation and Systems Engineering.
Software-defined Radio Heterogeneous
Reconfigurable Architecture using a
Network-on-Chip
Cleiber Marques da Silva
June/2012
Advisor: Leandro Buss Becker, Dr.
Co-advisor: Antônio Augusto M. Fröhlich, Dr.
Area of Concentration: Control, Automation and Systems
Research Area: Computer Architecture
Key words: Software-defined Radio, Network-on-Chip, and Architecture
Number of Pages: xxvi + 86
Software Defined Radio (SDR) is a technology that permit the reconfiguration of a
communication system without the need to change any hardware element using a
software-based approach. However, the growing complexity of new communication
standards together with the need to reduce the consumption energy are the challenges
for SDR architectures. Reconfigurable computing using coarse-grained approaches are
good candidates to solving SDR issues, because it have high performance and low
power consumption. In this context the work proposes a heterogeneous reconfigurable
architecture for the development of SDRs with FPGAs that uses a Network-on-Chip
(NoC) to enhance the internal communication infrastructure and hardware accelerators to speed DSP-related algorithms. NoC is an emerging technology for on-chip
interconnect that proposes the solution of scalability, reuse and control of electrical parameters. The proposed architecture is basically composed of a RF interface, hardware
accelerators, a control block and a high speed communication interface with a host. To
validate the proposed architecture it was developed a prototype in FPGA using a PC
with GNU Radio as host. The performed experiments demonstrate that the proposed
solution presents a significant improvement in the total performance of the system in
terms of CPU usage and latency when comparing with the off-the-shelf USRP.
xi
Sumário
1 Introdução
1
1.1
Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.2
Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
1.3
Visão Geral do Texto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
2 Tecnologias Relacionadas
2.1
Rádios definidos por Software . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.1.1
Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.1.1.1
RF Front-end
. . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.1.1.2
Digital Down Converter e Digital Up Converter . . . . . . .
8
GNU Radio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
2.1.2
2.1.2.1
2.2
2.3
5
Universal Hardware Driver . . . . . . . . . . . . . . . . . . .
11
Computação Reconfigurável . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
2.2.1
Dispositivos Reconfiguráveis . . . . . . . . . . . . . . . . . . . . . . . .
13
Network on Chip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
2.3.1
Arquitetura HERMES . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
2.3.2
SoCIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
2.3.3
Æthereal
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
2.3.4
QNoC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
2.3.5
RTSNoC
20
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
xiii
2.3.5.1
Formato dos pacotes na RTSNoC . . . . . . . . . . . . . . .
22
2.3.5.2
Estrutura interna do Roteador . . . . . . . . . . . . . . . . .
23
2.3.5.3
Simulação funcional do roteador . . . . . . . . . . . . . . . .
25
2.3.5.4
Adaptadores de Canais na RTSNoC . . . . . . . . . . . . . .
26
2.4
Desenvolvimento para FPGA em alto nı́vel . . . . . . . . . . . . . . . . . . .
26
2.5
Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
3 Trabalhos Relacionados
3.1
3.2
3.3
31
Arquiteturas com Processador Central . . . . . . . . . . . . . . . . . . . . . .
31
3.1.1
LeoCore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
3.1.2
Signal-processing On-Demand Architecture
. . . . . . . . . . . . . . .
33
3.1.3
Tomahawk
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
Arquiteturas Reconfiguráveis . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
3.2.1
ADRES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
3.2.2
BUTTER e CREMA . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
3.2.3
Arquitetura de Canais para SDR de Múltiplas Camadas . . . . . . . .
37
3.2.4
CRUSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
4 Arquitetura Heterogênea e Reconfigurável
41
4.1
Motivações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
4.2
Arquitetura Proposta
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
4.2.1
Bloco RF Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
4.2.2
Controle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
4.2.3
Interconexão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
4.2.4
Aceleradores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
4.2.5
Interface com o Host . . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
4.3
Fluxo de projeto para nova aplicações . . . . . . . . . . . . . . . . . . . . . .
52
4.4
Resumo da Proposta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
xiv
5 Implementação e Avaliação da Proposta
5.1
Implementação da Arquitetura Proposta . . . . . . . . . . . . . . . . . . . . .
55
5.1.1
FPGA Virtex-6 Xilinx . . . . . . . . . . . . . . . . . . . . . . . . . . .
55
5.1.2
BESDR - Placa Front-End RF . . . . . . . . . . . . . . . . . . . . . .
56
5.1.2.1
Caminhos de Recepção e de Transmissão . . . . . . . . . . .
57
5.1.2.2
Placas filhas . . . . . . . . . . . . . . . . . . . . . . . . . . .
59
5.1.2.3
Módulo de controle para BESDR . . . . . . . . . . . . . . . .
60
Interfaceamento da Proposta com GNU Radio . . . . . . . . . . . . .
60
Avaliação da Arquitetura Proposta . . . . . . . . . . . . . . . . . . . . . . . .
61
5.2.1
Implementação do experimento . . . . . . . . . . . . . . . . . . . . . .
61
Avaliação dos Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
64
5.3.1
Análise de desempenho . . . . . . . . . . . . . . . . . . . . . . . . . .
64
5.3.2
Análise de latência da RTSNoC . . . . . . . . . . . . . . . . . . . . . .
68
5.3.3
Consumo dos Recursos da FPGA . . . . . . . . . . . . . . . . . . . . .
70
Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
70
5.1.3
5.2
5.3
5.4
6 Conclusões
6.1
55
73
Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A Considerações sobre os aceleradores da Arquitetura
74
75
A.1 Fast Fourier Transform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
75
A.2 Filtro FIR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
76
B Geração ondas FM narrowband
79
Referências Bibliográficas
81
xv
Lista de Siglas
ADC Analog-to-Digital Converter
ADRES Architecture for Dynamically Reconfigurable Embedded Systems
AGC Automatic Gain Control
AM Amplitude Modulation
ANSI American National Standards Institute
API Application Programming Interface
ARM Advanced RISC Machine
ASIC Aplication Specific Integrated Circuit
ASIP Application Specifc Instruction Set Processor
BESDR Board for Embedded Software-defined Radio
BRAM Block RAM
CIC Cascaded Integrator-Comb
CLICHE Chip-Level Integration of Communicating Heterogeneous Elements
CORDIC COordinate Rotation DIgital Computer
CRC Cyclic Redundant Check
CRUSH Cognitive Radio Universal Software Hardware
DAC Digital-to-Analog Converter
DCM Digital Clock Manager
DCT Discrete Cosine Transform
DDC Digital Down Converter
xvii
DFE Digital Front-end
DFT Discrete Fourier Transform
DMA Direct Memory Access
DSP Digital Signal Processor
DUC Digital Up Converter
DVB-T Digital Video Broadcasting - Terrestrial
EVP Embedded Vector Processor
FEC Forward Error Correction
FFT Fast Fourier Transform
PHY Ethernet Physical Layer
FIFO First-In First-Out
FIR Finite Impulse Response
FMC FPGA Mezzanine Card
FPGA Field Programmable Gate Array
GbE Gigabit Ethernet
GMII Gigabit Medium Independent Interface
GMRS General Mobile Radio Service
GNU GNU’s Not Unix
GPP General Purpose Processor
GPS Global Positioning System
HDL Hardware Description Language
HERS Heterogeneous Reconfigurable System
HPC High Pin Count
I2C Inter-Integrated Circuit
IEEE Institute of Electrical and Eletronic Engineering
IF Frequência Intermediária
xviii
IOB Input Output Block
IP Intellectual Property
LISHA Laboratório de Integração Software e Hardware
LO Local Oscillator
LTE 3GPP Long Term Evolution
LUT LookUp Table
FM Frequency Modulation
MAC Media Access Control
MDIO Management Data Input/Output
MIMO Multiple-Input and Multiple-Output
MIT Massachusetts Institute of Technology
MPSoC Multiprocessor System on Chip
NCO Numerically Controlled Oslitator
NoC Network on Chip
PCI Peripheral Component Interconnect
PGA Programmable Gain Amplifier
QNoC Quality of Service NoC
RAM Random Access Memory
RF Radio Frequency
RISC Reduced Instruction Set Computing
RPC Remote Procedure Call
ROM Read-only Memory
RSSI Received Signal Strength Indication
RTL Register Transfer Level
RTSNoC Real Time Star Network on Chip
SDR Software-defined Radio
xix
SIMD Single Instruction Multiple Data
SMA SubMiniature version A
SNR Signal-to-Noise Ratio
SPI Serial Peripheral Interface
SPIN Scalable Programmable Integrated Network
SoC System on Chip
SoCIN System on Chip Interconnection Network
SODA Signal-processing On-Demand Architecture
SSB Single-sidedband Modulation
SWIG Simplified Wrapper and Interface Generator
TDM Time Division Multiplexing
UART Universal Asynchronous Receiver Transmitter
UDP User Datagram Protocol
UHD Universal Hardware Driver
USRP Universal Software Radio Peripheral
VHDL VHSIC Hardware Description Languange
VHF Very High Frequency
VHSIC Very High Speed Integrated Circuits
VITA VMEbus International Trade Association
VLIW Very Long Instruction Word
WiMAX Worldwide Interoperability for Microware Access
xx
Lista de Figuras
2.1
Estrutura básica SDR Ideal. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.2
Estrutura básica de um SDR Real. . . . . . . . . . . . . . . . . . . . . . . . .
7
2.3
Arquiteturas de DDC e DUC [22]. . . . . . . . . . . . . . . . . . . . . . . . .
9
2.4
Flowgrpah tı́pico do GNU Radio. . . . . . . . . . . . . . . . . . . . . . . . . .
10
2.5
Diagrama de blocos da estrutura do UHD [23]. . . . . . . . . . . . . . . . . .
12
2.6
Arquitetura básica de um FPGA [44]. . . . . . . . . . . . . . . . . . . . . . .
14
2.7
Elementos de um bloco lógico programável [44]. . . . . . . . . . . . . . . . . .
14
2.8
Arquiteturas interna de um FPGA Xilinx [73]. . . . . . . . . . . . . . . . . .
15
2.9
Estrutura de um pacote de dados em uma NoC [60]. . . . . . . . . . . . . . .
16
2.10 Topologia NoC Hermes [50]. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
2.11 Roteador da NoC Hermes [50]. . . . . . . . . . . . . . . . . . . . . . . . . . .
18
2.12 As duas topologias para SoCIN: mesh e torus . . . . . . . . . . . . . . . . . .
19
2.13 Link SoCIN [74]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
2.14 Roteador da NoC Æthreal [26]. . . . . . . . . . . . . . . . . . . . . . . . . . .
20
2.15 Arquitetura do roteador Quality of Service NoC (QNoC) [8]. . . . . . . . . .
21
2.16 Topologia do roteador RTSNoC. . . . . . . . . . . . . . . . . . . . . . . . . .
21
2.17 Canais de comunicação da RTSNoC. . . . . . . . . . . . . . . . . . . . . . . .
22
2.18 Exemplos de redes RTSNoC. . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
2.19 Formato dos pacotes da RTSNoC. . . . . . . . . . . . . . . . . . . . . . . . .
23
2.20 Estrutura interna do roteador da RTSNoC. . . . . . . . . . . . . . . . . . . .
24
xxi
2.21 Simulação de envio de pacotes na RTSNoC. . . . . . . . . . . . . . . . . . . .
25
2.22 Uso de adaptadores na interconexão de roteadores e núcleos.
. . . . . . . . .
26
2.23 Exemplo de uma máquin de estados para um adaptador RTSNoC. . . . . . .
27
2.24 Fluxo de desenvolvimento utilizando o System Generator. . . . . . . . . . . .
28
3.1
Categorização das soluções em SDR. . . . . . . . . . . . . . . . . . . . . . . .
31
3.2
Arquitetura LeoCore [40]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
3.3
Visão geral da arquitetura SODA [72]. . . . . . . . . . . . . . . . . . . . . . .
33
3.4
Arquitetura Tomahawk MPSoC [38]. . . . . . . . . . . . . . . . . . . . . . . .
34
3.5
Núcleo da arquitetura ADRES [10]. . . . . . . . . . . . . . . . . . . . . . . . .
35
3.6
Arquitetura Butter e Crema [25]. . . . . . . . . . . . . . . . . . . . . . . . . .
36
3.7
Arquitetura de múltiplos canais [17]. . . . . . . . . . . . . . . . . . . . . . . .
37
3.8
Diagrama do sistema CRUSH [21]. . . . . . . . . . . . . . . . . . . . . . . . .
38
4.1
Exploração de arquiteturas de SDR. . . . . . . . . . . . . . . . . . . . . . . .
42
4.2
Visão geral da arquitetura proposta. . . . . . . . . . . . . . . . . . . . . . . .
44
4.3
Diagrama de blocos da interface RF. . . . . . . . . . . . . . . . . . . . . . . .
46
4.4
Representação gráfica do filtro FIR. . . . . . . . . . . . . . . . . . . . . . . .
47
4.5
Estruturas dos pacotes de configuração e dados. . . . . . . . . . . . . . . . . .
49
4.6
Diagrama de blocos da interface GbE
. . . . . . . . . . . . . . . . . . . . . .
51
4.7
Fluxo de projeto de um Software-defined Radio (SDR) para a arquitetura. . .
53
5.1
Digrama de blocos do kit ML605 [28]. . . . . . . . . . . . . . . . . . . . . . .
56
5.2
Exemplo de utilização da BESDR. . . . . . . . . . . . . . . . . . . . . . . . .
57
5.3
Diagrama de blocos da BESDR. . . . . . . . . . . . . . . . . . . . . . . . . . .
58
5.4
Caminhos de Recepção e Transmissão do ADC e DAC. . . . . . . . . . . . . .
59
5.5
Diagrama de Classes simplificado da interface de abstração da arquitetura com
UHD e GNU Radio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
xxii
61
5.6
Ambiente de testes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
62
5.7
Algoritmo de recepção do experimento de teste. . . . . . . . . . . . . . . . . .
63
5.8
Domı́nio da frequência dos 8 canais transmitidos para a realização dos testes.
64
5.9
Ocupação da CPU no cenário de testes . . . . . . . . . . . . . . . . . . . . . .
66
5.10 Ocupação média da CPU no cenário de testes.
. . . . . . . . . . . . . . . . .
67
5.11 Número de FFTs por segundo em função do tamanho da janela. . . . . . . .
68
5.12 Diagrama de forma de onda da utilização da RTSNoC. . . . . . . . . . . . . .
69
A.1 Representação gráfica da FFT. . . . . . . . . . . . . . . . . . . . . . . . . . .
76
A.2 Representação gráfica do filtro FIR. . . . . . . . . . . . . . . . . . . . . . . .
76
B.1 Diagrama de blocos para modulador FM narrowband. . . . . . . . . . . . . .
79
xxiii
Lista de Tabelas
2.1
Tabela de comparação desenvolvimento FPGA [29]. . . . . . . . . . . . . . . .
29
5.1
Lista dos canais GMRS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
62
5.2
Análise de tempo para diferentes tamanhos de janela de FFT. . . . . . . . . .
67
5.3
Consumo de recursos para realização do experimento. . . . . . . . . . . . . .
70
xxv
Capı́tulo 1
Introdução
1.1
Motivação
No decorrer dos últimos anos surgiram uma grande quantidade de padrões e protocolos
de comunicação sem fio, aliados com o aumento de poder de processamento, diminuição dos
custos e miniaturização dos sistemas computacionais. No entanto, nos sistemas tradicionais
de comunicação sem fio muitas funções são implementadas em cadeias de hardware, por
exemplo, modulação/demodulação, codificação/decodificação e filtragem. Essas funções são
normalmente imutáveis, projetadas para operar em uma frequência fixa e de acordo um
padrão especı́fico. Para se comunicar com diferentes terminais sem fio é necessários arranjos
distintos de hardware que suportem os vários protocolos e estruturas de comunicação.
Neste ponto, mostra-se muito atrativa a possibilidade de se reconfigurar o equipamento,
para que este possa oferecer e ter acesso a diversos serviços, sem a necessidade da incorporação
de hardware ao dispositivo. Neste contexto, surge a tecnologia de Rádios definidos por Software (SDR - Software-defined Radio) [46], que utiliza uma abordagem baseada em software
para implementar os diferentes sistemas de comunicação sem fio, sem a necessidade de alterar qualquer elemento de hardware. Essa estratégia de desenvolvimento possibilita que
sistemas de funcionalidade antes definida estaticamente em tempo de projeto sejam trazidos
para um domı́nio reconfigurável, isso torna possı́vel, por exemplo, a atualização de padrões
de modulações ou protocolos.
Outra vantagem proporcionada pelo desenvolvimento dos SDRs é a diminuição dos
custos de produção, pois permitem que toda uma famı́lia de produtos de rádio sejam implementadas em uma plataforma comum de hardware. Além disso, reduz o time-to-market para
o lançamento de novos produtos, tira proveito do baixo custo de desenvolvimento e reuso do
software [34].
2
1. Introdução
Atualmente, exitem várias propostas [2, 17, 38, 40, 72] para implementação de SDRs,
as quais utilizam o conceito de distribuição de processamento por unidades heterogêneas
como Digital Signal Processor (DSP), Field Programmable Gate Arrays (FPGAs) e General
Purpose Processor (GPP). Uma das arquiteturas mais utilizadas e conhecidas é o GNU’s Not
Unix (GNU) Radio [62], um framework aberto que juntamente com a plataforma Universal
Software Radio Peripheral (USRP) [23], possibilita a criação de rádios funcionais a partir de
modelos de alto nı́vel utilizando computadores pessoais.
As tecnologias tradicionais de GPP e DSP, são baseadas em um núcleo de execução
de instruções sequenciais, falham para atender os requisitos de paralelismo e desempenho
para processar elevadas taxas de dados, que são intrı́nsecos de rádios, além de problemas de
eficiência energética. Abordagens que utilizam computação reconfigurável como os FPGAs,
que são circuitos digitais de funcionalidade reconfigurável, permitem a exploração do paralelismo existentes na aplicações, enquanto um GPP ou DSP fica restrito a execução de uma
série de instruções sequencialmente, em hardware é possı́vel sintetizar diversas partes de uma
mesma função em paralelo ganhando em desempenho.
Sistemas em chip (SoC - System on Chip) consistem de um conjunto de dispositivos
(analógicos ou digitais) com função especı́fica reunidos em um mesmo componente de hardware, com o objetivo de se obter um sistema integrado. O método mais comum para interconexão dos componentes em um SoC é o barramento compartilhado, que é um conjunto de
conexões comum a um conjunto de dispositivos. Um problema apresentado por esse tipo de
interconexão é a possibilidade de realização de uma única transação de comunicação em um
dado instante de tempo, o que é um problema para sistemas de processamento paralelo.
Como alternativa para as interconexões em SoCs, foram propostas as redes em chip
(NoC - Network on Chip). Baseadas em conceitos de computação distribuı́da e redes de
computadores, as NoCs apresentam maior escalabilidade e confiabilidade [14]. Nesse tipo de
interconexão, cada componente é conectado a um roteador. Todos os roteadores do sistemas
são interconectados e são responsáveis por transferir e receber dados dos componentes.
Esta dissertação apresenta a concepção de uma arquitetura reconfigurável e heterogênea
para SDRs, que utiliza computação reconfigurável para a criação de aceleradores em hardware dos principais algoritmos DSPs utilizados em SDRs e uma NoC como infraestrutura de
comunicação entre os blocos. A arquitetura proposta permite o deslocamento de algoritmos
comumente utilizadas nas camadas fı́sicas de um rádio integralmente para hardware na forma
de aceleradores.
Para avaliar a arquitetura proposta foi desenvolvido um protótipo utilizando a Board
for Embedded Software-defined Radio (BESDR) e a FPGA Xilinx Virtex-6. Além disso,
realizou-se um cenário de testes, que demonstrou uma melhoria significativa no desempenho
global do sistema.
1.2. Objetivos
1.2
3
Objetivos
O principal objetivo deste trabalho é propor uma arquitetura para rádios definidos por
software, que permita a migração dos algoritmos de processamento de sinais digitais para o
hardware na forma de aceleradores sem perder a flexibilidade intrı́nseca dos SDRs.
A partir deste objetivo principal, são definidos os seguintes objetivos especı́ficos:
• Analisar algoritmos comuns às camadas fı́sicas de rádios.
• Definir uma infraestrutura de comunicação eficiente para os blocos de processamento
heterogêneos, sem a perda de flexibilidade dos blocos de software, garantindo o aproveitamento dos recursos do hardware.
• Propor uma arquitetura para configuração e controle dos blocos em hardware.
• Definir um fluxo de projeto para de SDRs utilizando a arquitetura proposta.
• Testar e analisar a arquitetura proposta levando em consideração alguns parâmetros
como desempenho e ocupação da FPGA.
1.3
Visão Geral do Texto
O próximo capı́tulo apresenta as tecnologias relacionadas com o desenvolvimento deste
trabalho, onde inicialmente é apresentado a fundamentação teórica da tecnologia SDR, as
estruturas internas do GNU Radio e os conceitos e arquiteturas de Network on Chips (NoCs).
O Capı́tulo 3 é referente ao estado da arte das pesquisas em SDR, apresentado os
principais trabalhos relacionados.
O Capı́tulo 4 apresenta as principais caracterı́sticas e fundamentos da arquitetura proposta nesta dissertação.
O Capı́tulo 5 apresenta a implementação de um cenário de testes para validação da
arquitetura proposta e uma avaliação de desempenho comparativa com outras arquiteturas.
Finalmente são apresentadas no Capı́tulo 6 as conclusões e propostas de trabalhos
futuros.
4
1. Introdução
Capı́tulo 2
Tecnologias Relacionadas
Neste capı́tulo é feita uma revisão dos principais conceitos e tecnologias relacionados
a este trabalho. Primeiramente é apresentado detalhes sobre Rádios definidos por Software,
computação reconfigurável, redes-em-chip e suas principais topologias. Por fim, um fluxo
para desenvolvimento de projetos em FPGA baseado em modelos.
2.1
Rádios definidos por Software
Rádio definido por software (Software-defined Radio (SDR)) [45] é uma tecnologia que
tem sido pesquisada nas últimas décadas e que está se tornando uma alternativa aos tradicionais transmissores e receptores de radiocomunicação. Tem como objetivo flexibilizar a
implementação dos rádios, ao invés de ter sua funcionalidade definida por meio de componentes de hardware decidido em tempo de projeto, é possı́vel a reconfiguração por meio de
módulos de software. O termo SDR foi introduzido por John Mitola III, sua definição é dada
como:
“A software radio is a radio whose channel modulation waveforms are defined
in software. That is, waveforms are generated as sampled digital signals, converted from digital to analog via a wideband DAC and then possibly upconverted
from IF to RF. The receiver, similarly, employs a wideband Analog to Digital
Converter (ADC) that captures all of the channels of the software radio node.
The receiver then extracts, downconverts and demodulates the channel waveform
using software on a general purpose processor [48].”
Em uma maneira mais simplificada, um rádio definido por software é um transceptor
de rádio que tem seu princı́pio de funcionamento sendo executado através de um software,
6
2. Tecnologias Relacionadas
podendo ter seu funcionamento alterado com uma simples atualização deste mesmo software,
sem a necessidade de alteração nenhuma de hardware. O objetivo principal dessa tecnologia é
conceber um rádio que virtualmente possa se comunicar com qualquer nova tecnologia de rede
sem fio apenas atualizando o software, ou seja, a ideia é colocar o software mais próximo da
antena e utilizá-lo para filtrar, modular, demodular e executar outros estágios da transmissão
e recepção.
Pode-se destacar as seguintes vantagens na utilização de um SDR [64]:
• Multifuncionalidade: atualmente existem diversos padrões de comunicação sem fio. Um
rádio reconfigurável pode adaptar-se aos diversos padrões, enquanto um rádio tradicional precisa implementar todos os padrões simultaneamente.
• Flexibilidade: ao contrário dos rádios tradicionais, existe a possibilidade de realizar
correções de falhas e atualizações de funcionalidades.
• Facilidade de produção: com as funcionalidades desenvolvidas por software, não há
necessidade de uma grande quantidade de componentes discretos, com um processador
de alto desempenho é possı́vel executar diversos estágios da cadeia de processamento
do rádio.
O conceito de SDR não deve ser confundido com rádios baseados ou controlados por
software, pois hoje, praticamente todos os rádios se utilizam de software em sua concepção.
Estes rádios baseados ou controlados por software necessitam de ajustes no hardware para
qualquer mudança em interfaces baseadas em software [71]. Ou seja, com o software podem
ser controlados parâmetros do rádio como frequência de operação, modo de operação (Amplitude Modulation (AM), Frequency Modulation (FM), Single-sidedband Modulation (SSB)),
controle de ganho, etc. O software é só uma interface para ajustes no próprio hardware.
2.1.1
Arquitetura
Ao propor os rádios definidos por software em 1992, John Mitola III comenta sobre o
SDR Ideal (figura 2.1) [47]. Nesse rádio, o sinal seria digitalizado imediatamente após ser
recebido pela antena e imediatamente antes de ser transmitido por ela, e todas as etapas de
processamento Radio Frequency (RF) e de sinais seriam executadas diretamente em software.
ç Algumas limitações impedem que o modelo ideal de SDR seja implementado, os requisitos necessários de Analog-to-Digital Converter s (ADCs) e Digital-to-Analog Converter s
(DACs) ficam muitos além dos limites práticos existentes no que se refere a taxa de amostragem,
largura de banda e faixa dinâmica. Segundo o teorema de Nyquist, um sinal analógico que
foi amostrado só pode ser reconstruı́do sem perdas a partir das suas amostras se a sua taxa
2.1. Rádios definidos por Software
7
Figura 2.1: Estrutura básica SDR Ideal.
de amostragem for pelo menos duas vezes maior que a maior frequência do sinal original [36],
ou seja:
fs ≥ 2B,
(2.1)
onde fs é a frequência de amostragem e B é a maior frequência do sinal. Por exemplo, para
amostrar um sinal na faixa de 2,4 Ghz, seria necessário uma frequência de amostragem de
4,8 GHz. Contudo, existem limitações quanto à capacidade de amostragem e os custos dos
ADCs de alta taxa. Além disso, a grande capacidade computacional necessária para processar
diretamente o sinal torna essa alternativa inviável.
Para solução desses problemas são feitas algumas alterações do sinal via hardware,
enquanto diferentes processadores, tais como FPGAs, DSPs e processadores de propósito
geral ficam encarregados do processamento do software, para implementação de um modelo
real de SDR.
A solução então é filtrar a janela de frequência desejada e convertê-la para uma Frequência
Intermediária (IF), para então ser amostrada pelo ADC. A figura 2.2 apresenta os blocos
da estrutura básica de um SDR real.
Figura 2.2: Estrutura básica de um SDR Real.
2.1.1.1
RF Front-end
Nos SDRs reais são adicionadas interfaces analógicas entre a antena, ADC e DAC,
chamada de RF front-end. Este bloco é responsável por captar e preparar os sinais para
conversão analógico/digital e preparar os sinais para transmissão após a conversão digi-
8
2. Tecnologias Relacionadas
tal/analógico. A preparação dos sinais é feita através da amplificação dos sinais, controle
de ganho, filtragem anti-aliasing
1
e deslocamento para uma IF (no caso de recepção) ou
para frequência original do sinal (no caso de transmissão).
O deslocamento do sinal para uma recepção é realizado seguindo a proposta de Edwin
Armstrong descrita em [31]:
VIF = VRF − VLO ,
(2.2)
VIF = VRF + VLO ,
(2.3)
deslocamento para transmissão:
onde é VIF é a frequência intermediária, VRF é a radio frequência e o VLO é o Local Oscillator
(LO). Por exemplo, para digitalizar um sinal que está na faixa de 87,5-108 M Hz, o front-end
seleciona uma janela de 6 M Hz e desloca para a IF 0-6 M Hz. Dessa forma, o sinal pode ser
amostrado por ADCs com um custo menor. As topologias mais utilizadas para transladação
dos sinais são: conversores super heteródino, direto e múltiplo.
2.1.1.2
Digital Down Converter e Digital Up Converter
Os SDRs reais ainda possuem um estágio antes da conexão com o processador. Normalmente apenas uma faixa do sinal amostrado pelo ADCs é necessária, por isso esses sistemas
incluem um Digital Down Converter (DDC) e um Digital Up Converter (DUC) que em
comparação pode ser chamado de um Digital Front-end (DFE).
O DDC é responsável por converter a frequência intermediária para uma frequência em
banda base. Seu funcionamento consiste em mixar a IF em quadratura com duas sinusoides,
geradas por um oscilador local, decompondo assim o sinal em componentes complexas. Para
selecionar a faixa de frequência de interesse, o sinal passa por um filtro passa-baixas decimador, reduzindo assim a taxa de dados enviados ao processador [66]. A figura 2.3a apresenta
a arquitetura de um DDC.
O DUC tem a função contrária do DDC, ele transporta o sinal em banda base, para
frequência intermediária novamente. O sinal complexo é interpolado, para obter um número
maior de amostras, depois é mixado com duas sinusoides em quadratura convertendo o sinal
de complexo para real. O RF front-end finalmente transmite o sinal na sua frequência original.
A figura 2.3b apresenta a arquitetura de um DUC.
As sinusoides comentadas nos parágrafos são geradas pelo Numerically Controlled Oslitator (NCO) que, basicamente, tem como entrada um clock e um incremento de fase, a cada
1
Um filtro anti-aliasing consiste em um filtro passa-baixas com frequência de corte igual ou menor que
a metade da frequência de amostragem, com o intuito de retirar componentes de frequências indesejadas
sobreponham o espectro do sinal amostrado.
2.1. Rádios definidos por Software
9
(a) Arquitetura de um DDC
(b) Arquitetura de um DUC.
Figura 2.3: Arquiteturas de DDC e DUC [22].
ciclo do clock ele incrementa o seu acumulador de fase e apresenta na saı́da o seno e o cosseno
da fase armazenada no acumulador [65].
O NCO pode ser implementado em várias arquiteturas, como uma tabela de look-up em
uma memória Read-only Memory (ROM) ou utilizando um algoritmo COordinate Rotation
DIgital Computer (CORDIC) [41]. O CORDIC é um algoritmo numérico que calcula funções
trigonométricas através de rotações fasoriais iterativas, calculando coordenadas cartesianas
de um vetor que roda sobre um ângulo arbitrado, e é de excelente desempenho e uma saı́da
para sistemas que não possuem memória interna [3].
2.1.2
GNU Radio
O GNU Radio [62] é um framework de software livre, derivado do projeto SpectrumWare
[69] do Massachusetts Institute of Technology (MIT), para desenvolvimento de SDRs em
computadores pessoais combinados com um hardware para conversão analógica/digital e RF
front-end. O GNU Radio suporta o uso de vários dispositivos como RF front-end, entre eles
USRP [23]. Segundo Eric Blosson, um dos fundadores do projeto, o GNU Radio tem como
objetivo
10
2. Tecnologias Relacionadas
“trazer o código mais próximo possı́vel da antena, transformando assim problemas
de hardware em problemas de software [22].”
O GNU Radio disponibiliza uma biblioteca que possui blocos para processamento digital
de sinal, conta com funções básicas até algoritmos completos de filtros, (de)moduladores,
(de)codificadores, etc. A biblioteca permite conectar os blocos para formar um SDR. Os
blocos do GNU Radio permitem realizar uma abstração da camada fı́sica de um rádio em um
grafo acı́clico, onde os nodos representam os blocos de processamento e as arestas o fluxo dos
dados entre os nodos. A figura 2.4 apresenta um exemplo de um flowgraph de uma cadeia
de recepção, onde, os dados saem do nodo inicial, o Audio Source, e vão fluindo através dos
blocos de processamento, sofrendo transformações até chegar no nodo final.
Figura 2.4: Flowgrpah tı́pico do GNU Radio.
Conceitualmente, um bloco de processamento processa um fluxo infinito de dados,
fluindo das suas portas de entrada para as suas portas de saı́da. A única restrição existente
para o fluxo de dados é que eles não podem conter laços (loops), significa que a parte que
contém loop deve ser construı́da completamente dentro de um bloco [52]. As portas dos
blocos de entrada e saı́da servem como fontes e sumidouros de dados no grafo. Por exemplo,
há fontes que lêem dados de um arquivo ou de um ADC, e sumidouros que escrevem em um
arquivo, DAC ou em um display gráfico.
A estrutura interna do GNU Radio é formada basicamente por quatro componentes
[18] [43]:
Blocos de processamento: são os componentes que efetivamente atuam sobre o stream e
podem ser dividos em três classes: Normal, Fonte e Sumidouros. A grande maioria
dos blocos é do tipo Normal, os quais possuem entradas, saı́das e são responsáveis pelo
processamento do sinal nas fase intermediárias do flowgraph. Os blocos Fontes possuem
somente saı́da e iniciam o flowgraph. Os blocos Sumidouros possuem somente entrada
e consomem a stream processada.
Controlador de flowgraph: é responsável pela abstração do fluxo de dados, ou seja, a
sequência de como o sinal é processado pelos blocos e as conexões entre eles sendo
utilizado para construção do flowgraph.
Buffer de Dados: é responsável pela alocação dos buffers entre os blocos. A função define o
tamanho dos buffers considerando a taxa relativa de consumo e produção e os tamanhos
dos dados de entrada e saı́da. Cada buffer é implementado como uma FIFO o que
possibilita múltiplas portas de leitura e uma única porta de escrita.
2.1. Rádios definidos por Software
11
Escalonador: é responsável por movimentar os dados pelo flowgraph, passando repetidas
vezes por cada bloco, ele verifica se há dados suficientes na entrada e espaço suficiente
na saı́da. Se esses requisitos forem satisfeitos o método work do bloco é chamado.
A implementação do GNU Radio é feita em linguagem C++ e Python, e utiliza o
Simplified Wrapper and Interface Generator (SWIG) para criar interfaces entre ambas. A
linguagem C++ é utilizada para programação onde é necessário desempenho, como nos blocos
de processamento de sinais. Já a linguagem Python é utilizada para conexão dos blocos de
processamento de sinais. Essa abordagem oferece uma interface de alto nı́vel ao desenvolvedor
e um bom desempenho através da execução nativa dos blocos de processamento.
As principais vantagens do GNU Radio estão na utilização de plataforma de uso geral
o que facilita a instalação e desenvolvimento, na quantidade de blocos de processamento
de sinal disponı́veis e na grande comunidade de software livre que suporta o framework.
As desvantagens surgem a partir das próprias caracterı́sticas básicas. Devido as aplicações
serem executadas em computador pessoal com um sistema operacional de propósito geral
e se comunicando com RF front-ends através de barramentos compartilhados [51]. O uso
desse tipo de sistema insere um atraso não-determinı́stico na cadeia de processamento, o que
impossibilita a implementação eficiente das camadas mais altas dos protocolos que possuem
requisitos de tempo precisos [56].
2.1.2.1
Universal Hardware Driver
O Universal Hardware Driver (UHD) é um componente mais recente [23], o qual provê
uma Application Programming Interface (API) e device drivers para plataformas de aquisição
de dados para SDRs, desenvolvidas pela empresa Ettus Research, que normalmente são utilizados com o GNU Radio. O UHD foi criado com o intuito de criar uma interface padrão para
as diferentes plataformas existentes. Com uma API bem definida permite a portabilidade
para diversas plataformas, atualmente suporta os sistemas operacionais Linux, Windows e
MAC OSX, além de permitir portabilidade para diversas aplicações. A figura 2.5 apresenta
um diagrama em blocos da estrutura interna e funcionamento do UHD.
A API do UHD tem definido um canal de comunicação um para o envio e recebimento
de dados e outro para mensagens de controle. Por meio dos canais de controle e comunicação
é possı́vel:
• Encontrar dispositivos.
• Configurar propriedades dos dispositivos como: ganho, frequência central, taxa de
transmissão, seleção de antena e front-end.
12
2. Tecnologias Relacionadas
Figura 2.5: Diagrama de blocos da estrutura do UHD [23].
• Detectar erros no stream como: overflow, underflow, erros de sequência.
• Sincronização de streams com timestamps para sistemas Multiple-Input and MultipleOutput (MIMO).
O UHD tem suporte ao padrão VMEbus International Trade Association (VITA)-49
que define a transferência de dados de uma IF digital entre os equipamentos de aquisição e
de processamento do sinal. O padrão tem o intuito de proporcionar interoperabilidade entre
os diversos fabricantes. O padrão define um pacote para o stream foi projetado para diminuir
o overhead das mensagens, suporta multi-canais e sincronização [61].
2.2
Computação Reconfigurável
Atualmente, observa-se um grande número de aplicações que necessitam de recursos
computacionais especı́ficos. Os processadores de uso geral ou DSPs não conseguem resolver
eficientemente esses problemas devido as generalidades de suas estruturas internas. Já as
soluções implementadas totalmente em hardware (ASIC) apresentam problemas em relação
a flexibilidade, reusabilidade e time-to-market.
Nesse contexto, a computação reconfigurável surge como um paradigma de computação
que combina o hardware com a flexibilidade do software utilizando hardwares reconfiguráveis
[70]. Possibilita uma maior flexibilidade e desempenho em relação aos paradigmas de hardware e software, como também uma efetiva melhora de eficiência, custo, generalidade e
2.2. Computação Reconfigurável
13
tolerância a falhas [13]. A utilização de computação reconfigurável é vantajosa para sistemas
de alto desempenho, pois, permite explorar múltiplos nı́veis de paralelismo [67].
As arquiteturas reconfiguráveis são formadas por blocos (módulos) lógicos que reproduzem unidades funcionais de processamento, armazenamento, comunicação. As arquiteturas
reconfiguráveis não necessariamente precisam ser todas as partes reconfiguráveis, por isso, podem ser hı́bridas. Entre as principais caracterı́sticas das arquiteturas reconfiguráveis, podem
ser destacadas:
Granularidade: essa caracterı́stica está relacionada aos elementos de processamento, podese definir arquiteturas reconfiguráveis em granularidade fina e grossa. Por granularidade
fina, entende-se que a unidade reconfigurável mı́nima seja composta por elementos
bastante simples, por exemplo a nı́vel de bit. Enquanto, a granularidade grossa é
aquela se se da em menor escala e o sistema é composto de grandes blocos dispostos
em uma organização previamente definida.
Reconfiguração: essa caracterı́stica está relacionada à capacidade de realizar uma ou várias
configurações. O tipo da reconfiguração estática ou dinâmica, parcial ou total, local
ou remota. A configuração estática está relacionada com a configuração do dispositivo
antes desse começar a fazer a computação dos dados, caso seja necessário reconfigurar,
para que se tenha outra funcionalidade, o dispositivo para de executar as operações e é
reconfigurado. Já a reconfiguração dinâmica o dispositivo realiza uma reconfiguração de
uma área, onde não esta sendo processado dados, paralelamente à execução de operações
de computação [30].
Interconexão: essa caracterı́stica está relacionada a forma de conexão entre os diversos
elementos de processamento. Podendo ser classificadas como conexões dedicadas e barramentos compartilhados. As conexões dedicadas são um conjunto de ligações diretas
entre componentes que irão se comunicar. Os barramentos compartilhados são quando
um conjunto de núcleos compartilha um mesmo conjunto de conexões e normalmente
são controlados por uma lógica de arbitragem.
No contexto de SDRs as arquiteturas reconfiguráveis representam um papel importante
e são largamente utilizadas principalmente na realização do RF front-end digital. Nessa
etapa há uma alta vazão de dados e são realizadas as funções de DDC e DUC e outras com
caracterı́sticas paralelas como separação de canais [20] [43].
2.2.1
Dispositivos Reconfiguráveis
Um Field Programmable Gate Array (FPGA) é um dispositivo programável que possui
blocos e conexões que podem ser programadas. Esse dispositivo permite a implementação
14
2. Tecnologias Relacionadas
de circuitos lógicos que consistem de um arranjo dos blocos e interconexões, contidos num
circuito integrado. Sua configuração pode ser alterada sem que tenham que ser retirados do
circuito eletrônico, a capacidade atual dos FPGAs está na faixa de milhões de portas lógicas
[30].
Um FPGA tı́pico é composto por três componentes básicos: blocos lógicos, chaves de
interconexão e blocos de entrada e saı́da. A estrutura genérica da estrutura é apresentada na
figura 2.6.
Figura 2.6: Arquitetura básica de um FPGA [44].
Os blocos lógicos são implementados através de uma estrutura chamada de LookUp
Table (LUT), que representam uma a tabela-verdade de uma determinada função lógica, um
multiplexador e um flip-flop. A figura 2.7 mostra um exemplo de um bloco lógico. A tabelaverdade é implementada através de uma memória interna e um multiplexador que traduz as
entradas para o elemento correspondente desta memória interna.
Figura 2.7: Elementos de um bloco lógico programável [44].
2.2. Computação Reconfigurável
15
Os FPGAs comerciais possuem outros blocos na sua composição não somente LUTs,
que implementam funções puramente combinacionais. Esses FPGAs possuem uma matriz
de blocos lógicos configuráveis, cercados por uma rede de interconexão programável, formada por blocos de interconexão. Circundando todo o circuito, existem os Input Output
Block s (IOBs), que também são programáveis e que servem como interface com o mundo
exterior [70]. Atualmente, também existem nos FPGAs uma área de memória interna Block
RAM (BRAM) e blocos para gerenciamento de clock. Os Digital Clock Manager s (DCMs)
fornecem opções para tratamento de sinais de clock, como multiplicação, divisão, calibração
e o deslocamento de fase. Além disso é comum encontrar blocos que exercem funções especı́ficas de processamento de DSP, tais como somadores e acumuladores, pois os FPGAs são
amplamente utilizados neste domı́nio de aplicação. A figura 2.8 apresenta a estrutura de um
FPGA comercial do fabricante Xilinx.
Figura 2.8: Arquiteturas interna de um FPGA Xilinx [73].
A configuração do comportamento do FPGA, pode ser feita através de uma Hardware
Description Language (HDL). Depois que o circuito foi projetado em HDL ele é sintetizado
independente de plataforma gerando o netlist. O próximo passo, no fluxo de geração da
configuração do FPGA, é o mapeamento das estruturas em um dispositivo, este processo é
denominado place-and-route. O place-and-route é uma parte importante desta cadeia, pois
esta diretamente ligado com o desempenho e a melhor utilização da área do dispositivo . Ao
final é gerado um arquivo binário que configura o FPGA (bitstream) [13].
Atualmente, as linguagens de descrição de hardware mais utilizadas são o Verilog e
VHSIC Hardware Description Languange (VHDL). Essas linguagens são de grande utilidade,
pois permitem definir o comportamento do hardware em alto nı́vel. VHDL é um acrônimo
de Very High Speed Integrated Circuits (VHSIC) + HDL surgiu na de década de 1980 e em
1987 foi aprovada como padrão da Institute of Electrical and Eletronic Engineering (IEEE)
[5].
16
2. Tecnologias Relacionadas
2.3
Network on Chip
Em barramentos compartilhados, um conjunto de núcleos compartilha uma mesma in-
terconexão. Há uma perda de desempenho devido ao fato que somente um núcleo por vez pode
acessar o barramento, pode-se utilizar outras topologias de barramento como hierárquicos, em
anel ou crossbars [60]. Em um ambiente com diversos núcleos em barramento compartilhado,
uma série de problemas surge, como [7]:
• dificuldades para dissipação de energia.
• efeitos na integridade do sinal causados pelo aumento do ruı́do, interferência eletromagnética.
• atraso não-determinı́stico na propagação sinais.
Para solucionar os problemas dos barramentos compartilhados foi proposto as Network
on Chip (NoC) [6]. Em uma NoC, os núcleos são conectados a um comutador (switch) e
realizam a comunicação por meio de troca de mensagens. Os comutadores estão conectados
em uma malha (mesh) bidimensional o que permite a comunicação entre os núcleos.
São utilizados dois termos para definir os campos dos pacotes em uma NoC. O termo
flit é utilizado para identificar os bits onde serão executadas as ações de controle de fluxo nos
enlaces. O corpo de um flit em blocos denominados phit, como apresentado na figura 2.9.
O tamanho de um phit em bits corresponde à largura do enlace de comunicação entre dois
comutadores [60].
Figura 2.9: Estrutura de um pacote de dados em uma NoC [60].
A disposição dos núcleos pode determinar o grau de escalabilidade e o desempenho de
um sistema utilizando NoC. A seguir é apresentado as topologias utilizadas encontradas na
literatura para construção de NoC:
2.3. Network on Chip
17
CLICHE: é uma topologia simples, Chip-Level Integration of Communicating Heterogeneous
Elements (CLICHE) [35] é uma rede em mesh bidimensional, cada roteador é conectado
a um núcleo. A facilidade de roteamento da topologia ajuda diminuir o tamanho do
roteador, aumenta a capacidade dos canais fı́sicos e melhora a escalabilidade.
Torus: uma topologia similar à mesh, exceto pelo fato de possuir interconexão que ligam
os componentes das extremidades superior com a inferior, e os das direita com os da
esquerda [14].
Butterfly Fat Tree: nessa topologia os núcleos estão dispostos em forma de uma árvore,
cada nó é representado por um conjunto de coordenadas nı́vel e posição. Cada roteador
é conectado a outros dois roteadores do nı́vel acima e a quatro “filhos” no nı́vel abaixo,
que podem ser outros roteadores ou núcleos e são chamadas de “folhas” [58]
SPIN: esta topologia Scalable Programmable Integrated Network (SPIN) [27] é semelhante
com a Butterfly Fat Tree. Para uma árvore com “N” núcleos, existem um total de
3N/4 roteadores na árvore, todos os nı́veis de roteadores possuem o mesmo número
de roteadores. O tamanho da rede cresce na proporção de (N logN )/8. A abordagem
desta topologia é a preservação data taxa de transmissão no dois sentidos
Octogonal: esta topologia nenhum componente necessita mais do que dois saltos para se
comunicar com outro componente. O modelo básico desta topologia é em anel com
oito componentes. Essa topologia possui vantagens na implementação do algoritmo de
roteamento e alta taxa de comunicação [33].
Como vantagens do uso de uma NoC pode-se destacar o reuso, a alta escalabilidade,
melhor controle dos parâmetros elétricos, devido a estrutura das interconexões. Como desvantagens o consumo de energia nos comutadores, latência de comunicação e o sobre custo de
área em silı́cio para geração dos comutadores.
No restante seção são apresentadas algumas implementações de NoC existentes e as
abordagens que cada implementação enfoca.
As implementações apresentadas abordam
questões particulares de NoC, tais como, topologia, modularidade, reusabilidade entre outros.
2.3.1
Arquitetura HERMES
HERMES é uma infraestrutura para NoC que faz o uso de roteadores bastante simples
para proporcionar um menor sobrecusto de área. O mecanismo de comunicação é o de
comutação de pacotes e a topologia do tipo mesh [50]. A topologia da HERMES é mostrada
na figura 2.10
O roteador HERMES possui uma unidade lógica de roteamento e cinco portas bidirecionais: Norte, Sul, Leste e Oeste, para conexões com outros roteadores, uma Local para
18
2. Tecnologias Relacionadas
Figura 2.10: Topologia NoC Hermes [50].
estabelecer comunicação com o núcleo. Cada porta possui um buffer para armazenar dados temporariamente, caso o destino esteja ocupado ou eventuais problemas de conexão. A
unidade lógica implementa o roteamento, lógica de arbitragem e o algoritmo de comutação
de pacotes. A figura 2.11 apresenta o roteador da NoC HERMES.
Figura 2.11: Roteador da NoC Hermes [50].
2.3.2
SoCIN
A NoC System on Chip Interconnection Network (SoCIN) [74] foi desenvolvida pela
Universidade Federal do Rio Grande do Sul. Pode ser construı́da utilizando topologias 2D
tanto em mesh quanto torus, como apresentado na figura 2.12.
As interconexões desta NoC possuem dois canais unidirecionais, cada um com seus
dados, controles de fluxo e empacotamento. As mensagens transmitidas possuem dois bits
que indicam o inicio (bop: begin-of-packet) e o final do pacote (eop: end-of-packet). Os bits
2.3. Network on Chip
19
Figura 2.12: As duas topologias para SoCIN: mesh e torus
de controle são usados para validar os dados do canal (val ) e para dar conhecimentos dos
dados recebidos (ack ). A figura 2.13 apresenta a estrutura do link do SoCIN.
Figura 2.13: Link SoCIN [74].
2.3.3
Æthereal
A NoC Æthereal [26], foi desenvolvida baseada em serviços diferenciados que garantem
uma comunicação, com o intuito de facilitar integração e eliminar incertezas da interconexão.
Os serviços diferenciados são implementados através de configurações individuais nas métricas
de comunicação entre os núcleos, como vazão de dados e latência.
A Æthereal possui dois componentes roteadores e interfaces de rede. O canal implementa uma comunicação ponto-a-ponto entre duas interfaces de rede, com a possibilidade
de vários caminhos para a conexão dos núcleos. O canal pode ter garantia de latência ou
de “melhor esforço” na comunicação, para garantir a latência usa uma implementação Time
Division Multiplexing (TDM) para comutação do circuito. A figura 2.14 apresenta o roteador
Æthereal trabalhando nas duas abordagens garantia de latência e “melhor esforço”.
A ordem da entrega das mensagens não é garantida quando utilizado vários canais,
Æthreal tem a possibilidade de controlar nas conexões múltiplos canais, controle de fluxo e
um reordenação das mensagens.
20
2. Tecnologias Relacionadas
Figura 2.14: Roteador da NoC Æthreal [26].
2.3.4
QNoC
A rede QNoC foi proposta em [8] e possui uma topologia de malha irregular o mecanismo
de comunicação é o de comutação de pacotes, possui controle de fluxo baseado em créditos.
A QNoC oferece classes de serviço com diferentes nı́veis de prioridade como: (a) Signalling,
nı́vel de serviço com maior prioridade na rede; (b) Real time, nı́vel de serviço que garante
largura de banda e latência para as aplicações; (c) Read/Write, nı́vel de serviço projetado
para suportar acessos curtos a memórias e registradores; (d) Block Transfer, nı́vel de serviço
usado para transferência de mensagens e blocos de dados grandes.
A figura 2.15 ilustra a arquitetura do roteador da QNoC, suporta até cinco conexões:
quatro para roteadores vizinhos e uma para o núcleo local. O roteador transfere os pacotes
das portas de entrada para as de saı́da, os dados são recebidos em flits e armazenados em
buffers de entrada. Na medida que o roteador envia os dados uma posição do buffer fica
disponı́vel e um crédito é enviado ao outro roteador. O gerenciamento das prioridades utiliza
o algoritmo round-robin e os nı́veis de serviço são indicados por um canal de controle.
2.3.5
RTSNoC
A Real Time Star Network on Chip (RTSNoC) foi desenvolvida no intuito de criar uma
estrutura de intercomunicação com previsibilidade de latência, sendo assim apropriada para
a interconexão de núcleos de tempo real que necessitem deste tipo de garantia. O principal
elemento que compõem esta rede é o seu roteador.
O roteador da rede RTSNoC possui oito pontos de interconexão, conforme ilustra a
figura 2.16. Os oito pontos recebem os nomes de pontos cardeais de uma bússola: NN para
2.3. Network on Chip
21
Figura 2.15: Arquitetura do roteador QNoC [8].
a porta Norte, NE para Nordeste, EE para Leste, SE para Sudoeste, SS para Sul, SW para
Sudoeste, WW para Oeste e finalmente NW para Noroeste.
Figura 2.16: Topologia do roteador RTSNoC.
Em cada ponto de interconexão do roteador da rede RTSNoC estão disponı́veis os
enlaces da rede, que constituem os canais de comunicação da rede. Os enlaces da rede RTSNoC são implementados por dois canais unidirecionais em oposição, conforme figura 2.17. O
tamanho de cada canal pode ser configurado pelo usuário de acordo com as necessidades da
aplicação. Os barramentos de sinais denominados de DIN e DOUT referem-se aos barramentos de dados de entrada e saı́da de dados, respectivamente. Os sinais RD e WR são strobes
utilizados para escrever ou ler dados no roteador, respectivamente. Por fim, os sinais WAIT
e ND constituem os sinais utilizados para controle de fluxo na rede. O sinal WAIT indica ao
22
2. Tecnologias Relacionadas
PE que deve aguardar para poder escrever novo dado no canal de entrada do roteador. Já o
sinal ND indica ao canal de destino do pacote que um novo pacote está disponı́vel para ser
encaminhado.
Figura 2.17: Canais de comunicação da RTSNoC.
Com um roteador e oito núcleos é constituı́da uma subrede RTSNoC. A interconexão de
mais roteadores, além dos núcleos, permite que sejam estabelecidas redes em malha regular
2-D ou irregular 2-D, conforme apresentado nas figuras 2.18a e 2.18b.
(a) Malha regular com
quatro roteadores
(b) Malha irregular com
três roteadores.
Figura 2.18: Exemplos de redes RTSNoC.
2.3.5.1
Formato dos pacotes na RTSNoC
O roteador da Rede RTSNoC é parametrizável em tempo de projeto. Os parâmetros
ajustáveis são o tamanho do campo de dados e as coordenadas cartesianas dos roteadores
envolvidos em uma determinada comunicação. A figura 2.19 apresenta o formato deste pacote.
Como a rede RTSNoC trabalha em malha regular ou irregular 2-D, são utilizados dois
campos, denominados de XORI e YORI, que correspondem às coordenadas X e Y do roteador
na malha de onde está sendo gerado um pacote, ou seja, o seu endereço de origem. O mesmo
2.3. Network on Chip
23
Figura 2.19: Formato dos pacotes da RTSNoC.
acontece para o endereço do roteador de destino do pacote, que possui os campos XDST e
YDST para informar as coordenadas de destino na comunicação. O campo HORI refere-se
ao endereço da porta dentro do roteador de origem de onde está sendo enviado o pacote para
a rede. De modo similar, HDST é a informação do núcleo de destino do pacote a ser roteado.
O campo DATA apresentado na figura 2.19 é a carga útil que deve ser entregue aos
núcleos da rede. A limitação de um phit por pacote está contida na camada de rede da NoC.
Pacotes com número ilimitado de dados podem ser constituı́dos logicamente entre os núcleos,
de modo transparente para a NoC.
2.3.5.2
Estrutura interna do Roteador
O roteador proposto possui oito canais bi-direcionais, os quais podem ser conectados
a núcleos ou aos canais de outros roteadores. O algoritmo de roteamento adotado é do tipo
XY e por este motivo os canais Norte, Sul, Leste e Oeste são priorizados para conexão com
os canais de outros roteadores, quando necessário, para formar uma rede em malha 2-D. A
figura 2.20 ilustra a estrutura interna do roteador da RTSNoC.
Cada canal de entrada é composto por uma interface de entrada, uma interface de saı́da
e um controlador de fluxo. A interface de entrada possui um registrador capaz de armazenar
um phit. Quando um núcleo deseja enviar pacotes pela rede ele deve escrever o pacote neste
registrador. Em seguida, o controlador de fluxo irá identificar no cabeçalho do pacote qual
o destino da mensagem e verificará se o destino está livre para ser utilizado. Paralelo a
isto, o controlador de fluxo informa ao bloco árbitro da existência de uma nova requisição de
roteamento.
O bloco árbitro implementa um algoritmo tipo Round Robin. Ao inicializar, todos os
canais recebem um nı́vel de prioridade, diferente dos demais. Um determinado núcleo só
terá sua requisição de roteamento atendida se tiver prioridade superior aos outros núcleos
que estão enviando requisições ao árbitro naquele momento, ou então se não houver outra
requisição pendente no árbitro além da sua requisição. Uma vez que a requisição é atendida,
o canal que solicitou o envio de pacotes passa a ter a menor prioridade na arbitragem e
24
2. Tecnologias Relacionadas
só poderá enviar outro pacote na sequência se nenhum outro canal estiver requisitando um
roteamento.
Figura 2.20: Estrutura interna do roteador da RTSNoC.
Uma vez que foi definido qual canal terá prioridade de roteamento, o bloco árbitro envia
um comando ao bloco de switch, comunicando qual roteamento deve ser realizado naquele
momento. O roteamento adotado é o algoritmo XY. Este algoritmo é utilizado em NoCs com
topologia de malhas regulares, pois em sua operação um caminho deve primeiro percorre a
coordenada X para então efetuar o encaminhamento no eixo Y. Esta abordagem é utilizada
para evitar o problema de deadlock causados pela alocação de recursos feita por dois ou mais
fluxos.
Devido ao fato de o algoritmo XY ser utilizado no roteamento em redes com topologia
malha regular 2-D, é necessário fazer a alocação de determinados canais dos roteadores para
que se possa garantir o funcionamento deste tipo de algoritmo numa malha irregular. No
exemplo apresentado na figura 2.18b, o canal Oeste do roteador número sete está conectado
ao canal Sul do roteador número cinco. Se esta conexão não tivesse sido realizada, um
pacote gerado por algum núcleo do roteador número sete não conseguiria alcançar nenhum
dos núcleos conectados no roteador número cinco.
2.3. Network on Chip
25
Uma vez definida a arbitragem, o bloco arbiter envia um comando para o bloco
switch, responsável por controlar a crossbar que é quem realiza o encaminhamento do pacote
disponı́vel no registrador de entrada para o canal de saı́da.
O roteador da RTSNoC utiliza quatro ciclos de clock para realizar o encaminhamento
de um pacote. Na versão original são dois ciclos de clock, mas foi detectado um problema na
estrutura interna de roteamento, para um caso particular de transmissão de dados, e houve a
necessidade de alterar o roteador incluindo dois ciclos a mais, em média. Será realizado um
trabalho especı́fico para que o roteador possa novamente trabalhar apenas com dois ciclos de
clock.
2.3.5.3
Simulação funcional do roteador
Em um cenário onde foram colocados dois núcleos em um roteador RTSNoC. Um núcleo
conectado na porta Norte (NN) envia cinco pacotes para o núcleo conectado na porta Oeste
(WW). Os sinais do canal de comunicação são apresentados na figura 2.21, que é o resultado
desta simulação realizada na ferramenta ISE do fabricante Xilinx.
Figura 2.21: Simulação de envio de pacotes na RTSNoC.
Conforme ilustrado na figura 2.21, os dados a serem enviados pelo roteador são disponibilizados pelo núcleo 1 no barramento i DIN NN[37:0]. Uma vez que os dados estão disponı́veis
em i DIN NN, o núcleo gera um pulso de um perı́odo de clock em i WR NN para registrar
o dado no roteador. Em seguida, o roteador coloca o sinal o WAIT NN em nı́vel 1 até que
o dado disponibilizado pelo núcleo 1 possa ser encaminhado. Este sinal é um indicativo de
que o núcleo conectado na porta Norte deve esperar para poder enviar novo dado por aquela
porta. Quando o dado fica disponı́vel para a porta de destino, neste caso a porta Oeste
(WW), o roteador coloca o pino o ND WW em nı́vel lógico 1, indicando que existe um dado
26
2. Tecnologias Relacionadas
válido para aquela porta. O núcleo 2 deve então gerar um pulso de um ciclo de clock em
i RD WW para poder retirar este dado do roteador, que é disponibilizado no barramento
o DOUT WW[37:0].
2.3.5.4
Adaptadores de Canais na RTSNoC
A interconexão entre os canais de dois ou mais roteadores ou a interconexão entre os
núcleos e os roteadores deve ser feita através de adaptadores (wrappers). A figura 2.22 ilustra
um exemplo de interconexão entre roteadores e núcleos.
Figura 2.22: Uso de adaptadores na interconexão de roteadores e núcleos.
Os adaptadores são necessários devido ao fato de os canais de comunicação da RTSNoC
terem sido dimensionados para utilizarem o menor número possı́vel de sinais de handshake.
Como os canais de comunicação da Rede RTSNoC são bi-direcionais, são necessários dois
adaptadores para cada interconexão entre núcleos e roteadores ou entre roteadores.
A figura 2.23 apresenta uma máquina de estados de um exemplo de adaptador para a
RTSNoC. Esta máquina fica aguardando pela chegada de um novo dado no canal de comunicação (estado idle). Ao receber um novo dado, a máquina registra o pacote internamente,
verifica se o canal de destino está disponı́vel e, se estiver disponı́vel, encaminha o pacote.
2.4
Desenvolvimento para FPGA em alto nı́vel
Historicamente, os fluxos tradicionais para desenvolvimento de projeto em FPGA são
espelhados nos processos de desenvolvimento de Aplication Specific Integrated Circuits (ASICs).
2.4. Desenvolvimento para FPGA em alto nı́vel
27
Figura 2.23: Exemplo de uma máquin de estados para um adaptador RTSNoC.
Um modelo do sistema é criado a partir de uma linguagem imperativa, como C ou MATLAB. A fase de modelo representa a primeira oportunidade de realizar testes e validação do
sistema. Tipicamente, a implementação inicial é descrita em uma linguagem de descrição
hardware como VHDL ou Verilog para Register Transfer Level (RTL), que permite a descrição da lógica por comportamento. Normalmente, a descrição RTL envolve a instanciação
de Intellectual Property (IP) reutilizáveis (por exemplo, decodificador Viterbi, Fast Fourier
Transform (FFT), filtro Finite Impulse Response (FIR)), muitas vezes fornecidos pelo fabricante do FPGA, para assegurar a implementação eficiente de funções complexas.
Testes de conformidade e funcionais, para o modelo original do sistema, são feitos
através de simulação do HDL com a criação de testbenchs. Este acoplamento fraco entre o
modelo e a implementação do sistema faz a depuração difı́cil e demorada. Por exemplo os
testes, proporcionam apenas uma relação de entrada/saı́da, por isso é muitas vezes necessário
refazer o modelo de sistema, que em alguns casos é desenvolvido por uma equipe totalmente
diferente, a fim de extrair estados e sinais internos para a depuração.
Sytem Generator é um ambiente de projeto em nı́vel de sistema para FPGAs. O fluxo
de projeto é integrado ao Matlab/Simulink, permite sı́ntese de HDL para dispositivos Xilinx,
possui bibliotecas de IPs com blocos de aritmética, operadores lógicos e funções DSPs. Gera
testbench, arquivos para simulação e permite co-simulação em hardware.
Em contraste, ao desenvolvimento tradicional, o fluxo de desenvolvimento com base
no System Generator, ou ferramentas similares deriva o hardware diretamente do modelo
através da geração automática de código [19] [32]. O método utilizado pelo Sytem Generator,
28
2. Tecnologias Relacionadas
também conhecido como model-based design, visa aumentar a produtividade, devido o nı́vel
de abstração, e confiabilidade pela geração automática de códigos. A figura 2.24 mostra o
fluxo de desenvolvimento utilizando o System Generator, o diagrama apresenta um tı́pico
fluxo para co-simulação do HDL.
Figura 2.24: Fluxo de desenvolvimento utilizando o System Generator.
O System Generator estende a API padrão do Simulink criando uma interface para
a simulação do HDL diretamente em plataformas de hardware. A ferramenta faz a geração
do bitstream sem a necessidade da utilização de ferramentas de FPGA. Utilizar somente um
sistema permite acelerar significativamente a simulação e validação do projeto.
Em [29] (tabela 2.1) é apresentado uma comparação de “homem-hora” entre o tradicional modelo de desenvolvimento versus a abordagem em alto nı́vel. O levantamento dos
dados foram realizados no desenvolvimento um sistema SDR, levando em consideração as
seguintes categorias: (a) especificação de interface e algoritmo; (b) projeto dos módulos;
(c) modelagem, simulação e verificação; (d) desenvolvimento do VHDL; (e) verificação comportamental do VHDL; (f) integração dos módulos. As duas abordagens foram realizadas
individualmente por dois desenvolvedores com vários anos de experiência na implementação
de sistemas de comunicação. Mesmo sendo uma avaliação subjetiva pode-se concluir uma
maior produtividade utilizando desenvolvimento em alto nı́vel.
2.5. Considerações Finais
29
Tabela 2.1: Tabela de comparação desenvolvimento FPGA [29].
Especif.
Projeto Modelagem, Desenv. Verif. Integração
de interface
dos
simulação e
do
do
dos
Fluxo
e algoritmo módulos verificação VHDL VHDL módulos
1
0,25
2
0
0
0
A2
Reed Solomon Encode
40
40
0
40
60
20
B3
1
0,5
3
0
0
0
A
Reed Solomon Decode
20
80
0
60
100
20
B
0
0,25
3
0
0
0
A
Scrambler/Descrambler
1
1
0
1
6
3
B
0
0,25
1,5
0
0
0
A
Convulotional Encode
1
1
0
1
1
1
B
0
0,5
2
0
0
0
A
Viterbi Decode
8
8
0
8
16
24
B
0
0,25
1
0
0
0
A
Differential Enc/Dec
1
1
0
1
4
2
B
0
0,5
2
0
0
0
A
Interleaver/Deinterleaver
40
16
0
16
36
60
B
1
0,5
4
0
0
0
A
PSK Modulator (2,4,8)
5
5
0
4
3
3
B
1
4
16
0
0
0
A
Frame Sync
4
6
0
4
6
4
B
4
7
34,5
0
0
0
A
Totais
120
158
0
135
232
137
B
Blocos
2.5
Considerações Finais
Este capı́tulo introduziu conceitos fundamentais para o entendimento da proposta do
trabalho. Apresentou detalhes sobre SDRs, computação reconfigurável, redes-em-chip e abordagens de desenvolvimento em FPGA. No próximo capı́tulo será apresentado os trabalhos
relacionados que envolem grande parte desses conceitos.
2
3
Fluxo de projeto utilizando abordagem em alto nı́vel.
Fluxo de projeto utilizando abordagem tradicional.
30
2. Tecnologias Relacionadas
Capı́tulo 3
Trabalhos Relacionados
Várias arquiteturas de SDR foram propostas pela academia e a indústria nos últimos
anos, segundo [63] existem duas abordagens para arquiteturas de SDR que podem ser seguidas:
(i) baseada em hardware reconfigurável e (ii) baseada em um processador central, normalmente um DSP, com aceleradores para auxiliar a arquitetura. A segunda abordagem garante
uma elevada flexibilidade, mas também sofre de problemas relacionados com o consumo de
energia. Para reduzir o consumo de energia, algumas plataformas utilizam vários DSPs rodando a um clock relativamente em baixo. Nesse capı́tulo, vamos analisar diferentes soluções
propostas para arquiteturas de SDR com base nas duas abordagens mencionadas (Figura 3.1)
[4].
Figura 3.1: Categorização das soluções em SDR.
3.1
Arquiteturas com Processador Central
Esta seção fornece uma visão geral de algumas arquiteturas de SDR baseadas em um
processador central (DSPs), que possuem recursos extras, como aceleradores, para explorar o
32
3. Trabalhos Relacionados
paralelismo intrı́nseco de alguns blocos de rádio. Além disso, algumas das plataformas usam
a ideia de múltiplos núcleos, onde tarefas maiores são divididas em partes menores.
3.1.1
LeoCore
LeoCore [40] é um Application Specifc Instruction Set Processor (ASIP) para pro-
cessamento de sinais de rádio em banda base. Este núcleo foi desenvolvido para telefones
celulares, laptops, terminais de radiodifusão, Global Positioning System (GPS) e sistemas embarcados. A filosofia básica por trás da arquitetura é primeiro identificar em nı́vel algorı́tmico
as operações de processamento de sinal necessário para a aplicação, como: FFT, filtros, decimadores, interpoladores, geradores de forma de onda, etc. Em seguida mapear os para um
processamento adequado como um processador Single Instruction Multiple Data (SIMD) ou
um acelerador ASIC.
A arquitetura do LeoCore é dividida em quatro processadores otimizados de maneira
diferente para tratar um conjunto distinto de operações. Os processadores são classificados
como: RF front-end digital, processador SIMD, aceleradores de funções, processador para
controle e outras funções (3.2).
Figura 3.2: Arquitetura LeoCore [40].
O conjunto de instruções dessa arquitetura cobre estritamente funções de DSP mencionadas anteriormente, não permitindo executar aplicações de uso geral. Há uma troca
de flexibilidade por eficiência em nı́vel de instrução. Os principais problemas relacionados
a otimização são latência dos dados e consumo de energia. Para solucionar problemas de
latência são realizados paralelização de tarefas, para contornar os problemas de consumo de
energia foi proposto desligar os módulos ociosos [39].
3.1. Arquiteturas com Processador Central
33
Juntamente com o LeoCore é fornecido o Coresonic Developer Studio, uma ferramenta
de desenvolvimento que possui montador e depurador. Em publicações há benchmarks para
sistemas Digital Video Broadcasting - Terrestrial (DVB-T) e Worldwide Interoperability for
Microware Access (WiMAX)
3.1.2
Signal-processing On-Demand Architecture
Signal-processing On-Demand Architecture (SODA) é uma arquitetura para disposi-
tivos móveis com foco em redução de consumo de energia. A arquitetura é baseada em
dividir as tarefas em dois tipos de processadores, um para dados onde são realizadas as
operações de DSP, outro para controle que destina-se a executar as operações de sistema e
gerenciar os processadores de dados, através de Remote Procedure Call (RPC) e operações
de Direct Memory Access (DMA). A arquitetura é apresentada na figura 3.3 sendo composta
por um processador de controle, quatro processadores de dados e uma memória scratchpad.
Os componentes são interconectados por meio de um barramento compartilhado. Os processadores de dados possuem uma memória interna para instruções e dados, uma unidade de
processamento escalar e uma unidade SIMD para processamento vetorial.
Figura 3.3: Visão geral da arquitetura SODA [72].
34
3. Trabalhos Relacionados
Um aspecto importante desta arquitetura é que ela não utiliza uma abordagem multithreading, cada tarefa é realizada em uma unidade de processamento (PE). Essa abordagem
foi escolhida, devido as observações que fizeram durante o desenvolvimento da arquitetura,
onde a taxa de comunicação inter-unidade é muito mais baixa do que a intra-unidade para
aplicações de processamento de sinais em banda base. Os desenvolvedores da SODA desencorajam soluções multithreading para um projeto de processador de comunicação em banda
base.
3.1.3
Tomahawk
Tomahawk é uma plataforma heterogênea de SDR em um único chip. Como em muitas
outras soluções explora e paralelismo no nı́vel de tarefa. Sua principal caracterı́stica é o seu
CoreManager que é um escalonador dedicado em hardware (3.4). Essa arquitetura utiliza dois
processadores Reduced Instruction Set Computing (RISC) Tensilica para executar um sistema
operacional e funções de controle, seis unidades de DSP, um ASIP para decodificadores e
filtros. Todos as unidades do chip utilizam transferência sı́ncrona para diminuir o consumo
de energia [12]. Foram realizados testes na arquitetura para WiMAX e 3GPP Long Term
Evolution (LTE).
Figura 3.4: Arquitetura Tomahawk MPSoC [38].
Seu modelo de programação deve ser mencionado como uma das principais vantagens
da arquitetura, distinguindo-se das outras soluções. As tarefas são basicamente convertidos
em descrições de tarefas em tempo de compilação. Estas descrições são enviadas pela unidade
de controle para CoreManager com uma fila de comprimento máxima de dezesseis tarefas.
O mapeamento espacial e temporal dessas tarefas para as unidades do chip é então feita
automaticamente pelo CoreManager. Este modelo de programação facilita o desenvolvimento,
pois não é necessário o desenvolvimento das tarefas, diminuindo o ciclo de projeto.
3.2. Arquiteturas Reconfiguráveis
3.2
35
Arquiteturas Reconfiguráveis
Esta seção fornece uma visão geral de algumas arquiteturas reconfiguráveis de granu-
laridade grossa voltadas para processamento de fluxo de dados deSDR.
3.2.1
ADRES
A Architecture for Dynamically Reconfigurable Embedded Systems (ADRES) são unidades
de processamento que possuem uma arquitetura reconfigurável de granularidade grossa e são
usados para processamento em banda base.
Figura 3.5: Núcleo da arquitetura ADRES [10].
O diferencial da arquitetura ADRES é a utilização de um processador Very Long Instruction Word (VLIW) em um arranjo de elementos de processamento reconfiguráveis, como
mostrado na figura 3.5 [10]. Os autores apresentam que o uso de um processador VLIW ao
invés de um processador RISC, comum em outras arquiteturas, traz um ganho de velocidade
superior. Isso se da pelo fato que os processadores VLIW são capazes de explorar eficientemente paralelismo no nı́vel de instruções.
36
3. Trabalhos Relacionados
Os elementos de processamento do ADRES são unidades funcionais com bancos de
registradores acoplados que se comunicam através de memória compartilhada. Essa abordagem facilita a geração de código binário por compiladores, mas acarreta problemas de
escalabilidade nos bancos de registradores.
3.2.2
BUTTER e CREMA
BUTTER é uma arquitetura reconfigurável de granularidade grossa desenvolvida na
Tampere Universtity of Tehcnology [11].
A arquitetura é composta por uma matriz de
unidades de processamento, que pode ter as funcionalidades e interconexões definidas em
tempo de execução (figura 3.6). Essa caracterı́stica permite alcançar uma alta taxa de dados
necessária em aplicações de SDR.
Figura 3.6: Arquitetura Butter e Crema [25].
Normalmente a matriz de unidades de processamento tem uma dimensão de 4x8 elementos, sedo que cada elemento pode executar diferentes tipos de operações aritméticas. Essa
matriz foi idealizada para ser utilizada como um co-processador na combinada com um processador de propósito geral. Na plataforma dos desenvolvedores é acoplado um processador
open-source chamado COFFE [55], que é utilizado como um controlador global, enquanto a
matriz realiza computação intensiva.
Um novo núcleo reconfigurável foi concebido como evolução do BUTTER. O novo
3.2. Arquiteturas Reconfiguráveis
37
núcleo é chamado CREMA, permite em tempo de projeto adaptar a arquitetura de cada
unidade de processamento de acordo com os requisitos da aplicação. Esse recurso reduz a
flexibilidade de reproduzir instâncias especı́ficas, mas reduz o tempo de reconfigurabilidade e
o tamanho de uma lógica em FPGA.
3.2.3
Arquitetura de Canais para SDR de Múltiplas Camadas
A arquitetura proposta por [17] emprega o conceito de múltiplos canais entre a interface
fı́sica (hardware) e as camadas fı́sicas (PHYs) implementadas em software. A mudança de
paradigma de “manipulação do espectro” para “múltiplos canais” simplifica a interação com
o hardware e permite que a dependência da camada fı́sica (PHY) passe a ser um canal ou
um grupo de canais e não mais o hardware como um todo, permitindo o compartilhamento
da mesma janela amostrada pelo ADC por várias camadas fı́sicas. Essa simplificação tornou
transparente várias configurações do hardware, uma vez que a partir dos canais solicitados
(frequências centrais e larguras de banda) ao bloco de controle é possı́vel inferir todos os
parâmetros de configuração. A figura 3.7 apresenta um diagrama de blocos da arquitetura
proposta, a sua prototipação foi feita utilizando como base a plataforma USRP2 e o GNU
Radio, as alterações não diminuı́ram a flexibilidade no projeto ou em tempo de execução se
comparada com a arquitetura tradicional.
Figura 3.7: Arquitetura de múltiplos canais [17].
Outro benefı́cio proporcionado pelo conceito de canal é a possibilidade da adição de
uma estrutura de separação de canais no hardware, o que diminui drasticamente a ocupação
38
3. Trabalhos Relacionados
do processador de uso geral do sistema (host), uma vez que o paralelismo intrı́nseco existente
na separação de diversos canais, que exige o processamento concomitante do mesmo grupo
de dados, e a alta quantidade de amostras por segundo, proveniente das fases iniciais do
rádio, são caracterı́sticas onerosas para implementações em software e são beneficiados pela
implementação paralela do hardware.
3.2.4
CRUSH
Cognitive Radio Universal Software Hardware (CRUSH) proposta por [21] é uma ar-
quitetura para SDR com foco em aplicações de rádio cognitivo, sua principal ideia é mover
o processamento de dados mais próximo do front-end utilizando FPGAs, pois esses componentes permitem alto desempenho e reconfigurabilidade. A proposta propõe resolver um
problema encontrado atualmente, onde grande parte das amostras são processadas utilizando
um computador como host impactando muito em rádios que possuem tarefas com tempo
crı́tico.
A figura 3.8 apresenta um digrama em blocos da arquitetura CRUSH, é composta
por um kit de desenvolvimento FPGA Xilinx ML605 conectado a uma USRP N210, dessa
forma, aumentando os recursos de lógica programável disponı́veis. Para um cenário de testes
da plataforma foi implementado um algoritmo de sensoriamento de espectro, utilizado para
determinar a disponibilidade de canais para comunicações de rádio cognitivos. Os resultados
mostram ganhos significativos na execução de FFTs e no ciclo completo de sensoriamento do
espectro.
Figura 3.8: Diagrama do sistema CRUSH [21].
3.3. Considerações Finais
3.3
39
Considerações Finais
Além das arquiteturas apresentadas existem outras que foram propostas nos últimos
anos, SandBridge Sandblaster [68], NXP Embedded Vector Processor (EVP) [57], Heterogeneous Reconfigurable System (HERS) [54].
Muitas das arquiteturas consistem em um System on Chips (SoCs) que incluem um
processador de propósito geral para implementação das camadas mais altas dos protocolos e
co-processadores SIMD para fazer processamento dos sinais. Apesar de muitas das arquiteturas apresentadas atingirem os requisitos de desempenho, elas impõem muitas dificuldades
no desenvolvimento de aplicações. Por exemplo, na maioria das arquiteturas o desenvolvedor deve dividir as tarefas, definir as partes que rodaram em software, nos aceleradores e
nas unidades DSP. No caso das unidades DSP deve-se escrever as tarefas diretamente na
linguagem assembly para a maioria dos casos.
Segundo [4] num futuro próximo a evolução dessas arquiteturas é adotar o paradigma de
NoC para integrar um número crescente de subsistemas com altas demandas computacionais.
Os próximos desafios da área são aumentar o poder de processamento, limitar o consumo de
energia e tornar mais flexı́vel o processo de desenvolvimento dos SDRs.
40
3. Trabalhos Relacionados
Capı́tulo 4
Arquitetura Heterogênea e
Reconfigurável
Neste capı́tulo, inicialmente, apresenta-se os fatores que motivaram o desenvolvimento
de uma nova arquitetura para SDR. Em seguida é mostrada a arquitetura e suas caracterı́sticas.
4.1
Motivações
Os trabalhos relacionados, apresentados no capı́tulo 3, levantam as principais carac-
terı́sticas que as futuras arquiteturas de SDR devem possuir:
• Alto poder de processamento.
• Baixo consumo de energia.
• Reconfigurabilidade.
• Facilidade de programação.
A metodologia para desenvolvimento de arquiteturas de SDR proposta em [40] sugere
que o primeiro passo do projeto é especificar os potenciais produtos que a arquitetura pretende atender. Por exemplo, a arquitetura será utilizada em telefones celulares, terminais
de radiodifusão, sistemas de posicionamento global. Após a especificação dos produtos, os
padrões relacionados devem ser coletados (802.11 a/b/g/n, DVB-T), a partir dos padrões são
definidos os subsistemas como: (a) Digital front-end, (b) sincronizadores, (c) estimadores de
canais, (d) equalizadores de canais e (e) módulos corretores de erros. Por fim, os algoritmos
necessários pelos subsistemas são especificados e alocados para o hardware (figura 4.1).
42
4. Arquitetura Heterogênea e Reconfigurável
Figura 4.1: Exploração de arquiteturas de SDR.
Segundo análises realizadas por Anjum et al [4] em aplicações de rádio, cerca de 90%
do tempo de execução do processamento na camada fı́sica é usado para executar os seguintes
algoritmos:
• Filtros de dados do tipo inteiro, utilizados para filtragem e correlação.
• Filtros de dados do tipo complexo, utilizados em filtros passa-baixo e banda-passante,
identificação de preâmbulos, adaptação de taxas, sincronização de fase e quadratura.
• Algoritmos de transformação como FFT, Discrete Cosine Transform (DCT) e transformada de Walsh.
• Processamento de sinais no domı́nio da frequência, como filtros, processamento de subportadoras, estimação de canais e equalização.
• Algoritmos de divisão, raiz quadrada de dados inteiros e complexos, geradores de onda.
• Computação de matrizes em ambos os domı́nios do tempo e da frequência incluindo
soma, multiplicação, transposição e decomposição de matrizes.
• Algoritmos de Forward Error Correction (FEC) e Cyclic Redundant Check (CRC).
Vários decodificadores FEC são amplamente adotados nos sistemas modernos de comunicação sem fio.
Desta forma, conclui-se que uma arquitetura capaz de otimizar a execução desta classe
de algoritmos, denominados essenciais, por consequência irá aumentar o desempenho e eficiência
do sistema.
4.2. Arquitetura Proposta
43
A arquitetura a ser proposta tem como meta atender alguns requisitos, como desempenho e flexibilidade, que podem variar de acordo com a aplicação e as caracterı́sticas do
rádio a ser implementado. Para alcançar esses requisitos, optou-se por utilizar os recursos de
paralelismo e reconfiguração utilizando o paradigma de computação reconfigurável.
O paralelismo será alcançado utilizando o processamento simultâneo de vários blocos
de processamento de sinal com o intuito de diminuir o tempo de execução do fluxo de dados.
A arquitetura possuirá um grau de paralelismo variável, de acordo com a demanda de cada
aplicação. Já a utilização da reconfiguração tem o intuito de tornar a arquitetura mais flexı́vel
(adaptável para cada tipo de rádio e requisitos da aplicação), visto que ela permite alterar algumas de suas caracterı́sticas. Com o aumento da flexibilidade, espera-se, por exemplo, poder
fazer a opção de realizar o processamento de um bloco em software de propósito geral ou em
um bloco de hardware dedicado, em detrimento de um maior consumo de recursos lógicos, ou
vice-versa. As técnicas de reconfiguração também possibilitam uma maior tolerância a falhas
no circuito digital, pois no caso de defeito em alguma parte do dispositivo, o circuito pode ser
implementado em outra área do chip. Além disso, com a computação reconfigurável podese obter uma significativa redução de custos, uma vez que o recurso de reconfigurabilidade
permite a utilização do mesmo hardware para diferentes versões do produto.
4.2
Arquitetura Proposta
A nova arquitetura proposta usa a ideia de paralelismo ao nı́vel de tarefa utilizando
uma estrutura heterogênea com componentes de processamento em software e hardware. Os
componentes de hardware são dedicados para a execução de uma tarefa, podendo ser chamados de aceleradores, e podem ser reconfigurados dependendo das necessidades da aplicação.
Essa abordagem propõe o mapeamento de tarefas em hardware com a finalidade de aumentar
o desempenho do sistema.
O diferencial desta proposta é a utilização de uma NoC como forma de interconexão e
comunicação dos blocos de processamento. Como forma de programação a arquitetura oferece
um framework que possibilita o mapeamento das tarefas de alto nı́vel em hardware, por meio
de um bloco de controle, este bloco controla o fluxo de execução e realiza a configuração dos
parâmetros dos nodos em hardware.
A arquitetura proposta é apresentada na figura 4.2 sendo composta dos seguintes blocos:
Interface RF: bloco responsável por realizar a interface com ADCs e DACs, que fazem a
conversão dos sinais RF, sendo este nodo o fonte para um SDR. O bloco também realiza
toda a parte de DFE DDCs e DUCs.
44
4. Arquitetura Heterogênea e Reconfigurável
Controle: bloco responsável pelo controle e conexão dos nodos para a formação do SDR,
também do fluxo e da taxa de dados entre os nodos. É composto por um processador,
sof-core arquitetura MicroBlaze, e periféricos conectados pelo barramento AMBA4
AXI-Lite 1 .
Interconexão: a comunicação entre os blocos da arquitetura é realizada por meio de uma
rede-em-chip, os núcleos pertencentes ao bloco de controle se conectam por meio de um
barramento compartilhado. A comunicação entre o bloco de controle e os outros blocos
se da por uma bridge entre a rede-em-chip e o barramento compartilhado.
Aceleradores: são blocos que realizam uma tarefa especifica de processamento digital de
sinais, mais especificamente os algoritmos essenciais (citados anteriormente) para camada fı́sica de um rádio. A arquitetura prevê dois aceleradores fixos (FFT e um filtro
FIR) e um espaço em silı́cio para ser reconfigurável com outros aceleradores.
Interface de rede: a arquitetura possui uma interface de rede Ethernet Gigabit que permite
comunicação com um host.
Interfaces seriais: a arquitetura possui interfaces seriais de baixa velocidade (Universal
Asynchronous Receiver Transmitter (UART), Inter-Integrated Circuit (I2C), Serial Peripheral Interface (SPI)) que são utilizadas para realizar depurações e configurações de
dispositivos externos, por exemplo, um front-end analógico.
Figura 4.2: Visão geral da arquitetura proposta.
A arquitetura proposta não oferece uma solução completa para um SDR, pois não
possui um processador de propósito geral com alto poder de processamento. Desta forma,
é necessário a sua integração com um host para a implementação das camadas de mais alto
1
AMBA é um padrão aberto de gerenciamento e interconexão intra-chip e de blocos funcionais para um
SoC.
4.2. Arquitetura Proposta
45
nı́vel de um rádio. O bloco de controle poderia substituir o host, mas por ser composto por um
softcore 2 de baixo processamento pode realizar eficientemente somente funções de controle
e configuração. Uma futura expansão poderia ser adicionar um hardcore com maior poder
de processamento, como processadores da arquitetura Advanced RISC Machine (ARM) que
atualmente estão sendo utilizados amplamente na industria.
Nas seções que seguem será apresentado em mais detalhes os blocos da arquitetura, a
forma de programação e o mecanismo para controle de fluxo.
4.2.1
Bloco RF Interface
A interface com o mundo RF na arquitetura proposta é realizado por meio do bloco
RF Interface, cujas principais funções são: (a) realizar a interface de aquisição e transmissão
de dados com os ADCs e DACs configurando e controlando; (b) implementar toda a parte
de Digital Front-end (DFE) (DDC, DUC, filtragem) para converter o sinal de uma IF para
banda base e vice-versa; (c) realizar interface com a rede-em-chip para enviar e receber dados
dos outros blocos, como também dados de controle para configuração dos módulos internos
do bloco.
Na implementação das funcionalidades de Digital Front-end para essa arquitetura,
foram definidos os seguintes limites a serem atendidos: (a) capacidade de transmissão e
recepção; (b) taxa de amostragem de 64M hz e quantificação de 12 bits para recepção e
128M hz de 14 bits para transmissão; (c) suporte para amostras complexas; (d) flexibilidade
de trocar o canal pela mudança da frequência central do DDC. Para a implementação dos
DDCs e DUCs é utilizado o algoritmo CORDIC para geração das sinusoides para translação
na frequência. As mudanças de taxas (interpolação e decimação) são realizadas utilizando a
classe de filtros Cascaded Integrator-Comb (CIC). Já a filtragem utiliza filtro FIR half-band
com 31 taps e também realiza uma decimação de fator dois.
O bloco RF Interface possui interfaces para dois ADCs e dois DACs, o controle dos
dispositivos pode ser feito pelas interfaces seriais (SPI e I2C) e aquisição e o envio de dados
é feito por interfaces paralelas sı́ncronas que utilizam um clock com a taxa de transmissão
para sincronização. A recepção de dados pode ser feita na forma complexa, para cada ADC
há um barramento de 12 bits para parte real ou imaginária. A implementação desse bloco foi
feita baseada na arquitetura da plataforma USRP utilizada amplamente com o GNU Radio,
a figura 4.3 mostra um diagrama de blocos da RF Interface.
O caminho de recepção dos dados é feito a partir da captura dos dados de um ADC,
em seguida o sinal é decimado, filtrado e convertido para banda base por fim é escrito em
uma First-In First-Out (FIFO) para ser enviado pela NoC. Já o caminho de transmissão os
2
Softcore é o núcleo de um microprocessador todo implementado em lógica sintetizável para ser utilizado
em dispositivos como FPGAs e ASICs.
46
4. Arquitetura Heterogênea e Reconfigurável
Figura 4.3: Diagrama de blocos da interface RF.
dados são recebidos em uma FIFO pela NoC, logo após o sinal é interpolado e filtrado, por
fim enviado para o DAC. A configuração dos fatores de decimação, interpolação e dos filtros
é realizado a partir de registradores de controle.
4.2.2
Controle
O bloco responsável por configurar os blocos da arquitetura, controlar o roteamento de
dados pela NoC e configurar dispositivos externos (ADCs e DACs) é chamado de Controle.
Este bloco tem um papel importante na arquitetura e para realizar todas essas tarefas necessita ser flexı́vel, por isso é formado pelo processador AeMB um softcore e outros periféricos
interligados por um barramento compartilhado o AMBA4, podendo ser programado na linguagem C. A comunicação entre o processador e a NoC é feita por um bloco chamado NoC
Bridge, este bloco faz a ponte entre NoC e o AMBA4, dessa forma o processador realiza
comunicação com os outros blocos e recebe os pacotes configuração do host.
Arquiteturas reconfiguráveis de granularidade grossa apresentam diversas vantagens do
ponto de vista de hardware para exploração de diversos tipos de paralelismo em aplicações. No
entanto, em conjunto com essas arquiteturas é necessário o desenvolvimento de ferramentas
que permitam o mapeamento de aplicação descritas em alto nı́vel para os recursos presentes no
hardware. Park et al. [59] propõem um método chamado Modulo Graph Embedding, baseado
em uma técnica utilizada para layout e visualização de grafos. Essa técnica consiste na
alocação de um grafo “convidado” em um grafo “hospedeiro”. O escalonamento de aplicações
é feito através de um grafo de fluxo de dados e de um grafo representando os recursos de
processamento presentes na arquitetura.
4.2. Arquitetura Proposta
47
Um dos problemas das arquiteturas de SDR que utilizam aceleração em hardware é
a sua forma de programação, é difı́cil para o desenvolvedor mapear as tarefas em alto nı́vel
para hardware. Este trabalho propõe uma abordagem semelhante a utilizada por Park et al.,
as tarefas que serão executadas na arquitetura formam um grafo “convidado”, o flowgraph é
constituı́do a partir do host que envia pacotes de configuração para o bloco de controle, este
então configura os blocos da arquitetura. A figura 4.4 apresenta um diagrama que mostra um
exemplo do processo de configuração dos blocos e determinação do flowgraph e transferência
dos dados entre os blocos e o host.
Figura 4.4: Representação gráfica do filtro FIR.
No exemplo apresentado na figura 4.4 primeiramente: (1) o host define o flowgraph
enviando pacotes de configuração para o bloco de controle esse bloco então envia os pacotes
para os blocos DFE e ACC1; (2) na sequência o host envia um pacote para iniciar a execução
do grafo; (3) baseado no flowgraph configurado o bloco DFE começa enviar dados para o bloco
ACC1 e esse após realizar o processamento envia para o host; (4) por fim o host finaliza o
fluxo de dados enviando um pacote para finalizar a execução.
Na arquitetura proposta utiliza-se a infraestrutura do GNU Radio (vide seção 2.1.2)
para a construção do grafo “hospedeiro”. Para tanto, é necessário criar blocos do tipo source
sink da arquitetura para o GNU Radio, estes blocos possuem métodos para que a partir
da forma de programação do GNU Radio seja possı́vel configurar os blocos aceleradores da
arquitetura.
Abaixo é apresentado um exemplo de programação da arquitetura utilizando o GNU
Radio, onde primeiramente é realizado a instanciação do objeto que se comunica com a arquitetura. Na sequência são realizadas configurações dos blocos RF Interface e do acelerador
FIR, como taxa de amostragem, frequência central e o tipo de filtragem. Por fim, é realizado
a definição do flowgraph configurando a rota de saı́da do stream de dados de cada bloco e no
host a gravação dos dados recebidos.
48
1
2
3
4. Arquitetura Heterogênea e Reconfigurável
from gnuradio import eng_notation
from gnuradio import gr
from gnuradio import uhd
4
5
6
7
class arch_noc_test(gr.top_block):
def __init__(self):
self.uhd_src = uhd.arch_noc_source(device_addr=’192.168.20.1’)
8
# Config DFE
self.uhd_src.dfe.set_samp_rate(200000)
self.uhd_src.dfe.set_center_freq(450e6, 0)
self.uhd_src.dfe.set_gain(0, 0)
self.uhd_src.dfe.route(0,0,SE)
9
10
11
12
13
14
# Config accelerator Filter FIR
taps = firdes.low_pass_2(1, 1, 0.4, 0.1, 60)
self.uhd_src.filter_fir.taps(10, taps)
self.uhd_src.filter_fir.route(0,0,SS)
15
16
17
18
19
# Use file sink to capture data from arch_noc
self.fsnk = gr.file_sink (gr.sizeof_gr_complex, test.dat)
20
21
22
# Connections
self.connect((self.uhd_src, 0), (self.fsnk, 0))
23
24
25
26
27
28
if __name__ == ’__main__’:
tb = arch_noc_test()
tb.run()
4.2.3
Interconexão
A interconexão entre os núcleos se dá através da infraestrutura provida pela rede-
em-chip RTSNoC. O propósito deste modelo de interconexão é substituir os barramentos
compartilhados para a comunicação dos blocos, normalmente utilizados em sistemas em chip.
Os barramentos compartilhados apresentam problemas de escalabilidade, não determinismo
na comunicação, dissipação de energia, ruı́dos e interferência eletromagnética.
O uso da NoC para interconexão da arquitetura trás as vantagens de melhorar o controle
dos parâmetros elétricos e escalabilidade, quando comparada com barramentos compartilhados e pipelines. Porém, a principal vantagem que pode ser destacada é a interface padrão de
comunicação bem definida que permite o reuso, facilidade da migração de tarefas em software
para aceleradores em hardware. Além de que a natureza de comunicação sı́ncrona adotada
pela RTSNoC diminui o consumo de energia.
O bloco de controle apresentado na seção anterior é responsável por determinar o
4.2. Arquitetura Proposta
49
roteamento do stream de dados pela infraestrutura da rede, ou seja, realizar a conexão dos
nodos. Para realizar a sincronização, o controle de fluxo, configuração dos blocos e transporte
dos dados, foram definidos dois tipos de pacotes para a NoC: dados e configuração. O tipo de
pacote enviado para os blocos é identificado por meio de um cabeçalho (conforme apresentado
na figura 4.5). Os pacotes de dados possuem somente informações referentes ao roteamento
e como carga os dados para processamento de sinais. Já os pacotes de configuração podem
ter as seguintes informações:
• configurações de roteamento para o bloco, isto é, a indicação dos endereços de destino,
para onde os dados do bloco que esta sendo configurado devem ser enviados. Essa
informação é utilizada durante a formação dos pacotes de dados.
• Configurações referentes aos blocos, por exemplo, no bloco interface RF a configuração
da frequência central de um DDC.
Figura 4.5: Estruturas dos pacotes de configuração e dados.
Normalmente as configurações de cada bloco são distintas, inerentes a solução que
cada bloco se propõe resolver, por isso o pacote de configuração possui um campo tipo
de configuração que está atrelado a cada bloco. Dessa forma, comandos para controle e
configuração são disparados pelo host para o bloco de controle e este cria os pacotes da NoC
envia para os blocos da arquitetura.
4.2.4
Aceleradores
A arquitetura propõe a implementação da classe de algoritmos essenciais (vide seção
4.1), que são implementados em software nas arquiteturas tradicionais de SDR, na forma
de blocos especı́ficos em hardware denominados aceleradores. Esse método possui as vantagens que permite aumentar a eficiência do algoritmo, além do que uma abordagem com
aceleradores diminui os problemas de latência da NoC.
50
4. Arquitetura Heterogênea e Reconfigurável
A solução utilizada para o projeto e desenvolvimento dos aceleradores é semelhante ao
desenvolvimento em alto nı́vel para FPGA, abordada na seção 2.4. Nessa abordagem o fluxo
de projeto inicia com o desenvolvimento do modelo em blocos e simulação em MATLAB,
após a validação do funcionamento do sistema é feita a troca dos blocos pelos do System
Generator Xilinx, por fim é gerado HDL para integração na infraestrutura de interconexão
da arquitetura. Além disso, os fabricantes de FPGA e outras empresas disponibilizam uma
grande variedade algoritmos de DSP na forma de IP também conhecidos como núcleos. Esses
IPs são feitos como módulos pré-definidos para FPGAs, dessa forma podem ser otimizados
para o dispositivo.
Para os aceleradores desenvolvidos foi escolhido remover as operações de ponto flutuante, pois este tipo de operação é bastante custoso do ponto de vista energético e em área de
silı́cio, e a grande maioria das arquiteturas para SDR pesquisadas não utilizam unidade de
ponto flutuante.
Para demonstrar a solução proposta, foram escolhidos dois algoritmos amplamente
uitilizados: FFT e um filtro FIR. A FFT tem suporte a uma janela 64-4096 pontos e o filtro
FIR com 64 taps onde é possı́vel configurá-lo como: passa-baixas; passa-alta; passa-banda e
rejeita-banda. Somente dois aceleradores não são suficientes para construir rádios modernos,
mas não é escopo deste trabalho criar aceleradores para os algoritmos essenciais. O uso de
computação reconfigurável e uma interface de comunicação bem definida com NoC, facilita a
adição e substituição de aceleradores conforme a necessidade do sistema dessa forma utilizar
uma abordagem orientada a aplicação.
4.2.5
Interface com o Host
A arquitetura proposta possui um bloco responsável pela comunicação com um host,
nesse caso o host realiza a configuração da arquitetura e a implementação das camadas de
mais alto nı́vel de um SDR. Com o intuito de dar uma maior flexibilidade para a arquitetura e
diminuir o tempo de latência de comunicação foi escolhida a interface padrão Gigabit Ethernet
(GbE). O bloco implementa a camada Media Access Control (MAC) do padrão GbE, o
desenvolvimento do bloco foi feita baseada no Tri-mode Ethernet MAC [24] do OpenCores 3
e no bloco utilizado pela USRP2. As principais caracterı́sticas do bloco são descritas abaixo
e um diagrama de blocos é apresentado na figura 4.6a:
• implementação completa do MAC seguindo a especificação IEEE 802.3.
• verificação e geração de pacotes com CRC.
• FIFOs para interface de uso do bloco.
3
OpenCores é uma comunidade Open Source para o desenvolvimento de hardware digital.
4.2. Arquitetura Proposta
51
• suporte para frames Jumbo (4096 bytes).
• suporte a controle de fluxo com geração de pause e termination frame (802.3 anexo 31A),
provendo um completo automatizado controle de fluxo sem sobrecarga para aplicação
de uso.
• interface para gerenciamento da Ethernet Physical Layer (PHY) por Management Data
Input/Output (MDIO).
(a) Arquitetura do bloco GbE
(b) Conexão entre o bloco
MAC GbE e o PHY
Figura 4.6: Diagrama de blocos da interface GbE
Para facilitar e tornar mais eficiente a comunicação com host o bloco GbE possui nos
caminhos de transmissão e recepção um módulo User Datagram Protocol (UDP), o módulo
realiza o tratamento geração dos pacotes UDP todo em hardware. O módulo UDP é capaz
de identificar os pacotes de controle e dados, os pacotes de dados são roteados para o bloco
de controle e os de dados para os aceleradores.
O bloco GbE implementa a camada MAC e para conexão com outros dispositivos
possui a interface Gigabit Medium Independent Interface (GMII), que é um padrão industrial
52
4. Arquitetura Heterogênea e Reconfigurável
utilizado para conexão com PHYs a figura 4.6b apresenta a o padrão de conexão dos sinais.
Além disso, o bloco possui uma interface MDIO que permite configurar, controlar e receber
estatı́sticas da PHY.
4.3
Fluxo de projeto para nova aplicações
Atualmente, existem uma série de dificuldades encontrar blocos (IPs) que implementem
os principais algoritmos utilizados em SDR. Além disso, é a implementação de novos IPs difı́cil
pois os desenvolvedores devem ter um bom conhecimento do algoritmo a ser desenvolvido e
de computação reconfigurável. Tentando minimizar este problema a arquitetura criou uma
interface bem definida utilizando a NoC como infraestrutura de comunicação e sugeriu uma
abordagem de alto nı́vel para desenvolvimento dos aceleradores.
Para utilização da arquitetura este trabalho propõe um fluxo de projeto que tem por
objetivo simplificar os procedimentos de criação de um SDR. A figura 4.7 ilustra as etapas
do fluxo de projetos, as quais são resumidas a seguir:
1. Definição da aplicação pretende-se desenvolver, por exemplo, Rádio FM.
2. Especificar os algoritmos que ocupam mais processamento para sua implementação em
hardware.
3. Implementar os algoritmos em HDL utilizando a abordagem de desenvolvimento em
alto nı́vel para FPGA, ou realizar uma pesquisa por IPs que implementem o algoritmo.
4. Criar os wrappers para os aceleradores receberem e enviarem dados pela NoC.
5. Conectar todos os blocos e gerar o bitstream para a arquitetura alvo.
6. Definir os parâmetros de configuração e criar um wrapper para o acelerador no GNU
Radio
7. Criar um programa para aplicação no host.
Este fluxo de projeto simplifica os procedimentos para a criação de uma aplicação na
arquitetura proposta e permite criar componentes reutilizáveis para futuras implementações.
A principal dificuldade do fluxo é a verificação e validação dos aceleradores, mesmo sendo
facilitada utilizando uma abordagem em alto nı́vel. As tarefas passı́veis de serem automatizadas são as conexões dos blocos para gerar o bitstream e a criação dos wrappers para o GNU
Radio.
4.4. Resumo da Proposta
53
Figura 4.7: Fluxo de projeto de um SDR para a arquitetura.
4.4
Resumo da Proposta
A arquitetura proposta no trabalho utiliza o conceito de computação reconfigurável
empregando uma NoC para realizar a infraestrutura de comunicação, esta abordagem melhora
problemas de escalabilidade, reconfigurabilidade e parâmetros elétricos. A granularidade
adotada é do tipo grossa para a implementação dos algoritmos de processamento de sinais.
A forma de programação utilizada pela arquitetura permite mapear tarefas de alto nı́vel de
um rádio para um grafo, as tarefas são disparadas por um host para um bloco de controle
que determina o roteamento dos dados. Para se beneficiar das vantagens do GNU Radio a
arquitetura criou uma interface compatı́vel que permite o uso deste framework no host.
Outro benefı́cio proporcionado pela arquitetura é o processamento em hardware dos
algoritmos essenciais para um SDR, o que diminui drasticamente a ocupação do processador
de uso geral do sistema (host), uma vez que os aceleradores realizam processamento nas fases
iniciais do rádios. Fases onde há uma maior demanda de processamento e a alta quantidade
de amostras por segundo e são beneficiados pela implementação paralela do hardware.
No próximo capı́tulo serão abordados os aspectos de implementação da arquitetura e a
comparação da proposta com a arquitetura USRP executando o GNU Radio.
54
4. Arquitetura Heterogênea e Reconfigurável
Capı́tulo 5
Implementação e Avaliação da
Proposta
Este capı́tulo apresenta os resultados obtidos através de experimentos realizados com a
implementação da arquitetura proposta. Para isso, inicialmente é apresentada a plataforma
utilizada para a implementação da arquitetura proposta, assim como a descrição dos experimentos realizados e os resultados obtidos.
5.1
Implementação da Arquitetura Proposta
Nesta seção apresenta-se o ambiente de hardware e software utilizado para desenvolver
um protótipo da arquitetura proposta no trabalho. Primeiro, descreve-se as plataformas de
desenvolvimento utilizadas e os módulos de hardware de prototipação. Em seguida, descrevese quais softwares comerciais foram empregados e os aplicativos implementados para habilitar
o desenvolvimento do estudo de caso.
5.1.1
FPGA Virtex-6 Xilinx
O FPGA Virtex-6 da Xilinx foi utilizado para implementar e testar a arquitetura pro-
posta. Essa famı́lia foi desenvolvida em 2009 para dar sequência às famı́lias de alto desempenho da Xilinx, utiliza o processo de fabricação de 40 nm e possui os mais avançados recursos
disponı́veis no mercado de FPGA.
O modelo utilizado foi XC6VLX240T, que possui 241.152 células lógicas, 37680 slices,
768 Block Random Access Memorys (RAMs) de 18 Kb e 720 sinais para entrada e saı́da.
Outros blocos também são fornecidos entre eles, o DSP48E1 slices para a implementação de
56
5. Implementação e Avaliação da Proposta
estrutura tı́picas presentes em algoritmos para processamento de sinais, além de blocos para
gerenciamento de sinais de clock, Peripheral Component Interconnect (PCI) Express e MACs
Ethernet.
Todos os testes utilizaram o kit ML605, a figura 5.1 apresenta seu diagrama de blocos.
A placa possui o FPGA Virtex-6, um soquete SODIMM para memória DDR3 e diversas
interfaces de comunicação e conectores para expansão. Para a sintetização de hardware, foi
utilizado a ferramenta ISE Foundantion, versão 13.1, fornecida pela Xilinx no seu programa
universitário.
Figura 5.1: Digrama de blocos do kit ML605 [28].
5.1.2
BESDR - Placa Front-End RF
A Board for Embedded Software-defined Radio (BESDR) é uma plataforma aberta, de
baixo custo desenvolvida no contexto deste trabalho pelo Laboratório de Integração Software
e Hardware (LISHA) [16], tem como objetivo prover uma interface de RF para kits de desenvolvimento FPGA, compatı́vel com padrão FPGA Mezzanine Card (FMC) de conexão.
Sendo basicamente composta por:
• dois ADCs com quatro canais de 12-bit, amostragem de 64 M SP S.
• dois DACs com quatro canais de 14-bit, amostragem de 128 M SP S.
• quatro slots para placas filhas que suporta uma grande variedade de placas de RF.
5.1. Implementação da Arquitetura Proposta
57
• interface auxiliar para controle do rádio que suporta padrões como Received Signal
Strength Indication (RSSI) e Automatic Gain Control (AGC).
• um conector para a conexão aos kits de desenvolvimento.
O principal objetivo da BESDR é permitir o desenvolvimento e prototipação rápida de
SDRs de baixo custo. A figura 5.2 apresenta um exemplo de utilização da placa e a figura
5.3 o diagrama de blocos da BESDR.
Figura 5.2: Exemplo de utilização da BESDR.
A interface de conexão utilizado pela BESDR o FMC, foi um padrão desenvolvido
pelo consorcio American National Standards Institute (ANSI) / VITA 57.1 formado por
diversas empresas fabricantes e usuárias de FPGA. O propósito é especificar padrões elétricos,
mecânicos de conexão e desta forma permitir a flexibilização, reuso do hardware e criar um
mercado de placas de aplicação para FPGAs [1]. O conector utilizado na BESDR é o tipo
FMC High Pin Count (HPC), por meio dele a placa:
• recebe os sinais de alimentação: +12V , +3.3V , 2.5V e GND.
• recebe o clock de referência dos ADCs, DACs e placas filhas.
• recebe os barramentos para configuração e controle: SPI, I2C e UART.
• externaliza os sinais dos ADCs e DACs.
5.1.2.1
Caminhos de Recepção e de Transmissão
Os quatro canais de recepção dos ADCs presentes na placa podem realizar uma amostragem
de até 64 M SP S. Em teoria, pode-se digitalizar uma banda de até 32 M Hz, caso realize-se
amostragem de uma IF com uma largura de banda maior que 32 M Hz ocorrerá o fenômeno
de aliasing, e a banda de interesse será mapeada entre -32 M Hz e +32 M Hz [42]. Quanto
maior a frequência do sinal amostrado maior é a degradação do Signal-to-Noise Ratio (SNR)
por meio do jitter.
58
5. Implementação e Avaliação da Proposta
Figura 5.3: Diagrama de blocos da BESDR.
A entrada de tensão dos ADCs é de 2 V pico-a-pico e a impedância de 50 ohms, ou
seja, potência de 40 mW ou 16 dBm. Um Programmable Gain Amplifier (PGA) é usado
antes dos ADCs para amplificar o sinal de entrada, e utilizar toda a faixa de entrada do
ADCs, caso o sinal for fraco. A faixa de ganho do PGA é de até 20 dB. É possı́vel utilizar
outras taxas de amostragem submúltiplas de 128 M Hz, tais como 64 M SP S, 42,66 M SP S,
32 M SP S, 25,6 M SP S e 21,33 M SP S. A figura 5.4a apresenta o caminho de recepção.
No caminho de transmissão, também há quatro canais como uma taxa de amostragem
de até 128 M SP S, de modo que a frequência de Nyquist é de 64 M Hz. Entretanto, utilizar
uma faixa de frequência de até 50 M Hz torna o processo de filtragem mais simples. Os DACs
podem fornecer um 1 V de pico para uma carga de 50 ohms, ou seja potência de 10 mW ou
10 dBm. Há também um PGA utilizado após a DAC, fornecendo até obter 20dB. O PGAs
em ambos os caminhos, recepção e transmissão, são programáveis. A figura 5.4b apresenta o
caminho de transmissão.
Em princı́pio, os quatro canais de entrada e saı́da utilizam amostras reais. Entretanto,
haverá mais flexibilidade e banda se amostras complexas forem utilizadas. Desta forma
resultando em dois canais de entrada complexos e dois canais de saı́da complexos [15].
5.1. Implementação da Arquitetura Proposta
59
(a) Caminho de Recepção do ADC
(b) Caminho de Transmissão do DAC.
Figura 5.4: Caminhos de Recepção e Transmissão do ADC e DAC.
5.1.2.2
Placas filhas
A BESDR possui quatro slots para placas filhas, onde pode-se conectar até duas placas
de recepção e duas de transmissão. As placas implementam o Front-End RF analógico, a
função delas é converter as frequências da portadora de interesse para uma IF possibilitando
a digitalização do sinal pelo ADC na recepção, o caminho inverso é feito para transmissão.
Caso seja utilizada amostragem real, são disponı́veis duas secões RF independentes em
cada placa filha, podendo ser utilizadas até quatro antenas em todo o sisetma. Se amostragem
complexa for utilizada, cada placa filha suporta uma interface RF. A BESDR não utiliza
nenhum filtro anti-aliasing ou de reconstrução, o que permite uma grande flexibilidade na
escolha da placa filha a ser utilizada.
A interface, para as placas filhas da BESDR, possui compatibilidade com as placas
utilizadas pela USRP [23]. Atualmente existe uma variedade de placas filhas compatı́veis
com BESDR, que trabalham com diferentes faixas de frequência e cobrem todo o espectro
livre. Por exemplo:
BasicTX/RX: placas filhas básicas equipadas com conectores SubMiniature version A (SMA)
que realizam interfaces para a conexão de Front-ends não compatı́veis com a BESDR.
TVRX: placa filha de recepção equipada com o Microtune 4937 Cable Modem, opera na
faixa de frequência de 50 M Hz a 800 M Hz, utilizada em aplicações como FM e Very
High Frequency (VHF).
60
5. Implementação e Avaliação da Proposta
RFX1800: placa filha com as cadeias de recepção e transmissão independentes, opera na
faixa de frequência de 1.5 GHz a 2.1 GHz, utilizada em aplicações de telefonia celular.
RFX2400: placa filha com as cadeias de recepção e transmissão independentes, opera na
faixa de frequência de 2.3 GHz a 2.9 GHz, utilizada em aplicações como Wi-Fi.
5.1.2.3
Módulo de controle para BESDR
Para a utilização da placa BESDR são utilizados os blocos de controle e RF Interface
e da arquitetura proposta, estes permitem o controle, configuração, recepção e transmissão
dos dados. O bloco de controle realiza a configuração dos parâmetros dos ADCs, DACs e
das placas filhas, por meio das interfaces seriais (I2C e SPI). Já o bloco RF Interface realiza
a interface paralela com os ADCs e DACs, como também todo o processamento DFE que
permite realizar uma gama de configurações, como por exemplo, a mudança da frequência
central, possibilitando ao sistema a troca de canal instantaneamente.
5.1.3
Interfaceamento da Proposta com GNU Radio
A integração da arquitetura proposta com o GNU Radio é facilitada devido ao UHD,
que é uma API e um conjunto de device drivers para comunicação com as plataformas USRP.
Dessa forma, o suporte para arquitetura proposta foi realizado adicionando ao UHD uma
extensão baseada na implementação da USRP2, que possibilita a comunicação entre o host
e a arquitetura.
Para tornar possı́vel a utilização do GNU Radio decidiu-se por fazer uma especialização do bloco gr-uhd já existente, pois muitas configurações (DDC, filtros, placas filhas)
que são realizadas nas plataformas USRP também são feitas na arquitetura proposta. A implementação atual do GNU Radio fornece uma interface que provê uma camada de abstração
as plataformas USRP, na forma dos blocos source e sink, a esta interface foram adicionadas
classes que implementam os blocos para a arquitetura proposta. Nas classes foram adicionados métodos que permitem configurar o novo comportamento da plataforma, por exemplo,
configurar o roteamento dos dados entre núcleos da NoC e parâmetros dos aceleradores em
hardware.
Na figura 5.5 é possı́vel ver o diagrama de classes simplificado da nova interface proposta estendida da interface original. Um ponto importante a ser salientado é cada vez que
for adicionado um novo acelerador em hardware, também é necessário adicionar métodos
especı́ficos relativos as suas configurações as classes da arquitetura.
5.2. Avaliação da Arquitetura Proposta
61
Figura 5.5: Diagrama de Classes simplificado da interface de abstração da arquitetura com UHD e
GNU Radio.
5.2
Avaliação da Arquitetura Proposta
O experimento de teste criado para a avaliação da arquitetura é a realização da inter-
ceptação de uma comunicação ponto-a-ponto do tipo General Mobile Radio Service (GMRS),
utilizada nas comunicações de rádios Walkie-talkie (figura 5.6a). Este tipo de aplicação é amplamente utilizado em ações militares e de segurança pública, por exemplo, interceptação de
comunicações entre criminosos. Para a realização de uma análise comparativa o cenário de
testes será implementado de duas formas distintas: (1) utilizando a arquitetura GNU Radio e USRP; (2) o protótipo da arquitetura proposta utilizando a BESDR com placas-filhas
TVRX2, kit ML605 e um host rodando GNU Radio com as modificações realizadas.
Com o intuito de criar um ambiente mais próximo do real e também coletar um número
maior de dados para a análise da arquitetura, foi desenvolvido um cenário de testes com
múltiplos canais. Porém, devido a dificuldade de criar um ambiente de experimentação
composto por vários rádios Walkie-talkie se comunicando, utilizou-se uma USRP junto com
o GNU Radio para emular a geração de múltiplos canais como apresentado na figura 5.6b.
A USRP realiza a transmissão de um stream com 8 canais (tabela 5.1) narrowband FM com
12,5 KHz de banda contendo áudios distintos.
5.2.1
Implementação do experimento
Os principais algoritmos utilizados para a implementação do experimento de teste pro-
posto são: (a) spectrum sensing; (b) separação dos canais de interesse; (c) demodulador
62
5. Implementação e Avaliação da Proposta
(a) Testes com canais GMRS
(b) Testes com múltiplos canais utilizando USRP.
Figura 5.6: Ambiente de testes.
Tabela 5.1: Lista dos canais GMRS
Canal
1
2
3
4
5
6
7
8
Frequência (M Hz)
462,550
462,575
462,600
462,625
462,650
462,675
462,700
467,725
5.2. Avaliação da Arquitetura Proposta
63
FM narrowband. A figura 5.7 apresenta um fluxograma do algoritmo de recepção, os blocos
de cor cinza representam as partes que estão sendo executados no hardware, por meio de
aceleradores na arquitetura proposta. O algoritmo pode ser dividido nas seguintes etapas:
1. Recebimento dos dados da janela de interesse e realização de DFE (decimação e filtragem).
2. Análise do espectro para encontrar as portadoras dos canais que estão se comunicando.
3. Separação dos canais encontrados.
4. Demodulação dos canais narrowband FM.
5. Gravação do stream de dados de cada canal em arquivos.
Figura 5.7: Algoritmo de recepção do experimento de teste.
O algoritmo de spectrum sensing, que é amplamente utilizado em aplicações de rádios
cognitivos, é baseado em um detector de energia utilizando uma FFT. De forma básica
funciona aplicando uma FFT de 1024 pontos ao sinal que é recebido após a decimação e
filtragem. Ao resultado no domı́nio da frequência é realizado uma busca para encontrar
frequências que possuem energia superior a 30 dBm permitindo, dessa forma, encontrar
portadoras ativas. Nas frequências ativas encontradas é realizado uma correlação para definir
as frequências minima e máxima (Fmin-Fmax), para então identificar os canais que podem
ser comparados com uma base de dados com canais pré-existentes.
Após determinar os canais ativos é necessário realizar a separação dos mesmos para
a demodulação. A separação dos canais é feita utilizando o algoritmo de DDC, este bloco
recebe a janela de interesse com todos os canais, então realiza a filtragem e translação de
frequência para a banda base de cada canal. Para realizar a separação dos canais são feitas
as configurações de frequência central e a taxa de decimação para os diferentes canais nos
blocos de DDC.
Já a implementação que faz a simulação de múltiplos canais se comunicando, utilizando
a USRP e GNU Radio, é feita modulando com FM narrowband arquivos de áudio do tipo
64
5. Implementação e Avaliação da Proposta
wav com amostragem de 8 KHz, por fim multiplicando cada sinal por um cosseno com a
frequência referente ao seu canal, dessa forma, é feita uma multiplexação de todos os canais
na frequência como é apresentado na figura 5.8.
Figura 5.8: Domı́nio da frequência dos 8 canais transmitidos para a realização dos testes.
5.3
Avaliação dos Resultados
Esta seção apresenta os resultados obtidos através de experimentos realizados e é or-
ganizado de forma a agrupar os aspectos de análise. A performance foi analisada de forma
comparativa, com e sem a arquitetura proposta. Outro aspecto abordado é o consumo dos
recursos da FPGA para a implementação dos testes.
5.3.1
Análise de desempenho
Para auxiliar a avaliação e análise de desempenho dos experimentos foi desenvolvido
o bloco bench graph para o GNU Radio. Esse bloco utiliza o utilitário mpstat do pacote
sysstat do Linux, que apresenta a ocupação de cada processador disponı́vel na máquina ou
a média global do sistema. A porcentagem de uso da CPU é separado pelo mpstat em sete
categorias: user, nice, system, iowait, irq, soft e idle. A duas primeiras categorias (user e nice)
apresentam a porcentagem do uso da CPU em espaço de usuário com aplicações, sendo que
a segunda categoria separa o que é executado com prioridade “nice”. As categorias system,
iowait, irq e soft apresentam métricas relacionadas com a porcentagem do uso da CPU pelo
kernel, requisição de disco, interrupções e interrupções de software, respectivamente. Por fim,
a categoria (idle) apresenta o tempo em que a CPU fica inativa.
Para simplificar a apresentação dos resultados a saı́da do mpstat foi agrupada em três
5.3. Avaliação dos Resultados
65
categorias USR, SYS e IDLE. A USR agrupa as duas primeiras categorias (user e nice)
e representa de forma geral o gasto de CPU pelas implementações dos cenários propostos.
A SYS agrupa os valores do consumo de processamento das tarefas do sistema operacional
(system, iowait, irq e soft). Por fim, o IDLE é o valor direto retirado das medições com mpstat.
Para a análise foi utilizado o valor da média global gerada pelo mpstat, que representa melhor
o consumo dos recursos do sistema por cada implementação.
As medições dos testes propostos foram feitas com intervalos de 2 segundos e os testes
foram executadas com prioridade “tempo real” durante 600 segundos (300 medições por
teste), o que foi suficiente uma vez que as implementações não apresentam grandes oscilações
no processamento dos fluxos de amostra, os quais são constantes durante todo o teste. O host
utilizado para o ambiente de testes foi composto por um PC com processador Intel QuadCore
de 2.83 GHz, com 4GB de RAM e rodando Ubuntu 11.04 com o kernel 2.6.38-15. A placa de
rede gigabit utilizada para interface com a arquitetura proposta foi a Broadcom BCM5755
integrada.
As figuras 5.9a e 5.9b apresentam os resultados da análise de desempenho para o cenário
de testes, utilizando a arquitetura tradicional e a arquitetura proposta respectivamente. As
medições de cada uma das categorias (USR, SYS e IDLE ) foram plotadas levando em consideração o uso dos quatro núcleos do processador utilizado. Como esperado, as implementações
tradicionais mostraram desempenho bastante inferior se comparado à arquitetura proposta.
Isto pode ser observado pela curva USR e SYS que somadas mostram uma ocupação média
maior que 340% na implementação com a arquitetura original, o que torna o computador
praticamente sem responsividade para outras possı́veis tarefas.
A figura 5.10 apresenta as médias de ocupação da CPU no cenário de testes. A ocupação
é dividia em USR e SYS para a implementação com a arquitetura proposta, respectivamente
27% e 10%. E também para implementação tradicional, respectivamente 310% e 33%. A
diminuição de 283% de ocupação da CPU por tarefas em espaço de usuário quando a arquitetura proposta é utilizada mostra um ganho de performance significativo. Além disso,
a diminuição do fluxo de dados, que possuem uma parte tratada diretamente no hardware,
possibilita uma diminuição da ocupação da CPU pelas tarefas do sistema de 23%.
Foram realizadas medições para verificar o desempenho das funções aceleradas em hardware comparando-as com suas implementações no GNU Radio. Para auxiliar nessa tarefa
foram utilizadas as ferramentas oprofile [37] e ChipScope presente no ISE. Oprofile permite
realizar análise dinâmica de programas em execução em ambientes Linux, permitindo realizar
medições do tempo de execução das funções de um programa. A tabela 5.2 apresenta a comparação do tempo médio para a execução de diferentes tamanhos FFTs entre o acelerador
em hardware e a implementação no host. Para o tamanho da janela da FFT utilizada no
experimento de 1024 pontos a implementação em hardware possui um desempenho 28 vezes
maior aproximadamente.
66
5. Implementação e Avaliação da Proposta
(a) Implementação USRP e GNU Radio
(b) Implementação com a arquitetura proposta
Figura 5.9: Ocupação da CPU no cenário de testes
5.3. Avaliação dos Resultados
67
Figura 5.10: Ocupação média da CPU no cenário de testes.
Tabela 5.2: Análise de tempo para diferentes tamanhos de janela de FFT.
Janela FFT
64
128
256
512
1024
2048
4096
FPGA Média (µs)
4.21
6.12
10.98
19.47
34.61
68.34
125.38
Host Média (µs)
937.89
912.25
1170.07
944.58
995.26
1055.14
1171.35
68
5. Implementação e Avaliação da Proposta
A figura 5.11 apresenta uma comparação do número de FFTs por segundo em função
do tamanho da janela para as implementações em hardware e executadas no host. Como
era esperado há um grande ganho de performance o que auxilia diminuir a latência para
implementação de um rádio já que essa operação é utilizada em diversas tecnologias de
comunicações.
Figura 5.11: Número de FFTs por segundo em função do tamanho da janela.
5.3.2
Análise de latência da RTSNoC
Para realizar uma análise de latência do roteador da rede RTSNoC, foram gerados
padrões de tráfegos de pacotes e para uma análise foi utilizada a ferramenta de simulação
presente no ISE.
A figura 5.12 mostra um diagrama de forma de onda da simulação da comunicação entre
os núcleos conectados ao roteador RTSNoC. Nessa comunicação, após o reset do sistema os
núcleos localizados nos canais NN, NE, ES e SS enviam pacotes simultaneamente para o canal
SE. A ordem de prioridade para acessar o mesmo canal é da mais alta para a mais baixa: NN,
NE, SE, SS, SW, NW e WW. Após o reset do sistema os núcleos enviam ao mesmo tempo o
pedido para enviar os pacotes. Os pacotes enviados por cada canal de comunicação são:
• 08811300AAh (canal NN);
• 08891300CCh (canal NE);
• 08911300EEh (canal EE);
5.3. Avaliação dos Resultados
69
• 08A11300FFh (canal SS).
Neste caso, dado o critério de prioridade, o núcleo localizado no canal de NN envia seu
pacote para o canal de SE, como mostrado na figura 5.12 (1). Seguindo a ordem de prioridade,
os outros pacotes são enviados do NE, EE, e terminando com o envio do pacote de SS, como
mostrado na figura 5.12, (2) até (4). A ordem de entrega dos pacotes é confirmado na figura
5.12(5).
Figura 5.12: Diagrama de forma de onda da utilização da RTSNoC.
A latência do roteador RTSNoC pode ser visto na figura 5.12 (6), onde o atraso do
pacote enviado pelo canal NN é dois ciclos de clock. Um ciclo devido o processo de arbitragem
e um segundo ciclo devido ao processo de roteamento, ou seja, a latência para envio de um
pacote é de dois ciclos de clock. Aos pacotes dos canais NE, EE e SS que estão competindo
pelo canal SE é adicionado mais um ciclo para a entrega. Por exemplo, o pacote enviado por
SS tem um ciclo de clock de arbitragem, mais um ciclo de atraso devido o pacote de NN e
mais dois devido os pacotes de NE e EE, por fim, outro devido o envio de seu próprio pacote,
totalizando cinco ciclos de atraso.
Portanto, os limites da latência de um fluxo de pacotes na RTSNoC, pode ser calculado
considerando que o mı́nimo de latência é o dobro do número de roteadores entre a fonte do
pacote até o seu destino, como mostra:
LM IN = NROU ∗ 2,
(5.1)
onde LM IN é o mı́nimo de latência e NROU é o número de roteadores no caminho entre a
70
5. Implementação e Avaliação da Proposta
origem do pacote e o destino do pacote. A latência máxima é determinada adicionando uma
unidade para o maior número de núcleos que podem competir por algum canal de destino em
um determinado instante, para cada roteador no caminho entre a fonte de pacote e o destino
do pacote. A expressão que determina a latência máxima é dada por:
LM AX =
X
(NREQ + 1),
(5.2)
onde LM AX é o máximo de latência e NREQ é o maior número de canais (ou núcleos) que
pode requerer a mesmo canal de comunicação como o destino de sua mensagens ao mesmo
tempo, para cada roteador no caminho entre a fonte do pacote e de destino final.
Outros cenários foram testados utilizando diferentes configurações de tráfego e diferentes topologias de rede usando mais de um roteador. Em todos os casos, a máxima latência
para a rede foi respeitada, independentemente do tráfego ou topologia usada no teste.
5.3.3
Consumo dos Recursos da FPGA
Na tabela 5.3 é apresentado o consumo dos recursos da FPGA Virtex-6 para a im-
plementação do experimento de testes na arquitetura proposta. Os custos são separados em
Slices, Flip-Flops, LUTs e blocos DSP48E1 que possuem multiplicadores em hardware (18x18
Mult).
Tabela 5.3: Consumo de recursos para realização do experimento.
Implementação
RTSNoC
FFT
Filtro FIR
Controle
RF Interface
Separação de canais
Gigabit Ethernet
5.4
Slices
807
4089
1127
1290
2946
8756
1206
FFs
1131
4794
1058
2799
2252
6988
1198
LUTs
429
2461
1578
2585
3285
12526
1526
DSP48E1
*
16
4
*
4
18
*
Considerações Finais
A principal vantagem da arquitetura proposta perante o sistema que utiliza USRP
juntamente com o GNU Radio é a capacidade da migração dos algoritmos DSP executados
no host para o hardware sem a perda da flexibilidade para as implementações de SDR. Isso
diminuiu drasticamente a ocupação do processador de uso geral do sistema (host), uma vez
que o paralelismo intrı́nseco existente na separação de diversos canais, que exige o processamento concomitante do mesmo grupo de dados, e a alta quantidade de amostras por segundo,
proveniente das fases iniciais do rádio, são caracterı́sticas onerosas para implementações em
software e foram beneficiados pela implementação paralela do hardware.
5.4. Considerações Finais
71
A RTSNoC apresenta uma latência máxima de dois ciclos de clock independente das
taxas de dados, diferente de outas implementações de NoC que mostram um comportamento
exponencial de latência com o aumento da taxa de dados [9]. Esse comportamento de uma
latência máxima e a capacidade de rodar a uma frequência superior de 200 M Hz aliado
com a utilização de uma abordagem de granularidade grossa dão a arquitetura uma vazão
suficiente para aplicações SDR.
A área ocupada pela estrutura de comunicação e os blocos da arquitetura não utiliza
muitos recursos das famı́lias de FPGA de alto desempenho, como é o caso do dispositivo
FPGA Virtex-6 utilizado para a prototipação. Porém, para o uso de dispositivos de menor
capacidade o valor consumido torna-se um problema como também a frequência de operação.
72
5. Implementação e Avaliação da Proposta
Capı́tulo 6
Conclusões
Este trabalho trabalho foi desenvolvido na direção de explorar arquiteturas capazes de
atender as demandas de aplicações atuais para SDR, como por exemplo rádios cognitivos.
O trabalho analisou os algoritmos mais utilizados para implementação das camadas fı́sicas
dos rádios e propôs uma arquitetura para SDRs utilizando uma abordagem de granularidade
grossa baseada em aceleradores em hardware para os algoritmos mais utilizados. Como alternativa de interconexão, foi explorado o uso da RTSNoC devido a vantagem desta tecnologia
para a interconexão de múltiplos blocos.
Como pontos positivos da proposta, pode-se considerar a escalabilidade, capacidade de
exploração de paralelismo e uma interface de comunicação bem definida para os blocos. A
arquitetura proposta permitiu o deslocamento das fases com alto consumo de processamento,
que necessitam altas taxas de amostragem, para o hardware reconfigurável. Os testes comparativos entre a implementação tradicional e a arquitetura proposta demonstraram ganhos
significativos no aproveitamento dos recursos do sistema, relacionados mais especificamente
ao desempenho e as interfaces de comunicação. Como contribuição destaca-se também o desenvolvimento da placa BESDR, que realiza um front-end RF para kits de desenvolvimento
FPGA, essa plataforma auxilia no desenvolvimento de futuras arquiteturas para SDR e foi
utilizada para a prototipação da arquitetura proposta.
A maior desvantagem encontrada foi a falta de aceleradores em hardware e a dificuldade
de implementação dos mesmos. No entanto, foi proposto a utilização de uma abordagem de
desenvolvimento de alto nı́vel para FPGAs utilizando as ferramentas System Generator e
Simulink. Outra desvantagem é a necessidade da utilização de um host para configuração,
controle e a implementação das camadas de mais alto nı́vel de um rádio.
74
6. Conclusões
6.1
Trabalhos Futuros
Como perspectivas de trabalhos futuros, no que se refere a arquitetura, as seguintes
atividades podem ser citados:
• Adicionar à arquitetura processadores hardcore de alto desempenho, por exemplo, ARM
Cortex-A8. Esse tipo de processadores já estão disponı́veis nas últimas gerações de
FPGA (Virtex 7), podem trazer vantagens como diminuir problemas de latência, não ter
a necessidade um host externo. Dessa forma, possibilitar a miniaturização do sistema,
diminuir o consumo de energia permitindo a utilização em sistemas embarcados.
• Adicionar à arquitetura co-processadores SIMD como blocos conectados na NoC para
permitir o desenvolvimento de algoritmos DSPs especı́ficos e complexos.
• Criação de uma ferramenta capaz de gerar o HDL para arquitetura a partir de um
repositório de aceleradores, semelhante a ferramenta gnuradio-companion que permite
a geração automática do flowgraph do GNU Radio a partir de seus blocos.
• Desenvolver mais aceleradores a partir de blocos do GNU Radio com abordagens de
descrição de hardware de alto nı́vel como System C.
• Explorar a reconfiguração parcial e dinâmica dos módulos de processamento no FPGA.
Apêndice A
Considerações sobre os aceleradores
da Arquitetura
A.1
Fast Fourier Transform
A Discrete Fourier Transform (DFT) é um algoritmo fundamental para processamento
digital de sinais é utilizada em muitas aplicações, é a representação finita e discreta da
transformada de Fourier. A DFT do sinal discreto X(k), k = 0, . . . , N − 1 de uma sequência
x(n), n = 0, . . . , N − 1 é definida como:
X(k) =
N
−1
X
x(n)e−jnk2π/N
k = 0, . . . , N = 1
(A.1)
n=0
onde N é o tamanho da transformada e j =
√
−1. A transformada inversa (IDFT) é dada
por:
x(k) =
N −1
1 X
X(k)ejnk2π/N
N
n = 0, . . . , N = 1
(A.2)
k=0
O cálculo direto de uma DFT é de alto custo computacional. Um método mais eficiente
para esse cálculo é o algoritmo da Fast Fourier Transform (FFT), o qual reduz drasticamente
o número de operações necessárias para se chegar ao mesmo resultado da DFT. Enquanto
numa DFT de N pontos o número de operações necessárias (adições, subtrações e multiplicações) é proporcional a N 2 , numa FFT esta razão de proporção é reduzida para log2 N .
A arquitetura possui um acelerador que implementa uma FFT de 256 pontos, para
realizar o calculo utiliza o algoritmo padrão Radix-2 Cooley-Tukey (também chamado de
butterfly), ou seja, a FFT de 256 pontos é decomposta em log2 (N ) estágios, e cada estágio
contém uma Radix-2 butterfly, a figura A.1 apresenta o diagrama de um estágio do acelerador.
O bloco também é capaz de calcular a transformada inversa (IFFT).
76
A. Considerações sobre os aceleradores da Arquitetura
Figura A.1: Representação gráfica da FFT.
A.2
Filtro FIR
O filtro Finite Impulse Response (FIR) é um dos blocos básicos mais utilizados em
sistemas DSP, é um tipo de filtro digital caracterizado por uma resposta ao impulso que
torna nula após um tempo finito. A função transferência de um filtro FIR de ordem N é
dada por:
Figura A.2: Representação gráfica do filtro FIR.
Y (n) =
N
X
i=0
k(i)S(n − 1),
(A.3)
A.2. Filtro FIR
77
onde S(n) é o sinal de entrada, Y (n) é o sinal de saı́da, N a ordem do filtro e k(i) são
os coeficientes do filtro que determinam a resposta em frequência do sistema. A figura A.2
mostra que a mesma função pode ser realizada com um grupo de elementos de delay (z −1 )
e multiplicadores, com um delay e um multiplicador para cada tap do filtro seguidos por
uma função de soma. Esse tipo de filtro em geral é implementado em DSPs com instruções
que multiplicam dois operandos e acumulam o resultado (Multiply and Accumulate (MAC))
em um único ciclo de clock. E possı́vel, no entanto, implementá-lo como uma cascata de
operações, o que possibilita uma implementação paralela e mais eficiente [49].
O acelerador da arquitetura implementa um filtro FIR com 64 taps e leva 8 clocks
do FPGA para realizar a operação. Os coeficientes para esse filtro deve ser carregados por
pacotes de configuração enviados pelo bloco de controle.
78
A. Considerações sobre os aceleradores da Arquitetura
Apêndice B
Geração ondas FM narrowband
Existem, essencialmente, dois métodos básicos de geração de ondas FM: direto e indireto
[53]. No método indireto a onda modulante é usado primeiramente para produzir uma onda
FM de banda estreita, e depois uma multiplicação de frequência para a translação para faixa
desejada. Já o no método direto a frequência da portadora é variada diretamente de acordo
com o sinal modulante.
Figura B.1: Diagrama de blocos para modulador FM narrowband.
Neste caso então utilizando o FM indireto considere primeiro a geração de uma onda
FM de banda estreita. Para isso, a expressão de uma onda FM s1 (t) que é escrita na seguinte
forma em função da onda modulante m(t):
s1 (t) = A1 cos(2πf1 t) − A1 sin(2πf1 t)φ1 (t)
Zt
= A1 cos(2πf1 t) − 2πk1 A1 sin(2πf1 t)
m(t)dt
(B.1)
0
onde f1 é a frequência da portadora e A1 é a amplitude da portadora. O argumento angular
φ1 de s1 (t) está relacionado com m(t) onde k1 é a sensibilidade de frequência do modulador.
A equação define uma onda FM narrowband e a partir dela é construı́do o diagrama de blocos
apresentado na figura B.1, o fator de escala 2πf1 é tratado pelo multiplicador modulador.
80
B. Geração ondas FM narrowband
A onda modulada produzida por esse modulador de banda estreita difere de um FM
ideal, pois apresenta modulação em amplitude residual distorção harmônica na frequência
de modulação. Porém, ao restringir o ı́ndice de modulação a β ≤ 0.3rad, os efeitos de AM
residual e PM harmônico são limitados a nı́veis negligenciáveis.
O passo seguinte no método de FM indireto é o de multiplicação na frequência. Basicamente, um multiplicador de frequência consiste num dispositivo não linear seguido por um
filtro passa-banda.
Referências Bibliográficas
[1] FPGA Mezzanine Card (FMC) standard. ANSI, New York, NY, 2008. Approved in
2008, revised in 2010.
[2] B. Ackland, D. Raychaudhuri, M. Bushnell, C. Rose, I. Seskar, T. Sizer, D. Samardzija,
J. Pastalan, A. Siegel, J. Laskar, et al. High performance cognitive radio platform with
integrated physical and network layer capabilities. NSF CNS-0435370, 2005.
[3] R. Andraka. A survey of cordic algorithms for fpga based computers. In Proceedings
of the 1998 ACM/SIGDA sixth international symposium on Field programmable gate
arrays, pages 191–200. ACM, 1998.
[4] O. Anjum, T. Ahonen, F. Garzia, J. Nurmi, C. Brunelli, and H. Berg. State of the
art baseband dsp platforms for software defined radio: A survey. EURASIP Journal on
Wireless Communications and Networking, 2011(1):5, 2011.
[5] P.J. Ashenden. The student’s guide to VHDL. Morgan Kaufmann, 2008.
[6] L. Benini and G. De Micheli. Networks on chips: A new soc paradigm. Computer, 35
(1):70–78, 2002.
[7] L. Benini and G. De Micheli. Networks on chips: Technology and Tools. Morgan Kaufmann, 2006.
[8] E. Bolotin, I. Cidon, R. Ginosar, and A. Kolodny. Qnoc: Qos architecture and design
process for network on chip. Journal of Systems Architecture, 50(2):105–128, 2004.
[9] L. Bononi and N. Concer. Simulation and analysis of network on chip architectures:
ring, spidergon and 2d mesh. In Proceedings of the conference on Design, automation
and test in Europe: Designers’ forum, pages 154–159. European Design and Automation
Association, 2006.
[10] F. Bouwens, M. Berekovic, A. Kanstein, and G. Gaydadjiev. Architectural exploration of
the adres coarse-grained reconfigurable array. Reconfigurable Computing: Architectures,
Tools and Applications, pages 1–13, 2007.
82
REFERÊNCIAS BIBLIOGRÁFICAS
[11] C. Brunelli, F. Cinelli, D. Rossi, and J. Nurmi. A vhdl model and implementation of a
coarse-grain reconfigurable coprocessor for a risc core. In Research in Microelectronics
and Electronics 2006, Ph. D., pages 229–232. IEEE, 2006.
[12] G. Cichon, P. Robelly, H. Seidel, E. Matúš, M. Bronzel, and G. Fettweis. Synchronous
transfer architecture (sta). Computer Systems: Architectures, Modeling, and Simulation,
pages 193–207, 2004.
[13] K. Compton and S. Hauck. Reconfigurable computing: a survey of systems and software.
ACM Computing Surveys (csuR), 34(2):171–210, 2002.
[14] W.J. Dally and B. Towles. Route packets, not wires: On-chip interconnection networks.
In Design Automation Conference, 2001. Proceedings, pages 684–689. IEEE, 2001.
[15] A.D. Datasheet. Mixed-signal front-end (mxfe) processor for broadband communications, 2002.
[16] Laboratório de Integração de Software e Hardware. Board for embedded software-defined
radio, 2012. URL http://www.lisha.ufsc.br/Project+eSDR.
[17] Roberto de Matos, Antônio Augusto Fröhlich, and Leandro Buss Becker. Using Multiple
Channels to Improve SDR Flexibility and Performance. In International Conference on
Computing, Networking and Communications, pages 1031–1035, Maui, U.S.A., January
2012. ISBN 978-1-4673-0009-4.
[18] R. Dhar, G. George, A. Malani, and P. Steenkiste. Supporting integrated mac and phy
software development for the usrp sdr. In Networking Technologies for Software Defined
Radio Networks, 2006. SDR’06.1 st IEEE Workshop on, pages 68–77. IEEE, 2006.
[19] C. Dick and J. Hwang. Fpgas: A platform-based approach to software radios. Software
Defined Radio, pages 235–272, 2004.
[20] C.H. Dick, S. Jose, and H.M. Pedersen. Design and implementation of high-performance
fpga signal processing datapaths for software defined radios. In Embedded Systems Conference, pages 1–16, 2001.
[21] G. Eichinger, M. Leeser, and K. Chowdhury. An fpga spectrum sensing accelerator for
cognitive radio. 2011.
[22] Blossom
Eric.
Exploring
gnu
radio,
2012.
URL
http://www.gnu.org/software/gnuradio/doc/exploring-gnuradio.html.
[23] M. Ettus. Universal software radio peripheral. Ettus Research, Mountain View, CA,
2009.
[24] J. Gao. 10 100 1000 mbps tri-mode ethernet mac specification, 2006.
REFERÊNCIAS BIBLIOGRÁFICAS
83
[25] F. Garzia, C. Brunelli, C. Giliberto, and J. Nurmi. Implementation of w-cdma cell search
on a runtime reconfigurable coarse-grain array. In EUROCON 2009, EUROCON’09.
IEEE, pages 411–415. IEEE, 2009.
[26] K. Goossens, J. Dielissen, and A. Radulescu. Æthereal network on chip: concepts,
architectures, and implementations. Design & Test of Computers, IEEE, 22(5):414–421,
2005.
[27] P. Guerrier and A. Greiner. A generic architecture for on-chip packet-switched interconnections. In Proceedings of the conference on Design, automation and test in Europe,
pages 250–256. ACM, 2000.
[28] M.L.H.U. Guide. 1. overview. ML605 Hardware User Guide, 2009.
[29] D. Haessig, J. Hwang, S. Gallagher, and M. Uhm. Case-study of a xilinx system generator
design flow for rapid development of sdr waveforms. In SDR technical conference, pages
14–18, 2005.
[30] S. Hauck and A. DeHon. Reconfigurable computing: the theory and practice of FPGAbased computation. Morgan Kaufmann Pub, 2008.
[31] S. Haykin. Sistemas de Comunicação-Analógicos e Digitais. Artmed, 2004.
[32] J. Hwang, B. Milne, N. Shirazi, and J. Stroomer. System level tools for fpgas. Proceedings
FPL 2001, 2001.
[33] F. Karim, A. Nguyen, and S. Dey. An interconnect architecture for networking systems
on chips. Micro, IEEE, 22(5):36–45, 2002.
[34] P.B. Kenington. RF and baseband techniques for software defined radio. Artech House,
2005.
[35] S. Kumar, A. Jantsch, J.P. Soininen, M. Forsell, M. Millberg, J. Oberg, K. Tiensyrja,
and A. Hemani. A network on chip architecture and design methodology. In VLSI, 2002.
Proceedings. IEEE Computer Society Annual Symposium on, pages 105–112. IEEE, 2002.
[36] B.P. Lathi. Sinais e sistemas lineares. Bookman, 2007.
[37] J. Levon. Oprofile manual. Victoria University of Manchester, 2004.
[38] T. Limberg, M. Winter, M. Bimberg, R. Klemm, MBS Tavares, H. Ahlendorf, E. Matúš,
G. Fettweis, H. Eisenreich, G. Ellguth, et al. A heterogeneous mpsoc with hardware
supported dynamic task scheduling for software defined radio. In Design Automation
Conference (DAC’09). Citeseer, 2009.
[39] D. Liu. Embedded DSP processor design: application specific instruction set processors,
volume 2. Morgan Kaufmann, 2008.
84
REFERÊNCIAS BIBLIOGRÁFICAS
[40] D. Liu, A. Nilsson, E. Tell, D. Wu, and J. Eilert. Bridging dream and reality: programmable baseband processors for software-defined radio. Communications Magazine,
IEEE, 47(9):134–140, 2009.
[41] M. Löhning, T. Hentschel, and G. Fettweis. Digital down conversion in software radio
terminals. In Proceedings of the 10. European Signal Processing Conference (EUSIPCO,
volume 3, pages 1517–1520. Citeseer, 2000.
[42] R.G. Lyons. Understanding digital signal processing. Prentice Hall PTR, 2004.
[43] R. Matos. Uma arquitetura de canais para rádios definidos por software de múltiplas
camadas. 2010.
[44] C. Maxfield. The Design warrior’s guide to FPGAs: Devices, tools and flows, volume 1.
Elsevier, 2004.
[45] J. Mitola. The software radio architecture. Communications Magazine, IEEE, 33(5):
26–38, 1995.
[46] J. Mitola. Software radio architecture. Wiley Online Library, 2000.
[47] J. Mitola III. Software radios: Survey, critical evaluation and future directions. Aerospace
and Electronic Systems Magazine, IEEE, 8(4):25–36, 1993.
[48] J.
Mitola
III.
What
is
a
software
defined
radio?,
2012.
URL
http://gnu.feld-it.at/software/gnuradio/gnuradio.html.
[49] S.K. Mitra and Y. Kuo. Digital signal processing: a computer-based approach, volume 2.
McGraw-Hill New York, 2006.
[50] F. Moraes, N. Calazans, A. Mello, L. Moller, and L. Ost. Hermes: an infrastructure for
low area overhead packet-switching networks on chip. Integration, the VLSI Journal, 38
(1):69–93, 2004.
[51] T.R. Muck. Uma arquitetura para implementação de sdrs em sistemas embarcados.
2009.
[52] A. Müller. Dab software receiver implementation. Swiss Federal Institute of Technology
Zurich, 2008.
[53] V.S. Neto. Telecomunicações: sistemas de modulação. Érica, 2005.
[54] A. Niktash, H.T. Parizi, and N. Bagherzadeh. Application of a heterogeneous reconfigurable architecture to ofdm wireless systems. In Circuits and Systems, 2007. ISCAS
2007. IEEE International Symposium on, pages 2586–2589. IEEE, 2007.
[55] J. Nurmi. Processor design: system-on-chip computing for ASICs and FPGAs. Springer
Verlag, 2007.
REFERÊNCIAS BIBLIOGRÁFICAS
85
[56] G. Nychis, T. Hottelier, Z. Yang, S. Seshan, and P. Steenkiste. Enabling mac protocol implementations on software-defined radios. In Proceedings of the 6th USENIX
symposium on Networked systems design and implementation, pages 91–105. USENIX
Association, 2009.
[57] O. Paker, K. van Berkel, and K. Moerman. Hardware and software implementations of
an mmse equalizer for mimo-ofdm based wlan. In Signal Processing Systems Design and
Implementation, 2005. IEEE Workshop on, pages 1–6. IEEE, 2005.
[58] P.P. Pande, C. Grecu, A. Ivanov, and R. Saleh. Design of a switch for network on
chip applications. In Circuits and Systems, 2003. ISCAS’03. Proceedings of the 2003
International Symposium on, volume 5, pages V–217. IEEE, 2003.
[59] H. Park, K. Fan, M. Kudlur, and S. Mahlke. Modulo graph embedding: mapping
applications onto coarse-grained reconfigurable architectures. In Proceedings of the 2006
international conference on Compilers, architecture and synthesis for embedded systems,
pages 136–146. ACM, 2006.
[60] S. Pasricha and N. Dutt. On-chip communication architectures: system on chip interconnect. Morgan Kaufmann, 2008.
[61] S.M. Pereira. Standardizing digital if data transfer with vita 49. RTC Magazine, 2006.
[62] GNU FSF Projec. The gnu radio, 2012. URL http://gnuradio.org.
[63] U. Ramacher. Software-defined radio prospects for multistandard mobile phones. Computer, 40(10):62–69, 2007.
[64] J.H. Reed. Software radio: a modern approach to radio engineering. Prentice Hall
Professional, 2002.
[65] R. Schena. Desenvolvimento de um digital down converter (ddc) para um protótipo
embarcado de rádio definido por software. 2007.
[66] M. Schwartz. Information transmission, modulation and noise. a unified approach to
communication systems. New York: McGraw-Hill, 1970, 1, 1970.
[67] M.C. Smith and G.D. Peterson. Programming high performance reconfigurable computers. SPIE ITCon Reconfigurable Technology: FPGAs and Reconfigurable Processors for
Computing and Communications, 2001.
[68] V. Surducan, M. Moudgill, G. Nacer, E. Surducan, P. Balzola, J. Glossner, S. Stanley,
M. Yu, D. Iancu, et al. The sandblaster software-defined radio platform for mobile
4g wireless communications. International Journal of Digital Multimedia Broadcasting,
2009, 2009.
86
REFERÊNCIAS BIBLIOGRÁFICAS
[69] D.L. Tennenhouse and V.G. Bose. Spectrumware: a software-oriented approach to wireless signal processing. In Proceedings of the 1st annual international conference on Mobile
computing and networking, pages 37–47. ACM, 1995.
[70] T.J. Todman, G.A. Constantinides, S.J.E. Wilton, O. Mencer, W. Luk, and P.Y.K.
Cheung. Reconfigurable computing: architectures and design methods. In Computers
and Digital Techniques, IEE Proceedings-, volume 152, pages 193–207. Iet, 2005.
[71] W.H.W. Tuttlebee. Software defined radio: origins, drivers, and international perspectives. Wiley, 2002.
[72] M. Woh, Y. Lin, S. Seo, S. Mahlke, T. Mudge, C. Chakrabarti, R. Bruce, D. Kershaw,
A. Reid, M. Wilder, et al. From soda to scotch: The evolution of a wireless baseband
processor. In Microarchitecture, 2008. MICRO-41. 2008 41st IEEE/ACM International
Symposium on, pages 152–163. Ieee, 2008.
[73] V.I.I. Xilinx. Platform fpgas: Complete data sheet. DS031 (v3. 4), March, 2005.
[74] C.A. Zeferino and A.A. Susin. Socin: a parametric and scalable network-on-chip. In Integrated Circuits and Systems Design, 2003. SBCCI 2003. Proceedings. 16th Symposium
on, pages 169–174. IEEE, 2003.