Embed Size (px)
Citation preview
UNIVERSIDADE FEDERAL DA BAHIA
ESCOLA POLITÉCNICA DA UFBA
PROGRAMA DE PÓS-GRADUAÇÃO EM
ENGENHARIA ELÉTRICA
DEPARTAMENTO DE ENGENHARIA ELÉTRICA
PROJETO DE UM SISTEMA DE CORREÇÃO DE
ERROS EM COMUNICAÇÃO MÓVEL USADO NO
PADRÃO LTE
Autor
Ilan Schnitman Souza
Orientadora
Ana Isabela de Araújo Cunha
SALVADOR
2013
UNIVERSIDADE FEDERAL DA BAHIA
ESCOLA POLITÉCNICA DA UFBA
PROGRAMA DE PÓS-GRADUAÇÃO EM
ENGENHARIA ELÉTRICA
DEPARTAMENTO DE ENGENHARIA ELÉTRICA
PROJETO DE UM SISTEMA DE CORREÇÃO DE
ERROS EM COMUNICAÇÃO MÓVEL USADO NO
PADRÃO LTE
Autor: Ilan Schnitman Souza
Orientadora: Prof. Dra. Ana Isabela de Araújo Cunha
Dissertação elaborada pelo acadêmico Ilan
Schnitman Souza, como parte das exigências
para conclusão do curso de pós-graduação
stricto-senso em Engenharia Elétrica da
Universidade Federal da Bahia, sob a
orientação da professora Dra. Ana Isabela de
Araújo Cunha
SALVADOR
2013
S729 Souza, Ilan Schnitman.
Projeto de um sistema de correção de erros em comunicação móvel usado no padrão LTE / Ilan Schnitman
Souza. – Salvador, 2013.
72f. : il. color.
Orientadora: Profa. Dra. Ana Isabela de Araújo de Cunha.
Dissertação (mestrado) – Universidade Federal da Bahia. Escola Politécnica, 2013.
1. Circuitos integrados. 2. Comunicações digitais. 3. Erro -
correção I. Cunha, Ana Isabela de Araújo. II. Universidade
Federal da Bahia. III. Título.
CDD: 621.381
UNIVERSIDADE FEDERAL DA BAHIA
ESCOLA POLITÉCNICA DA UFBA
PROGRAMA DE PÓS-GRADUAÇÃO EM
ENGENHARIA ELÉTRICA
DEPARTAMENTO DE ENGENHARIA ELÉTRICA
PROJETO DE UM SISTEMA DE CORREÇÃO DE
ERROS EM COMUNICAÇÃO MÓVEL USADO NO
PADRÃO LTE
Autor: Ilan Schnitman Souza
Orientadora: Prof. Dra. Ana Isabela de Araújo Cunha
Banca Examinadora
____________________________________________
Profa. Dra. Ana Isabela de Araújo Cunha
____________________________________________
Prof. Dr. Antônio Cezar de Castro Lima
____________________________________________
Prof. Dr. Paulo César Machado de Abreu Farias
____________________________________________
Prof. Dr. José Luís Almada Güntzel
EPÍGRAFE
“A moment of convenience, a lifetime of regret”
David Moon
DEDICATÓRIA
A todos os que me ajudaram
AGRADECIMENTOS
À professora Ana Isabela por aceitar me guiar neste desafio.
A Vinícius Torres dos Reis que dividiu a tarefa da realização deste projeto.
Ao LSI-TEC pelo apoio e por permitir a publicação deste trabalho.
A todos os que participaram direta ou indiretamente para que este trabalho fosse
realizado.
SUMÁRIO
LISTA DE ILUSTRAÇÕES ................................................................................................... i
LISTA DE TABELAS ........................................................................................................ iii
LISTA DE ABREVIATURAS .............................................................................................. iv
RESUMO ...................................................................................................................... vi
ABSTRACT .................................................................................................................... vii
1. INTRODUÇÃO ....................................................................................................... 1
2. CORREÇÃO DE ERROS ........................................................................................... 5
2.1. PERSPECTIVA HISTÓRICA .................................................................................. 5
2.2. ALGORITMOS E OTIMIZAÇÕES DO TURBO-CODE .............................................. 18
2.2.1. Algoritmo Log-MAP ........................................................................................ 19
2.2.2. Decodificação em Paralelo .............................................................................. 21
2.2.3. Interleaver ..................................................................................................... 23
3. ARQUITETURA PROPOSTA E IMPLEMENTAÇÃO ................................................... 25
3.1. FLUXO DE PROJETO DIGITAL............................................................................ 25
3.2. APRESENTAÇÃO DA ARQUITETURA ................................................................. 31
3.3. IMPLEMENTAÇÃO ........................................................................................... 47
4. DISCUSSÃO DOS RESULTADOS ............................................................................ 60
4.1. ESTUDO COMPARATIVO ................................................................................. 63
5. CONCLUSÃO ....................................................................................................... 67
5.1. PROPOSTA DE TRABALHOS FUTUROS .............................................................. 68
6. REFERÊNCIAS BIBLIOGRÁFICAS ........................................................................... 69
i
LISTA DE ILUSTRAÇÕES
Figura 1: Codificador Convolucional ................................................................................................................. 7
Figura 2: Representação do Gráfico em Treliça Relativo ao Codificador Convolucional da Figura 1............. 8
Figura 3: Exemplo de Treliça ........................................................................................................................... 10
Figura 4: Forward Recursion ........................................................................................................................... 11
Figura 5: Backward Recursion ......................................................................................................................... 11
Figura 6: Probabilidade de Transição ............................................................................................................. 12
Figura 7: Codificador Non-Systematic Convolutional ..................................................................................... 14
Figura 8: Codificador Recursive Systematic Convolutional ............................................................................. 14
Figura 9: Estrutura Simplificada do codificador Turbo-Code ......................................................................... 18
Figura 10: Estrutura Simplificada do Decodificador Turbo-Code ................................................................... 18
Figura 12: Comparação Sliding Window com Paralelismo ............................................................................. 22
Figura 11: Operações com o Uso de Sliding Window ...................................................................................... 22
Figura 13: Representação em Alto Nível do Fluxo de Projeto ......................................................................... 26
Figura 14: Detalhamento das Etapas de Front-End ......................................................................................... 27
Figura 15: Detalhamento das Etapas de Back-End .......................................................................................... 27
Figura 16: Codificador Especificado para o Padrão LTE ............................................................................... 31
Figura 17: Demonstração das Etapas de Decodificação ................................................................................. 36
Figura 18: Início da Treliça do Codificador do Padrão LTE ........................................................................... 36
Figura 19: Transições Intermediárias da Treliça do Padrão LTE ................................................................... 36
Figura 20: Geração dos Tail Bits ..................................................................................................................... 37
Figura 21: Arquitetura de Hardware do Cálculo da Probabilidade de Transição .......................................... 38
Figura 22: Arquitetura da SISO ........................................................................................................................ 38
Figura 23: Arquitetura de Hardware das Probabilidades de Estados ............................................................. 39
Figura 24: Cálculo da LLR ............................................................................................................................... 41
Figura 25: Cálculo da Informação Extrínseca ................................................................................................. 41
Figura 26: Arquitetura do Decodificador ......................................................................................................... 42
Figura 27: Máquina de Estados da Operação de Decodificação ..................................................................... 43
Figura 28: Alimentação dos Dados em uma Arquitetura com 4 SISOs ............................................................ 46
Figura 29: Separação dos Blocos a serem Processados .................................................................................. 47
Figura 30: Representação do Ambiente de Simulação do Sistema ................................................................... 48
Figura 31: Diagrama de Constelação dos Esquemas de Modulação ............................................................... 49
Figura 32: Resultado do FER (ou BLER) vs SNR ............................................................................................. 50
Figura 33: Arquitetura do Interleaver .............................................................................................................. 51
Figura 34: Representação das Interfaces do Bloco do Decodificador ............................................................. 53
Figura 35: Ambiente de Verificação SystemVerilog ......................................................................................... 54
Figura 36: Ambiente de Simulação Bitmatching .............................................................................................. 56
Figura 37: Floorplanning ................................................................................................................................. 57
Figura 38: Leiaute do decodificador ................................................................................................................ 57
Figura 39: Desempenho do Sistema Comparando por Tamanho de Blocos ................................................... 61
ii
Figura 40: Desempenho do Sistema Comparando os Resultados com Diferentes Valores de Iteração ........... 63
iii
LISTA DE TABELAS
Tabela 1: Parâmetros do Interleaver ................................................................................................................ 33
Tabela 2: Relação entre o Tamanho do Bloco de Dados e a Quantidade de Processadores Utilizados na
Decodificação .......................................................................................................................................................... 47
Tabela 3: Parâmetros para a Simulação Variando o Tamanho do Bloco de Processamento .......................... 61
Tabela 4: Parâmetros para a Simulação Variando o Esquema de Modulação ................................................ 62
Tabela 5: Parâmetros para a Simulação Variando o Número de Iterações ..................................................... 62
Tabela 6: Tabela Comparativa entre o Decodificador Proposto e Congêneres ............................................... 64
iv
LISTA DE ABREVIATURAS
16QAM - 16 Quadrature Amplitude Mudulation
64QAM - 64 Quadrature Amplitude Modulation
APP - A-Posteriori Probability
ARP - Almost Regular Permutation
ASIC - Application Specific Integrated Circuit
AT&T - American Telephone and Telegraph
BER - Bit Error Rate
BFM - Bus Functional Mode
BPSK - Binary Phase-Shift Keying
CI - Circuito Integrado
CMOS - Complementary Metal-Oxide-Semiconductor
DH - Design House
DUT - Device Under Test
EDA - Electronic Design Automation
ESF - Extrinsic Scaling Factor
FER - Frame Error Rate
FIFO - First-In First-Out
GSM - Global System for Mobile Communications
HDL - Hardware Description Language
IP - Internet Protocol
IP - Intellectual Property
LDPC - Low Density Parity Check
LLR - LOG Likelihood Ratio
Log-MAP - Logarithm MAP
LTE - Long Term Evolution
LUT - Look-Up Table
MAP - Maximum A-Posteriori
Max-Log-
MAMAP
- Maximum Logarithm MAP
MCT - Ministério da Ciência e Tecnologia
MIMO - Multiple-Input Multiple-Output
Musti-Vt - Multiple Voltage Threshold
NSC - Non-Systematic Convolutional
PLL - Phase Locked Loop
PVT - Process, Voltage and Temperature
QPP - Quadratic Permutation Polynomial
QPSK - Quadrature Phase-Shift Keying
RSC - Recusive Systematic Convolutional
RTL - Register Transfer Level
SDC - Synopsys Design Constraints
SISO - Soft-Input Soft-Output
SMS - Short Message Service
SoC - System On Chip
SOVA - Soft-Output Viterbi Algorithm
TSMC - Taiwan Semiconductor Manufacturing Company
VHDL - Very High Speed Integrated Circuit HDL
VLSI - Very Large Scale Integration
v
VLSI - Very Large Scale Integration
WCDMA - Wideband Code Division Multiple Access
vi
RESUMO
O presente trabalho propõe uma nova arquitetura para o sistema turbo-code de correções de
erro usado no padrão de comunicação móvel LTE (Long Term Evolution). Será estudada a
codificação de canal e o contexto do surgimento do turbo-code, contextualizando este
trabalho e dando uma visão da área das comunicações móveis abordados no trabalho.
Como o projeto foi proposto para tecnologia de semicondutores, será descrita uma breve
introdução à metodologia utilizada, detalhando os passos seguidos no projeto e a construção
da arquitetura. Serão reportadas e justificadas as decisões tomadas para a otimização do
hardware.
Foram utilizadas diversas técnicas de otimização de harware, como o processamento em
paralelo e a utilização do algorítmo de processamento Log-MAP. As técnicas são descritas
detalhadamente e suas vantagens e desvantagens são apresentadas, assim como são
justificadas as escolhas de projeto.
Os resultados medidos e estimados serão apresentados, mostrando então a prioridade
empregada para alguns parâmetros em detrimento de outros, sendo assim explicadas as
diferenças entre o desempenho da arquitetura proposta e de outras soluções descritas na
literatura.
No projeto foi desenvolvida uma arquitetura visando uma alta confiabilidade de correção de
erros. É neste aspecto que este trabalho se destaca dos demais relatados na literatura atual.
Porém, diversos outros aspectos foram levados em consideração como a latência, o
throughput, area de silício e consumo de potência os quais são impactados pela frequência
de operação e a tecnologia para o qual foi projetado. Os resultados foram bastante
satisfatórios comparativamente, em se ponderar o desempenho em função da correção de
erros.
vii
ABSTRACT
This work proposes a new turbo-code system architecture for error correction used in LTE
(Long Term Evolution) mobile communication standard. Channel coding will be studied
and the turbo-code creation context, giving the foundation of this work and giving an
overview of the mobile communications area of the project.
As the project intended to be implemented in a semiconductor technology, a brief overview
of the methodology will be presented detailing the steps in this project and the conception
of the architecture. The decisions to optimize the hardware will be reported and explained.
During project design, several hardware optimization techniques were used as parallel
processing and Log-MAP algorithm. The techniques will be detailled described and their
advatages ans disadvantages will be presented. The design choices will be explained.
The measured and estimated results will be presented, showing the priority given to certain
parameters over others, explaining performance differences between the architecture and
other solutions found in the literature.
The architecture designed aims high reliability in error correction. This is the aspect that
distighish this work from othes described in current bibliography. However several other
aspects were considered, as latency, throughput, silicon area and power consuption which
are consequencies of the operation frequency and technology. The results were similar to
other architectures specially considering the error correction performance.
1
1. INTRODUÇÃO
O desenvolvimento das tecnologias de comunicação está intimamente relacionado com
os avanços da microeletrônica. Devido à popularização das comunicações móveis e dos
sistemas computacionais o mercado de semicondutores movimenta uma quantidade de recursos
enorme, chegando a US$180 bilhões de dólares ainda no período de 1999-2000 [7].
Desde a década de 1940 os primeiros dispositivos de comunicação móveis foram
criados pela Bells Labs [3] e em 1946 começaram a ser homologados pela Comissão Federal de
Comunicações dos Estados Unidos da América, passando a ser operados pela American
Telephone and Telegraph (AT&T) [1]. O alto consumo de potência restringia a utilização
desses aparelhos, porém a configuração da rede de comunicação criada foi determinante para a
criação de um sistema divido em células com reutilização de frequências [1]. Devido ao alto
custo e baixa capacidade em número de usuários, esses sistemas ficaram restritos a poucos
equipamentos, tendo uso praticamente em dispositivos limitado a instalações em carros [3].
A partir da década de 1980 os sistemas de comunicação móveis começaram a ficar
disponíveis comercialmente em larga escala [3]. Nos primeiros padrões desenvolvidos, também
conhecidos como de primeira geração (1G), os sistemas ainda eram analógicos e proviam
serviços de voz apenas [1]. Porém, os dispositivos ainda consumiam muita potência, eram
caros, tinham baixa capacidade e o serviço ainda não era confiável [1].
Com os avanços das tecnologias e das teorias de comunicação digital, criaram-se a
partir do início da década de 1990 os sistemas de segunda geração (2G), sendo o Global System
for Mobile Communications (GSM) o mais popular e bem sucedido desses [2]. A capacidade já
permitia a inclusão de alguns novos recursos, como o serviço de mensagens curtas (SMS). A
própria evolução desses padrões elevou a capacidade original de forma a já permitir recursos
mais avançados, como o acesso à internet.
A partir da popularização das comunicações móveis em paralelo com o
desenvolvimento da internet, começou a existir uma demanda crescente por sistemas com
maior capacidade de transferência de dados. Muitos dos avanços tecnológicos vistos nas duas
últimas décadas se devem ao avanço das tecnologias aplicadas aos dispositivos semicondutores.
A partir dos anos 2000 os sistemas de terceira geração (3G) foram inseridos no mercado
[2] perdurando até os dias atuais. Essa tecnologia permite uma maior taxa de transmissão de
dados, o que é fundamental para suprir as necessidades de comunicação e acesso à informação
dos consumidores. Porém, os limites impostos são consideráveis com o avanço do número de
usuários e da taxa de transmissão de dados.
2
O sistema Long Term Evolution (LTE) surgiu para tentar vencer os desafios associados
aos 2G e 3G, criando todo um novo ambiente para o desenvolvimento das comunicações
móveis, sem que haja a necessidade de compatibilidade [1]. Uma das características mais
interessantes é a de o sistema ser projetado primordialmente para suportar transferência de
dados via Internet Protocol (IP), inclusive os serviços de voz.
O LTE teve como motivação, além do aumento da taxa de transferência o melhor
aproveitamento espectral, já que pode enviar mais dados em uma mesma faixa de frequência.
Essa característica é importante para o provedor dos serviços já que irá permitir que, para uma
mesma faixa licenciada, mais usuários possam ser atendidos com melhor qualidade.
Outra vantagem dos sistemas LTE é a menor latência associada à comunicação, ou seja,
o tempo de resposta do sistema. Para determinadas operações essa característica é fundamental.
Um exemplo é a utilização de voz sobre IP (VoIP) que se torna bastante comprometido ao se
optar por uma rede 3G, sendo no LTE a solução natural para o serviço de voz.
É importante lembrar que apesar de estar sendo popularmente denominada uma
tecnologia de quarta geração (4G), o LTE não atinge originalmente os requisitos para ser
enquadrado nessa categoria.
Para atingir o máximo da capacidade do canal é necessária a utilização de esquemas de
codificação de dados. Um dos mais bem sucedidos codificadores é o Turbo-Code, sendo o
principal codificador do LTE.
O Turbo-Code é um dos principais blocos do projeto da camada física do LTE, como
observado em [3]:
“A codificação de canal, e particularmente o decodificador de canal manteve a
reputação de ser a fonte dominante de complexidade de implementação das
comunicações sem fios, apesar do relativamente recente predomínio das técnicas
avançadas de antena com suas complexidades associadas.”
A teoria de comunicações determinou um limite teórico para as taxas de transmissão de
dados. Para um melhor aproveitamento os sistemas devem transmitir à maior taxa possível. O
limite da capacidade de um canal foi determinado por Claude Shannon, em 1948 [39], como
expresso na equação (1):
.
/ (1)
onde C é a capacidade de transferência de dados do canal, B é a largura de banda e S/N é a
relação sinal ruído.
Um sistema de correção de erros pode aproximar as taxas de transmissão desse limite
teórico. De fato, ao se utilizar uma codificação complexa o bastante esse limite poderia ser
atingido, porém isso traria uma enorme dificuldade de implementação.
3
Diversos esquemas de codificação foram propostos desde os estudos de Hamming sobre
o desempenho dos sistemas de detecção e correção de erros no combate aos efeitos negativos
do ruído introduzido pelo canal.
No início da década de 1990 foi idealizado o algoritmo do turbo-code [17] atingindo
uma taxa de transferência próxima ao limite de Shannon. Com o avanço das tecnologias esse
esquema de codificação se tornou viável, sendo crescente a sua utilização em sistemas de
comunicação modernos. O padrão LTE não foge a essa tendência, adotando o turbo-code como
o principal codificador de canal.
Este trabalho propõe uma nova arquitetura para o Turbo-Code especificado no sistema
LTE [18], sendo seu desempenho adequado aos requisitos definidos no padrão, com alguns
parâmetros de projeto superiores aos encontrados em trabalhos anteriores.
O codificador, como determinado no padrão do LTE, é bastante simples. Porém, o
decodificador não é especificado, dando flexibilidade de implementação. O objetivo principal
desse trabalho é apresentar a arquitetura de um processador dedicado, em tecnologia de
circuitos integrados para o decodificador e demonstrar o desempenho atingido pela arquitetura
proposta.
Como objetivos específicos este trabalho pretende:
a. Revisar a teoria de codificação com ênfase no Turbo-Code;
b. Revisar o fluxo de projeto digital e justificar o uso desta tecnologia para a realização do
Turbo-Code;
c. Desenvolver uma nova arquitetura de decodificação Turbo-Code, como parte integrante
do projeto da camada física de um sistema LTE em uma tecnologia de circuitos
integrados, passando por todas as etapas desde a modelagem e descrição até a geração
do leiaute final. Desta forma, objetiva-se criar toda a estrutura de um IP (Intelectual
Property) completo, ou seja, um bloco com boas possibilidades de reúso em outros
projetos;
d. Demonstrar a eficiência da solução desenvolvida, comparando-a a outros projetos
encontrados na bibliografia. Explicar os parâmetros das comparações e como isto afeta
o projeto;
e. Desenvolver um artigo científico para publicação em congresso internacional na área de
microeletrônica, tendo como parâmetro o SBCCI (Symposium on Integrated Circuits
and Systems Design)
4
A metodologia para a determinação da eficiência do decodificador é importante para
definição do sucesso deste projeto. Assim, para uma análise sobre a eficiência da arquitetura
desenvolvida foram extraídos ou simulados os diversos parâmetros de desempenho e algumas
comparações foram realizadas. Na época do desenvolvimento do projeto poucos artigos haviam
sido publicados diretamente relacionados com o projeto do turbo-code voltado para a
tecnologia LTE, o que acarretou na importância da publicação de um artigo relacionado.
Um artigo científico foi desenvolvido e publicado no 24º SBCCI [8], em 2011, estando
entre os melhores do congresso, gerando um convite para a publicação de uma versão estendida
na revista relacionada ao congresso. Consequentemente um novo artigo foi desenvolvido e
devidamente publicado na JICS (Journal of Integrated Circuit and Systems), em 2012 [37].
Durante o desenvolvimento alguns blocos correlatos da camada física do LTE foram
estudados para se ter uma melhor ideia das restrições e do desempenho exigido. A informação
mais imediata é relacionada ao throughput do sistema. Esse parâmetro é a quantidade de
informação processada em um período de tempo e está diretamente relacionada com as taxas de
transmissão de dados especificados no padrão.
A capacidade de correção de erros é fundamental para que se tenha um sistema
confiável e bem projetado. O desempenho pode ser medido através da simulação do modelo e
da verificação do projeto. Inicialmente foram especificadas as tolerâncias a erros para cada
esquema de modulação e buscou-se o hardware mais otimizado para atender a esses valores.
Pode-se notar que há um compromisso entre o desempenho e os resultados obtidos após a
implementação. Esse tipo de escolha é bastante comum em projetos de ASIC e envolve outros
parâmetros como área, potência e frequência de operação.
Para demonstrar o trabalho proposto esta dissertação será dividida em mais quatro
capítulos. Inicialmente, haverá uma descrição da codificação de canal, chegando até o turbo-
code e sua versão para o LTE. No capítulo seguinte será apresentada a arquitetura proposta, sua
implementação em hardware. Posteriormente, serão apresentados os resultados de desempenho
atingidos pela arquitetura, comparando-os com outros trabalhos relevantes. Finalmente, no
último capítulo será feita a conclusão e observações finais sobre este trabalho.
5
2. CORREÇÃO DE ERROS
Desde que Shannon estabeleceu os limites da capacidade do canal, vários estudos foram
realizados objetivando sistemas de comunicação mais eficientes. Segundo descrito em [5]
existem quatro requisitos básicos que podem ser otimizados ao se utilizar um sistema de
codificação em detrimento da necessidade de utilização de uma maior largura de banda:
- Desempenho com relação aos erros
- Potência
- Taxa de transferência de dados
- Capacidade
Nos sistemas de comunicação atuais os ganhos referentes aos quatro requisitos listados são
superiores à perda de desempenho associada a uma maior utilização da banda de transmissão.
O desempenho com relação aos erros é o requisito mais evidente, já que um esquema de
codificação irá necessariamente entregar os dados a uma taxa de erros menor do que um
sistema não codificado com uma mesma relação entre o sinal e o ruído do canal. Os sistemas de
detecção e correção de erros inserem informações redundantes, assim necessitando de uma
maior banda de transmissão para alocar as informações sobressalentes.
O requisito da potência é bastante interessante, pois se relaciona diretamente com o limite
da capacidade do canal. Uma forma de se aumentar esse limite é realizar a transmissão a uma
maior potência, assim melhorando a relação sinal/ruído. Contudo, essa não é uma boa
estratégia, especialmente em se tratando de dispositivos móveis, dependentes de uma fonte
bastante limitada de energia. Portanto, é mais eficiente inserir informações redundantes, o que
permite um desempenho semelhante ao aumento da potência, porém implicando em um menor
consumo.
A capacidade de transmissão está intimamente ligada ao aumento da taxa de transmissão.
Essa, por sua vez, também pode ser vista como uma expansão da relação sinal/ruído já que
estes fatores estão relacionados de uma forma inversamente proporcional. Portanto, um
codificador permite uma relação sinal ruído menor, gerando uma taxa de transmissão maior.
1.1. PERSPECTIVA HISTÓRICA
O telégrafo é considerado o primeiro sistema de comunicação elétrico. Inventado em 1837
por Samuel Morse, curiosamente utilizava um esquema digital de transmissão de dados em que
as letras do alfabeto eram codificadas em pulsos e pausas, o famoso código Morse.
6
Foram os estudos de Nyquist publicado em 1928 [38], ainda baseados no sistema de
telégrafo, que deram início às teorias de comunicações digitais modernas. Nesse trabalho
Nyquist propôs seu famoso teorema da largura mínima de banda para a transmissão de um
sinal. Estabeleceu assim que um determinado símbolo só poderia ser corretamente detectado se
a frequência da banda tivesse um limite mínimo teórico igual ao dobro da frequência de
símbolos. Portanto, na prática, para uma determinada banda de transmissão poderão ser
enviados símbolos a uma taxa inferior à metade da frequência de banda, assim evitando o efeito
da interferência intersimbólica. Como símbolos podem ser entendidos qualquer tipo de sinal,
portanto, com uma modulação eficiente pode-se alterar a taxa real de transmissão de dados,
permitindo o envio de mais de um bit de informação por símbolo.
Seguinte aos trabalhos de Nyquist [38], Shannon em 1948 [39], baseado em rigorosas
representações matemáticas e estatísticas, estabeleceu a capacidade do canal, inaugurando
assim uma nova área da engenharia: a teoria da informação. A equação (1) define a capacidade
do canal, também chamada de limite de Shannon, mostrando que para um determinado meio de
transmissão, um sinal transmitido a uma potência específica pode ser detectado sem ocorrência
de erros.
Anteriormente a Shannon [39], Hamming [40] havia iniciado os estudos sobre códigos de
correção de erros. Trabalhando na Bell Telephone Laboratories, ele era uma dos responsáveis
por auxiliar outros cientistas quando esses enfrentavam problemas no manuseio dos
computadores, que na época trabalhavam com relés programados através de cartões perfurados
e bastante suscetíveis a erros. Após esperar por cálculos importantes para pesquisas dos seus
colegas serem processados por alguns dias e não receber resultados, Hamming relatou que,
irritado, pensou:
“Maldição. Se uma máquina pode descobrir que há um erro, porque ela não pode localizar
onde ele está e mudar as configurações do relé de um para zero ou de zero para um?” [9]
Os estudos de Hamming influenciaram bastante o desenvolvimento da teoria de Shannon,
que por sua vez estabeleceu os parâmetros para os algoritmos de correção de erros através do
limite da capacidade do canal.
Após os trabalhos de Shannon [39] que deram visibilidade aos estudos de Hamming [40],
Golay em 1949 [41] também criou seu próprio método de correção de erros, estendendo o
código de Hamming, e inserido-se também como um dos pioneiros da área. Seu primeiro artigo
fundamental foi na teoria de correção de erros.
Após a criação de alguns outros métodos de codificação, como o de Reed-Salomon, Elias
em 1955 [11], propôs um sistema de codificação baseado em uma máquina de estados finitos
7
chamada de codificação convolucional, em que o sinal codificado depende apenas das entradas
e do estado passado. Esse tipo de codificador também ficou conhecido como codificação em
treliça devido à sua representação gráfica mais usual. Os códigos convolucionais podem ser
mostrados através de um gráfico que leva em consideração os estados dos registradores como
uma função temporal. O exemplo visto em [9] e reproduzido abaixo é bastante elucidativo da
forma como ocorre a construção do gráfico em treliça. O codificador convolucional é mostrado
na Figura 1.
Figura 1: Codificador Convolucional
O gráfico em treliça representa como a máquina de estados pode se comportar com o
tempo. Tomando um estado inicial em que todos os registradores têm valor zero, são
representados quais os estados que a máquina pode assumir e as saídas que o codificador pode
apresentar em se tendo as duas possibilidades de entrada. A máquina de estados do codificador
da Figura 1 pode ser representada pelo gráfico em treliça da Figura 2.
8
Figura 2: Representação do Gráfico em Treliça Relativo ao Codificador Convolucional da Figura 1
As linhas sólidas representam as saídas geradas a partir de um bit de entrada de valor zero,
e uma linha tracejada denota a saída do decodificador para uma entrada binária de valor um. Os
nós caracterizam os estados possíveis dos registradores do codificador. Os gráficos em treliça
têm todos os registradores em zero como estado inicial (representado nesse gráfico pelo estado
a=00). Partindo deste estado, a entrada pode levar a dois caminhos na treliça dependendo do
seu valor, ou seja, do dado a ser codificado. Pode-se notar que a partir do tempo t4 a treliça se
repete, não precisando então haver uma representação formal de todas as possibilidades através
do tempo. Essa relação temporal pode ser extrapolada a partir do gráfico reduzido.
A grande dificuldade enfrentada na utilização de esquemas de codificação convolucional se
dá na complexidade do decodificador. O problema, para um codificador simples, pode
inicialmente ser reduzido a encontrar o caminho na treliça que apresente a menor probabilidade
de erro se comparado com os possíveis caminhos seguidos. Considerando uma sequência
recebida pelo decodificador, os dados decodificados serão os que estão no caminho com menor
probabilidade de erros - a esse conceito dá-se o nome de maximum likelihood.
A função de erros para cada ramo da treliça será representada pela distância entre os dados
recebidos e todas as possibilidades da sequência. Essas distâncias são calculadas pela distância
de Hamming, para algoritmos de decisão abrupta (o decodificador só interpreta valores
binários) ou Euclidiana, para algoritmos de decisão suave (o decodificador interpreta símbolos
com mais de um bit cada). A decisão suave, também chamada de SISO (Soft-Input Soft-
Output), se dá pela utilização de dados ainda na forma ponderada na entrada do decodificador.
A distância de Hamming é apenas utilizada em sistemas com decisão abrupta, em que cada
dado de entrada do decodificador é representado por um bit. Para se calcular a distância entre
9
essa sequência recebida e a gerada por uma das possíveis sequências enviadas, basta fazer a
soma da quantidade de bits diferentes entre elas.
Já a distância Euclidiana está relacionada com os símbolos representados por mais de um
bit. Portanto, os sinais de entrada não apresentam apenas dois níveis lógicos. Para o cálculo se
considera que os ramos são constituídos pelos sinais sem ruídos e a métrica euclidiana será
simplesmente a distância entre o sinal recebido e o sinal sem ruído.
A ideia de encontrar a menor probabilidade de erros parece tentadora de início, porém essa
estratégia requer um hardware com uma complexidade enorme, pois deverão ser computados e
armazenados os dados para cada sequência possível.
Esse problema foi amenizado após Viterbi em 1967 [13] criar um sistema de decodificação
otimizado para os códigos convolucionais, gerando uma arquitetura mais simples. Porém a
ideia do algoritmo proposto continua sendo o de encontrar o caminho de maior probabilidade
(maximum-likelihood).
Através da análise do gráfico de treliça pode-se notar que a cada símbolo interpretado
existirão dois caminhos convergindo para cada nó. Portanto, só existirá um caminho mais
provável (menor distância) até um dado nó, assim, podendo eliminar uma das sequências,
sendo o caminho que não é eliminado chamado de sobrevivente. Desta forma, existirá sempre
um número limitado de sequencias a serem analisadas, reduzindo bastante a complexidade de
implementação.
Em contrapartida, Bahl et al. em 1972 [15] propuseram um decodificador baseado na
seguinte constatação: “O algoritmo de Viterbi, por ser um método de decodificação de máxima
probabilidade (maximum-likelihood), minimiza a probabilidade de erros de uma sequência para
o codificador convolucional. Esse algoritmo não necessariamente minimiza a probabilidade do
erro em um símbolo”. O algoritmo proposto em [15] se baseia na ideia de maximizar a
probabilidade a-posteriori (A-Posteriori Probability – APP) de cada símbolo ser correto, por
isso fora denominado Maximum A-Posteriori (MAP).
Segundo [14], maximizar as probabilidades a-posteriori por si só leva a um incremento
mínimo em termos de bits errados se comparado com o algoritmo de Viterbi, portanto essa
solução não foi usada de imediato, já que proporcionava um aumento de complexidade
significativo. Porém, essa informação a-posteriori é fundamental para um esquema de
decodificação iterativa.
O exemplo da funcionalidade do algoritmo MAP dado em [14], utilizando a notação
encontrada em [15], é bastante elucidativo:
10
A Figura 3 mostra uma treliça de terminação curta com sete seções, usada como exemplo.
O sinal transmitido é , -, e os símbolos de informação são ,
- ou seja, existem dois bits de terminação (tail bits) que levam o codificador de volta
ao estado zero.
O propósito final do algoritmo é o cálculo das probabilidades a-posteriori, tais como
, | - ou , | -, onde y é a sequência recebida observada na saída do canal, do qual a
sequência transmitida é . Porém, conceitualmente, é mais imediato calcular a probabilidade
de o codificador atravessar uma transição específica da treliça; ou seja,
, | -, onde é o estado no tempo , e é o estado no tempo . O
algoritmo calcula essa probabilidade como um produto de três termos, conforme expresso em
(2).
, | -
( )
, -
( ) ( ) ( ) ( ) (2)
Os valores de são variáveis internas do algoritmo e são calculados pela forward
recursion, definida em (3).
( ) ∑ ( ) ( ) (3)
Figura 3: Exemplo de Treliça
A forward recursion avalia os α-valores no tempo dos -valores calculados previamente
no tempo , e a soma sobre todos os estados m’ no tempo que conectam ao estado m
no tempo . A forward recursion é ilustrada na Figura 4. Os valores de são inicializados
como ( ) ( ) ( ) ( ) . Isto automaticamente força à condição em que
o codificador começará no estado 0.
11
Figura 4: Forward Recursion
Os β-valores são calculados por um procedimento análogo, chamado de backward
recursion, definido em (4).
( ) ∑ ( ) ( )
(4)
Os β-valores são inicializados por ( ) ( ) ( ) ( ) forçando a
condição de término da treliça. A soma se dá sobre todos os estados m’ no tempo , no qual
o estado m no tempo t se conecta. A backward recursion é ilustrada na Figura 5.
Figura 5: Backward Recursion
Os valores de são as probabilidades de transição condicional e são entradas para o
algoritmo. ( ) é a probabilidade conjunta de o estado no tempo ser e
ser recebido, sendo calculado por (5).
( ) ( | ) , | - ( | )
(5)
12
onde o primeiro termo, , | -, é a probabilidade de transição a priori e é
relacionada à probabilidade de .
O segundo termo, ( | ), é simplesmente a probabilidade de transição condicional do
canal dado que o símbolo seja transmitido. Note que é o simbolo associado com a transição
do estado .
As probabilidades dos símbolos a posteriori , | - podem ser calculadas a partir das
probabilidades a priori de transição, somando todas as transições correspondentes a e,
separadamente, somando todas as transições correspondentes a , para obter:
, | -
( )∑ , -
(6)
, | -
( )∑ , -
(7)
Na Figura (6), a transição sólida corresponde a e a transição tracejada corresponde a
.
Figura 6: Probabilidade de Transição
A descrição formal detalhada foi demonstrada em [15], bem como o algoritmo passo-a-
passo. A operação foi posteriormente alterada por Berrou, Glavieux e Thitimajshima em [17]
para se adequar ao caso da decodificação do turbo-code.
Como já citado, o algoritmo MAP é de difícil implementação em hardware, já que requer
muitas multiplicações de números que necessitam de muitos bits para a sua correta
representação. Além de requerer que a treliça seja percorrida ao menos duas vezes para o
cálculo das componentes e . Uma alternativa bastante interessante é a de realizar as
operações no domínio logarítmico, o que possibilita a redução das operações mais complexas.
Essa otimização será mostrada posteriormente nesse trabalho.
13
Durante um longo período essa decodificação não foi utilizada, por sua complexidade e
baixo ganho de desempenho com relação ao algoritmo de Viterbi [13]. O algoritmo MAP só foi
novamente discutido depois da criação dos turbo-codes, já que esses requeriam a informação a
posteriori de cada bit.
Durante muito tempo diversos estudos foram realizados e várias arquiteturas de codificação
foram propostas no sentido de usar mais esquemas de codificação de forma concatenada (por
exemplo, usar o codificador Reed-Solomon em série com um convolucional, como citado em
[14]). Os codificadores convolucionais eram uma boa alternativa como um dos codificadores a
serem concatenados. Para uma decodificação iterativa era preciso que as informações não
fossem abruptas, mas que houvesse um refinamento da informação. Com isso, algoritmos de
decisão suave foram mais estudados. A melhor alternativa neste período e com as
configurações desenvolvidas era a de utilizar os decodificadores do tipo SOVA (Soft-Output
Viterbi Algorithm).
O turbo-code mudou esse panorama propondo uma arquitetura em paralelo, onde dois
codificadores convolucionais recebiam a mesma entrada, porém com os dados permutados.
A criação do turbo-code foi proposta por Berrou, Glavieux e Thitimajshima em 1993 [17],
causando uma grande revolução no desenvolvimento dos codificadores, já que atingia
desempenho próximo ao estimado pelo limite de Shannon. Assim, o turbo-code se tornou
dominante como codificador de canal para comunicações digitais. A sua implementação porém
era desafiadora, sendo ainda atualmente um dos blocos mais complexos na implementação dos
sistemas de comunicação.
Primeiramente, [17] define um novo arranjo para realizar a codificação convolucional. Este
novo esquema já tinha um ganho de desempenho se comparado com os que vinham sendo
usados. Os codificadores sistemáticos são aqueles que enviam, além do sinal codificado, a
própria entrada. Contudo, é sabido que os codificadores convolucionais não sistemáticos (Non-
Systematic Convolutional – NSC) apresentam uma melhor resposta de erros para uma relação
sinal ruído alta [17]. A nova classe de codificadores chamados de convolucionais sitemáticos
recursivos (Recursive Systematic Convolutional – RSC) foi proposta por [17], sendo superior
aos NSC para qualquer relação sinal ruído em altas taxas de codificação. Neste caso, são
enviados sinais de sistemático (que é igual à entrada) e de paridade (resultado das operações do
codificador). Exemplos de codificadores NSC e RSC são mostrados nas Figuras 7 e 8, extraídas
de [17].
14
Figura 7: Codificador Non-Systematic Convolutional
Figura 8: Codificador Recursive Systematic Convolutional
Deve-se notar que no codificador NSC representado ambas as saídas são de sinais de
paridade, enquanto na figura do RSC, é o bit de paridade e é o bit de sistemático.
Sabe-se que a decodificação com decisão suave proporciona um ganho de desempenho
considerável para algoritmos iterativos. O logaritmo da razão das probabilidades (Log
Likelihood Ratio – LLR) é uma importante informação para o aprimoramento da decodificação.
A LLR pode ser calculada através da função de probabilidades descrita por (8):
( ) * ⁄ +
* ⁄ + (8)
sendo * ⁄ +, a probabilidade a posteriori (APP) do dado .
A formalização do algoritmo proposto por [15] foi modificado por [17] para o cálculo de
um codificador RSC, levando em consideração sua estrutura recursiva. Os passos descritos são
(algumas notações foram modificadas para melhor compatibilidade com [17]):
15
Considerando um RSC com comprimento K (quantidade de bits do codificador) em um
tempo k, os estados do codificador podem ser representados por:
( ) (9)
Sendo a entrada dos registradores de deslocamento com o dado de entrada , como
representado na Figura 8. O estados inicial e final do codificador, e , são iguais a zero.
A entrada do decodificador pode ser representada por * + onde
( ) são os sinais capturados que passam por um demodulador ou outro
processamento semelhante. Logo, a probabilidade conjunta para um estado m é definida por:
( ) *
⁄ + (10)
sendo então a probabilidade a posteriori (APP) definida por:
* ⁄ + ∑
( )
(11)
A LLR então fica:
( ) ∑
( )
∑ ( )
(12)
Para o cálculo da probabilidade conjunta, três funções de probabilidade são usadas,
descritas por (13).
( )
* +
* +
* ⁄ + (13.a)
( )
* ⁄ +
*
⁄ +
(13.b)
( ) * ⁄ + (13.c)
Pode-se notar que ( ) e ( ) são referentes às probabilidades de estado e
( ) se refere à probabilidade de transição entre estados, sendo esta variável calculada
pelas funções de probabilidades descritas em (14):
( ) ( )⁄
( ⁄ )
( ⁄ )
(14)
16
onde:
- ( )⁄ representa a probabilidade de transição do canal
condicionada a ( ). Contudo, pode ser desmembrado nas
variáveis recebidas, separadamente sistemático e paridade.
- ( ⁄ ) é a probabilidade de, tendo-se uma entrada, os
registradores transitem entre estados. Esta variável é sempre 1 ou 0, já que apenas uma entrada
específica leva a máquina entre estados determinados.
- ( ⁄ ) é a probabilidade de mudança de um estado para outro específico.
Este fator é relacionado com a probabilidade da entrada do codificador. Esta componente é
chamada de probabilidade a priori.
A probabilidade conjunta pode ser reescrita como:
( )
*
+
*
+ (15)
Através de algumas transformações em (15), obtém-se:
( )
( ) ( ) (16)
Por sua vez, ( ) e ( ) podem ser calculados recursivamente através das funções de
probabilidade de transição entre os estados, equações 17 e 18, calculando a probabilidade de
estados desde as primeiras amostras e desde a última amostra para ( ) e ( ),
respectivamente:
(17)
(18)
Assim, os passos do algoritmo de Bahls modificado por Berrou ficam:
- Passo 1: Inicializar as probabilidades ( ) e ( ) levando em consideração que os
registradores sempre começam e terminam com valores 0. Portanto:
( )
( )
( ) ( )
- Passo 2: Para cada recebido, são calculadas as probabilidades ( ) e
( ).
17
- Passo 3: Quando toda a sequência for recebida, ( ) é calculado e é multiplicado
por ( ) de forma a obter
( ) e posteriormente a LLR associada a cada .
Dessa forma, a decodificação de uma RSC é formalizada na forma de um algoritmo,
utilizando recursividade para o cálculo das probabilidades de estados. O algoritmo é mais
simples de entender graficamente através das figuras (4), (5) e (6).
O cálculo da LLR é reescrito como:
(19)
E a probabilidade de transição é representada pelas entradas independentes:
( )⁄
( )⁄ ( )⁄
(20)
Levando em consideração que um dos sinais do codificador é diretamente a entrada de
dados, a parte referente à informação do sistemático, ( )⁄ , no
cálculo de ( ) é independente do cálculo dos estados e , logo a LLR pode ser
fatorada em:
( ) ( ⁄ )
( ⁄ )
∑ ∑ ∑ ( )
( ) ( )
∑ ∑ ∑ ( ) ( ) ( )
(21)
A primeira parte da soma diz respeito apenas à entrada do sistemático, já a segunda parte se
refere à redundância inserida. Este fator representa a informação extrínseca, que, por sua vez,
não depende da informação do sistemático.
O codificador turbo-code é constituído por dois RSCs idênticos em paralelo, com a entrada
para um deles passando por uma função de interleave, que embaralha os dados de entrada,
alterando a sua ordem de uma forma pseudo aleatória de tal modo a permitir a reconstrução na
ordem natural dos dados. Este esquema pode ser visto na Figura 09.
18
Figura 9: Estrutura Simplificada do codificador Turbo-Code
Pode-se notar que os codificadores recebem a mesma informação, porém os bits são
recebidos em uma sequência diferente.
O decodificador iterativo usa a informação contida em uma sequência de paridade para que
refine a decodificação do seguinte. Um esquema de decodificador é representado na Figura 10.
Figura 10: Estrutura Simplificada do Decodificador Turbo-Code
Na Figura 10, w representa a informação extrínseca e as entradas de sistemático do segundo
decodificador são os dados decodificados pelo primeiro. Uma informação importante é que os
decodificadores não podem ser alimentados por dados correlatos, para evitar a correlação entre
os dados gerados pelos codificadores e as entradas.
1.2. ALGORITMOS E OTIMIZAÇÕES DO TURBO-CODE
Apesar de ser apresentado na forma de um algoritmo e de ser realizável, a decodificação do
turbo-code ainda tem um grau de complexidade muito elevado e sua implementação e
19
utilização na prática não seriam possíveis nas formas apresentadas até então. Para reduzir a
complexidade, algumas otimizações foram desenvolvidas, gerando uma forma bastante
simplificada do processador SISO.
1.2.1. Algoritmo Log-MAP
Segundo Robertson [16], o algoritmo apresentado por Bahls e modificado por Berrou
mesmo na sua forma recursiva apresenta um grau de complexidade alto. Isso se deve à
representação numérica, ao uso de funções não lineares e ao número elevado de somadores e
multiplicadores. A sua representação no domínio logarítmico resolve o problema numérico e
reduz a complexidade computacional.
No formalismo subsequente adotamos a notação:
( ) ∑
( )
(22)
As relações necessárias para o cálculo da LLR (posteriormente as componentes serão
separadas) no domínio logarítmico são desenvolvidas como mostrado em [16]:
( ) ( ( )) ( ) ( ( )) (23)
Logo:
( ) (∑∑ ( ( ) (
))
)
(∑∑∑ ( ( ) (
))
)
(24)
De acordo com [4]:
( ) ( ( )( | |)) ( ) ( | |) (25)
Inicialmente, aproximando-se a relação em (25) por ( ) ( ) pode-se
generalizar:
( ) * +
(26)
20
A função de máximo pode ser recursivamente calculada fazendo-se a comparação sempre
sobre duas componentes. Assim, combinando as equações (24), (25) e (26), obtém-se:
( ) ( )
( ( ) (
)) ( )
( ( ) (
)) (27)
Analogamente, para ( ) ( ( )), temos:
( ) ( )
( ( ) ( ))
( )( (
) ( )) (28)
Assim, a LLR fica:
( )
( )( ( ) (
) ( ))
( )
( ( ) ( ) ( ))
(29)
Decompondo como nas equações (14) e (20), a LLR fica:
( ) ( )
( ( ) ( ) ( ))
( ⁄ ) * +
( )
( ( ) ( ) ( ))
( ⁄ ) * +
(30)
A informação, a priori, pode então ser calculada para ( ⁄ )
por:
( ) ( * +
* +) (
* | +
* | +) (31)
Portanto:
* | + ( ) ( ( )) ( ) ( ( )) (32)
De forma similar, para ( ⁄ ):
* | + ( ( )) (33)
Essa simplificação é chamada de Max-Log-MAP devido à utilização das funções de
máximo e da composição logarítmica das variáveis. Essa solução apresenta um desempenho
sub-ótimo, já que a aproximação gera uma diferença de desempenho com relação ao cálculo
logarítmico. Uma forma de minimizar esta queda de desempenho é utilizando uma função de
21
correção baseada na componente não computada. Esta solução se aproxima bastante da
resposta ótima no domínio logarítmico. Este algoritmo é denominado de Log-MAP e tem sua
aproximação da função logarítmica representada por:
( ) ( ) ( | |)
( ) (| |)
(34)
onde ( ) é a função de correção. Consequentemente, pode-se provar que a expressão
( ) pode ser calculada com exatidão. Supondo que ( ) é
sabido. Então:
( ) ( )
( ) (| |)
( ) (| |)
(35)
Assim, todas as funções de máximo sobre dois valores têm uma função de correção. Como
consequência, por corrigir a cada passo a aproximação feita pelo Max-Log-MAP, o algoritmo
MAP original foi preservado.
Todavia, o cálculo de ( ) continua tendo um algo grau de complexidade. Como solução,
uma tabela com os valores pré-calculados pode ser inserida. Pode ser mostrado que poucos
valores já atendem a critérios bastante elevados de desempenho.
1.2.2. Decodificação em Paralelo
A implementação serial descrita por [17] e reproduzida anteriormente através da Figura 10,
é a forma iterativa do algoritmo de decodificação. Esta forma apresenta uma latência muito
elevada, impactando assim no desempenho do sistema.
Uma forma de reduzir o tempo de operação da decodificação é a implementação paralela
intra-SISO. Dobkin et al. [20] mostrou a arquitetura paralela para o decodificador MAP,
comparando o seu resultado com uma implementação utilizando janelas deslizantes (sliding-
window).
As janelas deslizantes são uma forma de acelerar a decodificação de forma a começar o
cálculo das componentes antes da conclusão do recebimento de todos os valores de entrada.
Um exemplo gráfico mostrado por [20] da utilização das janelas deslizantes pode ser visto na
Figura 11. Neste caso, primeiramente todos os dados são recebidos, posteriormente as
22
componentes são calculadas e, finalizando, a componente é calculada juntamente com a
LLR:
Porém a solução de janelas deslizantes reduz apenas o tempo do cálculo de uma
componente ( neste caso). Um algoritmo mais agressivo foi proposto por [20] em que
algumas SISOs operam em paralelo, dividindo os dados em sub-blocos de processamento de
tamanho W. Quanto menor o valor de W, menor é a latência associada. O maior empecilho é a
operação do interleaver. Contudo, um projeto correto permite a utilização desta técnica.
Posteriormente neste texto será apresentada uma das técnicas de interleaver.
A Figura 12 representa o tempo de processamento para uma arquitetura de janelas
deslizantes sequencial e uma totalmente paralela, onde N é o tamanho da palavra a ser
processada:
Figura 12: Comparação Sliding Window com Paralelismo
Figura 11: Operações com o Uso de Sliding Window
23
Existe uma queda de desempenho associada à descontinuidade do cálculo das componentes
de estado e . Neste sentido, algumas técnicas podem ser aplicadas para minimizar este
efeito. Uma delas é fazer a sobreposição dos cálculos: o fim dos sub-blocos se estende além do
começo do bloco subsequente, o que faz com que o cálculo seja mais apurado.
1.2.3. Interleaver
Segundo [22], o propósito do interleaver no turbo-code é assegurar que os padrões de
informação que causam palavras de baixo peso para o primeiro codificador não sejam
embaralhados gerando padrões de baixo peso para o segundo codificador, portanto melhorando
o peso do espectro do código.
Ainda segundo [22], otimizações de espalhamento do interleaver são desejáveis para
convergência rápida e uma boa propriedade de distância do código. Grandes distâncias abaixam
o ponto em que a curva de bit error rate (BER) planifica (“piso de erros”) e cresce a inclinação
da curva de BER.
O interleaver, como dito anteriormente, tem papel fundamental para permitir o uso de
certas técnicas de paralelização do decodificador. Segundo [21]:
“A seleção da codificação turbo foi cuidadosamente considerada durante a fase de estudo
do item do LTE para alcançar requisitos rígidos. Após a comparação com diversos
codificadores de alto desempenho (e.g., turbo codes, LDPC, etc) baseado na complexidade,
flexibilidade e compatibilidade, foi decidido usar o turbo code WCDMA existente com um
novo contention free interleaver, permitindo uma paralelização eficiente do decodificador para
altas taxas. Seguindo deliberações do grupo de trabalho, o Permutador Quase Regular (Almost
Regular Permutation – ARP) e o Permutador Polinomial Quadrático (Quadratic Permutation
Polynomial – QPP) emergiram como as soluções mais promissoras para os requisitos do LTE,
sendo o QPP selecionado.”
Uma contenção ocorre quando em uma arquitetura em paralelo, dois processadores SISO
tentam acessar o mesmo banco de memória ao mesmo tempo. A utilização de um interleaver
que não prevê paralelização requer hardware especializado para tratar as contenções, o que
gera uma solução pouco eficiente. Um contention-free interleaver com M sub-blocos de
tamanho W deve respeitar a seguinte relação:
( )
( )
(36)
24
Onde é a função de interleave ( )/deinterleave ( ), e para
todo .
Uma forma de otimizar a utilização das memórias é garantir que todos os processadores
SISO acessem o mesmo endereço de memória a cada momento. Para isso, o interleaver deve
seguir a função:
( ) ( ) (37)
Para todo e .
Esse é o tipo de função selecionada para o sistema LTE, assim permitindo a decodificação
em paralelo com uma implementação recursiva que leva a um hardware simples.
25
2. ARQUITETURA PROPOSTA E IMPLEMENTAÇÃO
O objetivo deste capítulo é o de introduzir a metodologia de desenvolvimento de circuitos
integrados digitais, justificar as decisões de projeto e descrever a arquitetura adotada.
A arquitetura adotada é a grande contribuição deste trabalho, já que foi pensada e
desenvolvida para otimizar o processo de decodificação e atender a objetivos específicos de
desempenho. Para tal, algumas técnicas para projeto do decodificador turbo-code foram
estudadas e algumas adotadas na medida em que afetam parâmetros estabelecidos.
2.1. FLUXO DE PROJETO DIGITAL
Com o evolução da tecnologia de fabricação de circuitos integrados CMOS permitindo um
avanço na miniaturização dos dispositivos e consequentemente da complexidade alcançada
pelos circuitos microeletrônicos, os desafios de projeto ficaram maiores. Uma das grandes
preocupações na microeletrônica é o de atingir a excelência técnica aliada a uma preocupação
com o tempo de execução, pois o momento de lançar o produto no mercado é fundamental para
o sucesso de uma solução (time to marketing). Esta preocupação já está em evidência há algum
tempo e definiu os rumos do fluxo de projetos adotado em SoCs. Já em 2002 [24] se
questionava:
“Como chegaremos lá (projetos com 12 milhões de portas lógicas)? Para qualquer
variável envolvida com a solução, uma coisa é clara: a habilidade de influenciar a
avaliação de propriedades intelectuais (Intellectual Property - IP) pelo reuso de projeto
será pedra fundamental invariável para qualquer combate efetivo à questão de
produtividade. IPs reusáveis são essenciais para atingir a qualidade em engenharia e a
realização no prazo de circuitos com muitos milhões de portas lógicas. Sem o reuso, a
indústria de eletrônicos simplesmente não será capaz de manter o ritmo com o desafio
de entregar dispositivos „melhores, mais rápidos e mais baratos‟ aos consumidores.”.
É neste contexto que se aplica o projeto desenvolvido, já que este teve como requisito
básico poder ser comercializado como um IP separado da camada física do LTE. Desta forma,
este se torna um projeto completo, percorrendo assim todas as etapas tradicionais do fluxo de
projetos digitais.
Diversas são as representações do fluxo de projeto, cada autor organizando as etapas da
forma que melhor lhe convém. Embora, todos sigam os mesmos passos básicos, diferindo
apenas na forma e não no conteúdo. Em [25] foi ilustrada uma forma bastante simplificada os
passos do design e suas respectivas etapas de verificação:
26
Figura 13: Representação em Alto Nível do Fluxo de Projeto
A Figura 13 mostra as transformações realizadas em cada etapa do projeto, reduzindo o
nível de abstração até chegar ao seu leiaute final. Também há uma partição entre o Front-End e
o Back-End, esta estrutura pode ser entendida como a porção em que somente transformações
lógicas ou físicas são realizadas. Partindo dos requisitos do produto, é criada uma especificação
funcional. Por sua vez, após o trabalho de projeto do RTL e a passagem pela síntese lógica,
uma especificação estrutural mais comumente conhecida como netlist é gerada. Após o término
desta etapa, a síntese física é realizada gerando o leiaute final do projeto. Todas essas etapas
vêm em conjunto com fases de verificação. Essas tarefas são detalhadas por [25] nas Figuras 14
e 15.
27
Figura 14: Detalhamento das Etapas de Front-End
Figura 15: Detalhamento das Etapas de Back-End
Na Figura 14 está representado o fluxo de desenvolvimento do Front-End, em que
inicialmente a especificação e, através de funções lógicas e matemáticas, evolui para uma
descrição em portas lógicas, entretanto ainda sem as informações físicas completamente
definidas.
28
Uma etapa que não é claramente mostrada na Figura 14, que pode ser adicionada entre a
especificação e o desenvolvimento do RTL é descrita em [26]. Nesta etapa, a especificação é
modelada em uma linguagem de alto nível como C/C++ ou Matlab de forma a validar os
conceitos da especificação. Uma descrição desta etapa feita por [26] é reproduzida a seguir:
“Uma vez que você tenha concluído a especificação detalhada do sistema, você
deve provar novos conceitos que você propôs para a implementação. Por exemplo, você
pode ter desenvolvido um novo algoritmo ou uma nova arquitetura, os quais você quer
implementar. Estes ainda não foram provados, ao invés de provar a sua adequação para
o projeto, você precisa usar linguagens de alto nível como C ou Matlab e testar os
códigos para todas as combinações possíveis que você poderá encontrar posteriormente
no hardware real quando você implementar o design. Até mesmo os padrões não podem
ser tomados como garantia e necessitam ser testados antes dos demorados códigos
Verilog. Quando você tiver certeza que os conceitos estão funcionando, este será o
momento correto de se começar o projeto de hardware.”
Após a modelagem, as funções a serem implementadas são escritas na forma de uma
linguagem de descrição de hardware (Hardware Description Language - HDL). Esta etapa é
denominada de RTL (Register Transfer Level), pois o projetista já revela onde os elementos de
memória são colocados na lógica, ou seja, quais sinais serão registrados. Algumas definições de
RTL são comentadas abaixo:
“RTL, ou nível de transferência de registradores, é um método de descrever o
comportamento do hardware em software usando uma linguagem de descrição de
hardware (HDL). Em qualquer linguagem de descrição de hardware (Verilog ou
VHDL), existem duas abordagens diferentes para descrever um bloco de hardware. Um
método consiste em descrevê-lo apenas pelo seu comportamento. A outra abordagem é
descrever o sistema de uma forma estrutural, ou seja, para atingir as funções pretendidas
são descritos blocos básicos cujas funcionalidades são sabidas e bem definidas. Nesta
abordagem, uma descrição Verilog ou VHDL do sistema é criada quando os
engenheiros de hardware sabem aproximadamente quais portas lógicas eles querem e
onde elas estarão.” [27]
“RTL significa nível de transferência de registradores, significando que o dado transferido
em um sistema realiza-se através de registradores” [28]
“Um código RTL é caracterizado pelo fluxo de controle direto através do código; é
compreendido por subcircuitos conhecidos que são conectados juntos de uma forma simples”
[29]
Esta é a função mais importante durante o projeto, já que irá definir os limites das
otimizações das etapas subsequentes. Um dos grandes motivos para a realimentação entre o
Back-End e o Front-End se dá exatamente na alteração do RTL para permitir que o projeto do
Back-End possa atingir certos requisitos.
A verificação do RTL é uma etapa bastante trabalhosa, consistindo basicamente de uma
verificação formal. Algumas metodologias estão sendo desenvolvidas nos últimos anos,
baseadas na evolução da linguagem Verilog para a linguagem SystemVerilog, que possibilitou
29
a introdução de muitas funções novas para a simulação, incluindo aí algumas características
que permitem o uso de estruturas com orientação a objetos. Porém, o conceito básico prevalece,
que é o de se comparar um modelo de referência (também chamado de Golden Model) com o
RTL a ser verificado, aplicando estímulos iguais aos dois modelos e comparando suas saídas.
Normalmente, esse modelo pode ser diretamente derivado do modelo desenvolvido após a
especificação.
Durante o Front-End ainda são realizadas as etapas de síntese e as respectivas verificações.
Uma etapa básica que acompanha o RTL é a descrição dos requisitos temporais (Timing
Constraints), já que é o projetista de Front-End que consegue definir cada requisito e restrição
para o que foi projetado. Estas informações são descritas em um arquivo no formato SDC
(Synopsys Design Constraints). A partir dos arquivos SDC e do RTL, é realizada a síntese
lógica, que tem como principal objetivo reduzir o projeto RTL de mais alto nível para o nível
de portas lógicas, porém sem apresentar as características físicas completas. Por todo o fluxo
digital as transformações se dão sempre tendo como objetivo principal atender aos requisitos de
tempo.
O resultado final de todas as etapas de síntese mostradas na Figura 14 é um netlist, ou seja,
um arquivo com a descrição das funções através de portas lógicas. As etapas de verificação
também são mostradas, consistindo na análise de temporização, análise de potência, uma
verificação funcional (não obrigatória) e uma verificação formal comparando através de uma
prova matemática que o netlist equivale ao RTL.
O fluxo de Back-End é simplificadamente representado pela Figura 15. Normalmente, as
etapas de síntese são automatizadas, embora guiadas pelo julgamento humano [25]. É de
extrema importância o conhecimento de todas as etapas percorridas pelas ferramentas de EDA
(Eletronic Design Automation) para poder solucionar qualquer dificuldade e para obter os
melhores resultados das ferramentas.
Na Figura 15 é mostrado que o primeiro passo após a síntese lógica é o placement. Uma
etapa anterior pode ser adicionada se o projeto tiver níveis hierárquicos ou módulos que não
obedecem às células padrão, como memórias ou Hard-IPs. Assim, a descrição das etapas
representadas na Figura 15 segundo [27] são reproduzidas a seguir:
Floorplanning: É a primeira grande etapa do projeto físico. As tarefas chaves incluem
analisar o tamanho do projeto (área de silício), selecionar o encapsulamento, posicionar as
entradas e saídas, posicionar as macrocélulas (tais como células de memória, células analógicas
e células de função especial), planejar a distribuição de potência e de clocks e particionar a
hierarquia.
30
Placement: O posicionamento é uma etapa chave para o projeto físico. Como o nome
sugere, o posicionamento é o processo de posicionar as células ou procurar a melhor
localização para cada célula do netlist dentro do floorplan. É uma atividade crucial, pois um
posicionamento pobre consome mais área, além de prejudicar o desempenho da velocidade do
chip. Posicionamento ruim geralmente leva a uma tarefa de roteamento difícil e, algumas vezes,
impossível.
Route: Após a etapa de placement, a exata localização das células e os seus pinos são
fixados. O próximo passo é completar fisicamente as interconexões definidas no netlist. Isso
implica no uso de fios (metais) para conectar os terminais relacionados em cada fio. O processo
de encontrar os leiautes geométricos para os fios é chamado de roteamento (routing). Como um
requisito, os fios roteados devem estar confinados a uma área. Adicionalmente, os fios não
devem estar curto-circuitados. Em outras palavras, os fios não devem ter uma interseção com
outros.
O objetivo do processo de roteamento depende da natureza do projeto. Em projetos de
propósito-geral, é suficiente minimizar o comprimento dos fios enquanto completa as
conexões. Em projetos de alto desempenho, é crucial o roteamento de cada fio de forma a
atingir os requisitos de temporização. Fios de propósito-específico, como o de clock e o terra,
requerem um tratamento especial.
Parasitic Extraction: Após as células serem posicionadas, as conexões elétricas são feitas
por fios metálicos. As células e os fios têm resistência e capacitância que afetam a propagação
de corrente através deles. Como consequência, há um impacto no tempo de propagação do
sinal. A Extração de Parasitas é o processo de extrair os valores exatos das resistências e
capacitâncias associadas a cada segmento de metal, de modo que seu impacto no atraso do sinal
possa ser determinado precisamente.
Timing Analysis: Verificação temporal é o processo de comprovar que o leiaute do chip
pode operar até a frequência definida para o produto. Diferentemente da verificação funcional,
a qual busca a funcionalidade do chip, a verificação temporal foca na velocidade do chip. Outra
diferença entre as duas verificações é que a de temporização deve ser realizada em todos os
casos limites (corner cases) de processo, temperatura e tensão (Process, Voltage and
Temperature – PVT). Um produto confiável deve rodar à temperatura desejada com
transistores fracos/fortes, resistência dos metais e vias alta/baixa, e com tensão fornecida
alta/baixa. Antes do projeto ser mandado para a manufatura, o comportamento de temporização
em todas as combinações destas condições têm que ser testadas com os requisitos do projeto.
31
2.2. APRESENTAÇÃO DA ARQUITETURA
O Turbo-Code do sistema LTE é definido em [18], consistindo apenas da especificação da
codificação como mostrado na Figura 16 e da definição do interleaver.
Figura 16: Codificador Especificado para o Padrão LTE
A Figura 16 mostra dois codificadores convolucionais de 8 estados em paralelo, ligados por
um interleaver, resultando em uma taxa de codificação de
. A cada bit de dados existirão 3 bits
codificados. Na Figura 16 as linhas pontilhadas representam o caminho de dados para a criação
dos tail bits, que levam o sistema ao estado em que todos os registradores tomam valor lógico
zero.
Em operação normal, apenas três sinais são enviados e ao final de um bloco de dados, o
sistema deve ser levado ao estado conhecido em que todos os registradores são zero, gerando
assim os tail bits.
As saídas de dados do codificador são um bit do sistemático e dois de paridade, sendo a
unidade de codificação composta por três registradores. Os três sinais devem ser enviados
concatenados entre si, sendo os bits modulados na seguinte sequência:
0 ( )
( )
( )
( )
( )
( )
( )
( )
( )
1 (38)
32
Usando a relação das saídas com o sinal codificado, tem-se:
( )
( )
( )
(39)
E os tail bits completam a sequência e são definidos por [12]:
( )
( )
( )
( )
( )
( )
( )
( )
( )
( )
( )
( )
(40)
Portanto, a sequência de transmissão de dados para um bloco de entrada de K bits terá
bits, com os últimos 12 representando os bits de terminação.
Outra definição é a função de geração do interleaver e os seus parâmetros, que são dados
pela equação (41). A Tabela 1 mostra os valores dos parâmetros necessários para os cálculos
[18].
( ) ( ) (41)
33
Tabela 1: Parâmetros do Interleaver
t K f1 f2 t K f1 f2 t K f1 f2 t K f1 f2
1 40 3 10 48 416 25 52 95 1120 67 140 142 3200 111 240
2 48 7 12 49 424 51 106 96 1152 35 72 143 3254 443 204
3 56 19 42 50 432 47 72 97 1184 19 74 144 3328 51 104
4 64 7 16 51 440 91 110 98 1216 39 76 145 3392 51 212
5 72 7 18 52 448 29 168 99 1248 19 78 146 3456 451 192
6 80 11 20 53 456 29 114 100 1280 199 240 147 3520 257 220
7 88 5 22 54 464 247 58 101 1312 21 82 148 3584 57 336
8 96 11 24 55 472 29 118 102 1344 211 252 149 3648 313 228
9 104 7 26 56 480 89 180 103 1376 21 86 150 3712 271 232
10 112 41 84 57 488 91 122 104 1408 43 88 151 3776 179 236
11 120 103 90 58 496 157 62 105 1440 149 60 152 3840 331 120
12 128 15 32 59 504 55 84 106 1472 45 92 153 3904 363 244
13 136 9 34 60 512 31 64 107 1504 49 846 154 3968 375 248
14 144 17 108 61 528 17 66 108 1536 71 48 155 4032 127 168
15 152 9 38 62 544 35 68 109 1568 13 28 156 4095 31 64
16 160 21 120 63 560 227 420 110 1600 17 80 157 4160 33 130
17 168 101 84 64 576 65 96 111 1632 25 102 158 4224 43 264
18 176 21 44 65 592 19 74 112 1664 183 104 159 4288 33 134
19 184 57 45 66 608 37 76 113 1696 55 954 160 4352 477 408
20 192 23 48 67 624 41 234 114 1728 127 96 161 4416 35 138
21 200 13 50 68 640 39 80 115 1760 27 110 162 4480 233 280
22 208 27 52 69 656 185 82 116 1792 29 112 163 4544 357 142
23 216 11 36 70 672 43 252 117 1824 29 114 164 4608 337 480
24 224 27 56 71 688 21 86 118 1856 57 116 165 4672 37 146
25 232 85 58 72 704 155 44 119 1888 45 354 166 4736 71 444
26 240 29 60 73 720 79 120 120 1920 31 120 167 4800 71 120
27 248 33 62 74 736 139 92 121 1952 59 610 168 4864 37 152
28 256 15 32 75 752 23 94 122 1984 185 124 169 4928 39 462
29 264 17 196 76 768 217 48 123 2016 113 420 170 4992 127 234
30 272 33 68 77 784 25 98 124 2048 31 64 171 5096 39 158
31 280 103 210 78 800 17 80 125 2112 17 66 172 5120 39 80
32 288 19 36 79 816 127 102 126 2176 171 136 173 5184 31 96
33 296 19 74 80 832 25 52 127 2240 209 420 174 5248 113 902
34 304 37 76 81 848 239 106 128 2304 253 216 175 5312 41 166
35 312 19 78 82 864 17 48 129 2368 367 444 176 5376 251 336
36 320 21 120 83 880 137 110 130 2432 265 456 177 5440 43 170
37 328 21 82 84 896 215 112 131 2496 181 468 178 5504 21 86
38 336 115 84 85 912 29 114 132 2560 39 80 179 5568 43 174
39 344 193 86 86 928 15 58 133 2624 27 164 180 5632 45 176
40 352 21 44 87 944 147 118 134 2688 127 504 181 5696 45 178
41 360 133 90 88 960 29 60 135 2752 143 172 182 5760 161 120
42 368 81 46 89 976 59 122 136 2816 43 88 183 5824 89 182
43 376 45 94 90 992 65 124 137 2880 29 300 184 5888 323 184
44 384 23 48 91 1008 55 84 138 2944 45 92 185 5962 47 186
45 392 243 98 92 1024 31 64 139 3008 157 188 186 6016 23 94
46 400 151 40 93 1056 17 66 140 3072 47 96 187 6080 47 190
47 408 155 102 94 1088 171 204 141 3136 13 28 188 6144 263 480
34
São 188 possíveis tamanhos das sequências, que variam de 40 a 6144 bits, dependendo de
diversos fatores, como a relação sinal/ruído. Essa definição é feita através de sistemas de
controle externos ao turbo-code durante a codificação. Esta informação também é enviada ao
decodificador, de modo que este então sabe previamente o tamanho da sequência a ser
decodificada.
O projeto consiste na implementação VLSI do decodificador do sistema LTE, tomando
alguns outros requisitos, como, por exemplo, a frequência. A frequência de operação é bastante
importante para o sucesso em atingir o desempenho previsto pelo sistema, porém causa um
grande impacto no consumo de potência, o que para um dispositivo móvel é bastante relevante.
Inicialmente foi considerada, baseada nos outros blocos do sistema LTE, que a frequência
de operação ficaria limitada a aproximadamente 120 MHz. Esta discussão será melhor
abordada em outra seção.
Para melhorar o desempenho do turbo-code projetado, as otimizações citadas no primeiro
capítulo foram usadas. A implementação do algoritmo Log-MAP é obrigatória para a
minimização do hardware implementado, causando uma perda de desempenho mínima. O
paralelismo também foi explorado como forma de reduzir a latência e aumentar o throughput
do sistema. Isso se dá simplesmente pelo fato de que um bloco de dados pode ter seu tempo de
processamento reduzido em até oito vezes, portanto o hardware estaria disponível para
processamento em um tempo menor, suportando assim taxas de processamento maiores.
Outro bloco que tem seu processamento muito otimizado é o interleaver, cuja
implementação se apresenta bastante complicada para o cálculo das posições, já que faz o uso
da função de resto da divisão, que é uma operação muito complexa de ser sintetizada, gerando
um hardware pouco eficiente. Este cálculo pode ser reduzido bastante se for levado em
consideração que os endereços serão calculados sempre de forma sequencial. Isto leva à
redução da função de resto de divisão que passa a ser implementada apenas por comparadores e
subtratores interagindo recursivamente, como demonstrado a partir das equações (42) a (45):
( ) ( ( )) (42)
( ( ) ( )) ( ) (43)
( ) ( ( ) ) (((∑
) ) )
(44)
( ) ( ( ) ) ((( ( ) ) ) ) (45)
35
Sendo um registrador com o valor agregado do somatório de 2 , demonstrando assim a
recursividade possível na implementação do interleaver. Isso só é possível, pois o sistema
sempre se iniciará na posição zero, continuando o processamento sequencialmente. Neste
formato pode-se ver claramente uma redução grande no hardware a ser implementado, sendo a
função do resto de divisão por um número qualquer constituída apenas por comparações e
subtrações, já que os valores nunca ultrapassam em três vezes o valor do quociente da divisão,
limitando os valores a serem calculados os restos de divisão. Não há, assim, a necessidade de se
usar a função completa de resto de divisão diretamente em hardware, apenas comparando com
os três primeiros múltiplos de K e subtraindo os valores correspondentes.
Portanto, para o codificador, todos os dados são armazenados antes que se comece o
processamento, já que os dados de entrada para o codificador que processa depois do
interleaver poderão ser acessados em qualquer ordem. Isto leva à necessidade de essas
informações estarem todas disponíveis para que não se tenha que parar o processamento até a
entrada atingir a posição necessária. O decodificador também obedece a este requisito.
Esta otimização do interleaver minimizou o hardware associado, uma vez que sendo
descrito e sintetizado na sua forma original, o interleaver necessitaria da introdução de um
nível de pipeline, o que elevaria sua latência, gerando um projeto com aproximadamente 34 mil
portas lógicas equivalentes. Contudo, introduzindo-se a otimização, atinge-se, para o mesmo
nível, aproximadamente 1500 portas lógicas equivalentes, sem nível de pipeline. Isso leva a um
hardware que ocupa menos área de silício e realiza a operação mais rapidamente.
Com a função de interleave implementada em hardware, o projeto do codificador segue o
descrito na especificação e mostrado na Figura 16, sendo necessário apenas sincronizar as
saídas válidas com o momento do interleaver.
A arquitetura do decodificador pode ser inicialmente entendida através da Figura 17, em
que aparecem dois processadores SISO, um processando os dados de forma regular e o outro
processando os dados que passaram pelo interleaver. A operação é iterativa, sendo que cada
SISO alimenta o outro de forma a refinar os resultados obtidos. É importante notar também que
os dados de realimentação entre os processadores devem passar necessariamente pelo processo
de interleave ou de-interleave.
36
Figura 17: Demonstração das Etapas de Decodificação
O processador SISO, realizado pelo algoritmo Log-MAP, inicialmente calcula os valores da
probabilidade de transição entre estados. O processamento inclui possíveis estados de entrada
do codificador que permitem a saída codificada ser zero ou um.
A relação das entradas com os possíveis estados pode ser vista nas Figuras 18 a 20.
Figura 18: Início da Treliça do Codificador do Padrão LTE
Figura 19: Transições Intermediárias da Treliça do Padrão LTE
37
Figura 0: Geração dos Tail Bits 2
A Figura 18 mostra o início da operação de codificação, enquanto a Figura 19 descreve a
operação normal da máquina de estados. Uma informação relevante consiste nos valores dos
dados codificados. A Figura 20 trata da terminação da treliça, em que o sistema é levado ao
estado em que todos os registradores têm valor zero. Neste caso, os dois sinais de codificação
são mostrados, tanto o sinal de paridade como o de sistemático.
Partindo destas figuras podem ser inferidos quais são os estados que levam a saída a um
valor específico. Dessa informação pode-se calcular a probabilidade de transição de estados.
Este cálculo é feito no domínio logarítmico assim sendo simplificado. Uma multiplicação de
quatro variáveis resulta em uma soma, e três possíveis inversores de sinal. Tomando-se como
ponto de partida as equações (14) e (20), chega-se a:
( )
( ( )) (⁄ ( )⁄ )
( ( ⁄ ))
(46)
Todos os elementos da soma são processados de acordo com as possibilidades de transição
de cada estado para outro específico, portanto o cálculo é feito para cada estado possível. No
caso do sistema LTE, desesseis valores serão calculados para cada estágio do processamento,
referentes a duas transições possíveis para cada estado. É importante notar que todos os valores
já são tratados no domínio logarítmico e o resultado esperado também deve ser representado
neste domínio, o que torna desnecessário o cálculo logarítmico. Este processamento já será
feito no momento da aquisição e demodulação dos sinais recebidos.
A arquitetura que representa os cálculos desenvolvidos para obter o valor das
probabilidades de transição de estados pode ser vista na Figura 21.
38
Figura 21: Arquitetura de Hardware do Cálculo da Probabilidade de Transição
Na Figura 21, ( ), ( ) e ( ) são, respectivamente, os fatores referentes ao
sistemático, paridade e o valor a priori. E os dados extraídos da LUT (Look-Up Table) são os
valores possíveis em cada transição.
O cálculo dos fatores de probabilidade e incorre em um hardware semelhante, podendo
ser reusado numa mesma sequência de cálculo pois esses dois elementos não serão calculados
no mesmo momento. Como uma forma de otimizar o tempo de processamento, o cálculo de é
feito no começo e armazenado. Posteriormente, o cálculo de é relizado e o resultado do
processamento é apresentado. Este esquema é mostrado na Figura 22.
Figura 22: Arquitetura da SISO
Seguindo as equações (27), (28) e (35) o hardware necessário para realizar o cálculo das
probabilidades de estados é representado na Figura 23 (a representação está levando em
consideração , porém, para o cálculo do o hardware é idêntico):
39
Figura 23: Arquitetura de Hardware das Probabilidades de Estados
40
Inicialmente, faz-se a soma da probabilidade de transição com a probabilidade de estados
para os dois possíveis caminhos da treliça, para cada estado, e compara-se os resultados para
obter o maior valor. Obtém-se assim, a probabilidade de a treliça se encontrar em um estado
específico baseado nos sinais recebidos e no estado anterior (ou posterior, no cálculo do ). O
máximo entre esses valores representa, inicialmente, o resultado sub-ótimo obtido pelo
algoritmo max-log-MAP. Após este estágio, diversos fatores de correção são aplicados para se
obter um melhor desempenho através do algoritmo Log-MAP.
O cálculo dos fatores de correção são feitos a partir de Look-Up Tables – LUTs, que são
tabelas com os valores linearizados dos resultados de uma função logarítmica. Os valores dos
fatores de correção são tomados em relação à subtração dos valores de entrada da função de
máximos.
O valor final do cálculo das funções de probabilidade de estados obedecem à função
otimizada do algoritmo Log-MAP. São calculadas oito funções de probabilidade em cada
estágio de processamento, já que cada estado tem uma probabilidade específica para cada sinal
de entrada do decodificador.
O cálculo da LLR é feito através da subtração dos valores da probabilidade de a entrada do
codificador ter sido zero ou um. Portanto, a arquitetura seguida pelo hardware é apresentada na
Figura 24.
41
Figura 24: Cálculo da LLR
É importante ressaltar, pela análise da Figura 24, que os índices dos componentes , e
das somas são combinados de forma a obedecer as possíveis transições entre os estados. Por
exemplo, o sinal que representa a probabilidade de o sistema estar no estado 1 e acabar no
estado 5 é calculado baseando-se nas probabilidades e dos estados 1 e 5, respectivamente, e
da probabilidade de a máquina fazer a transição entre estes estados.
A informação extrínseca pode então ser calculada, já que é parte integrante do cálculo da
LLR. Porém, pela facilidade de implementação, os dados extrínsecos são extraídos do valor da
LLR obtido. A implementação em hardware é representada na Figura 25.
Figura 25: Cálculo da Informação Extrínseca
42
Na Figura 25, os dados obtidos pelo processamento da SISO são subtraídos da informação
a priori calculada nas iterações anteriores. Em operação iterativa é o resultado da LLR que
representa a tendência do valor dos dados a serem decodificados, sendo usado na decisão final
(hard-decision). Já a informação extrínseca será realimentada no sistema de forma a reforçar ou
anular tendências da escolha a cada iteração, tornando-se assim a informação a priori para a
próxima etapa de iteração. Esta estrutura da realimentação é mostrada na Figura 26.
Figura 26: Arquitetura do Decodificador
Na Figura 26 pode ser observado que o processador SISO é reutilizado tanto para a
decodificação, com os dados na sequência permutada pelo interleaver, como na sequência
normal. Os dados inicialmente são demodulados (esta etapa é realizada fora do bloco do Turbo-
Code), este processo podendo ser feito na forma tradicional. Contudo, o padrão LTE prevê o
uso de MIMO, permitindo diversidade espacial com o uso de mais de uma antena. Os dados são
então demultiplexados, separados nos sinais de sistemático e nos de paridade. Estes dados têm
que ser armazenados em memórias, já que serão utilizados a cada iteração. O processador SISO
é então alimentado pelos sinal de sistemático, por um de paridade e pela informação extrínseca
gerada na iteração anterior.
Para leitura do sistemático e da informação extrínseca, de forma a ser compatível com o
sinal de paridade da sequência permutada, necessita-se da função de interleaver. Este bloco é
exatamente igual ao usado no codificador. Os resultados gerados pela função do interleaver
representam os endereços a serem usados durante a leitura dos dados nas memórias. A
informação extrínseca a ser escrita na memória, quando os dados são processados na sequência
43
com interleaver, deve seguir este mesmo padrão, para que, na forma direta, os sinais sejam
coerentes.
Uma otimização feita neste projeto é a sequência de processamento dos dados. No início de
cada bloco, são processados os sinais na sequência permutada do interleaver, já que assim o
throughput pôde ser otimizado em parte pelo fato de a última etapa de processamento se dar na
sequência linear, o que permite a escrita de novos dados de entrada na sequência em que são
lidos e processados os antigos. Desta forma, também o tempo de escrita na leitura não é um
período obrigatório de inatividade do processador SISO. Outra contribuição desta sequência de
processamento é que a saída dos dados após todas as iterações será realizada e logo enviada,
não precisando desfazer o processo da permutação do interleaver, que haveria caso o
processamento se iniciasse com a sequência linear.
A sequência de processamento é representada pela máquina de estados ilustrada na Figura
27.
Figura 2 : Máquina de Estados da Operação de Decodificação 7
Na Figura 27, SISO1 representa a etapa de processamento em que os dados advêm do
codificador que é alimentado diretamente com a sequência de entrada. Já a SISO2 é o
processamento com a utilização dos dados que passam pelo interleaver.
44
No caso do Turbo-Code implementado, alguns sinais de protocolo foram inseridos para
facilitar o controle do sistema. O sink_valid, representado na máquina de estados, é um sinal de
entrada que, quando em valor lógico positivo, demonstra ao bloco Turbo-Code que existe uma
nova informação de dados a ser decodificada. Desta forma, o bloco anterior controla a entrada
de dados, sem seguir uma regra rígida.
Em aplicações normais, o processo de decodificação é finalizado quando o sistema atinge
certo número de iterações estabelecidas ou quando o decodificador converge para um valor. No
caso do projeto descrito neste trabalho, apenas a primeira opção foi implementada. Esta escolha
foi feita como uma especificação do projeto, para facilitar a conclusão. Porém, um benefício
também obtido é o de ter latências fixas para cada tamanho de bloco possível, tornando assim o
controle mais simples.
A máquina de estados também evidencia duas etapas do processamento da SISO, chamadas
de IN e OUT. Estas receberam estas denominações pois o processamento é feito inicialmente
apenas lendo os valores de entrada e calculando o valor de . Já na segunda etapa, os valores
são novamente lidos, porém as saídas já têm dados válidos.
É importante notar também que o cálculo da probabilidade de transição de cada estado é
feito nas duas etapas de processamento, já que esta informação é usada para o cálculo das
componentes diretas e inversas de probabilidade de estados. É mais simples e eficaz refazer
esta operação a guardá-la para posteriormente utilizá-la.
Apesar das otimizações feitas, esta arquitetura ainda apresenta um throughput baixo se
comparado com o especificado pelo padrão LTE. Uma forma de atingir este objetivo é a
replicação do hardware completo, que traria um aumento significativo em área. O próprio
padrão foi idealizado, através do projeto do interleaver, para atender a uma paralelização do
processamento. Esta arquitetura paralela permite quebrar as sequências de decodificação para
que, assim, sejam processados blocos menores de dados, o que faz o fluxo ser maior. Neste
caso, o aumento de hardware será apenas na parte do processamento, não impactando nas
memórias, que se mostrou como o bloco que ocupa a maior área.
O interleaver tem papel fundamental para permitir a paralelização do hardware e da
otimização para atingir o throughput necessário. O interleaver é apresentado apenas como uma
função mostrada na equação (41), com os valores de referência da Tabela 1. A otimização para
realizar a operação de forma sequencial e reduzir o cálculo do resto de divisão por subtração e
comparação foi mostrada na equação (45). Contudo, para demonstrar a possibilidade do uso da
arquitetura em paralelo, algumas outras manipulações são necessárias.
45
Inicialmente, é importante ressaltar que nem todos os blocos tirarão proveito do
paralelismo. Este fato está ligado a uma queda de desempenho significativa ao se dividir a
operação em sequências pequenas. Isso se dá, pois, quando esta otimização é usada, os estados
iniciais das variáveis de probabilidade de estados não são conhecidos, o que no caso de
sequências mais longas é compensado pela melhor precisão dos dados realimentados e da outra
variável de estado. Portanto, o particionamento foi feito em escalas diferentes, baseadas no
tamanho das sequências. Os blocos podem não ter divisão do processamento, assim como
podem ser particionados em duas, quatro ou oito sequências de dados. O limite de 8 sequências
foi tomado com base em uma análise de desempenho e na dificuldade da implementação do
interleaver.
Para um particionamento da sequência em dois blocos de tamanho menor, é levado em
consideração que a constante de inicialização da equação (45) é sempre um valor ímpar, que
e são sempre pares e que o cálculo do endereço é sempre submetido à operação de resto de
divisão. Portanto, o endereço de permutação de uma posição com a correspondente na outra
metade da sequência é dado pela equação 47.
(
) (
) (47)
Pela operação de resto de divisão, todos os elementos múltiplos de um valor inteiro de K
podem ser eliminados, levando à simplificação:
(
) (
) (48)
(
) ( ( )
)
(49)
Esta relação demonstra que quando se divide a sequência em dois blocos, pode-se garantir
que cada processamento se dará em memórias separadas, ou seja, os dados a serem processados
em um modo com o interleaver serão obtidos cada um em uma metade dos dados. A mesma
demonstração pode ser feita para o caso em que se divide a sequência em quatro e oito blocos,
como pode ser visto nas equações (50).
(
) (
) (50)
(
) (
)
(51)
46
Como os tamanhos dos blocos que farão a paralelização com quatro processadores são
sempre múltiplos de 16 e é ímpar, o que gera a relação .
/
( ), o cálculo se
reduz a:
(
) (
( )) (52)
(
) (
( ))
(53)
Levando em conta a relação entre as sequências acessadas, as equações (52) e (53) podem
ser reescritas na forma:
(
) ( ( )
( )) (54)
(
) ( ( )
( ))
(55)
Para oito processadores, é múltiplo de 64, o que conduz a:
(
) (
( )
) (56)
(
) (
( )
( )( )))
(57)
Com as equações anteriores fica demonstrada a possibilidade da implementação de uma
arquitetura paralela, como a ilustrada na Figura 28 para o caso de quatro processadores SISO:
(a) (b)
Figura 28: Alimentação dos Dados em uma Arquitetura com 4 SISOs
47
As linhas contínuas representam uma ligação permanente, já que os bits de paridade são
sempre lidos de forma sequencial, mesmo quando estes são gerados com os dados recebidos na
forma permutada. O mesmo não ocorre com os sinais de sistemático e da informação
extrínseca, que devem ser lidos de qualquer memória. Nesta relação, os processadores SISO
não acessam a mesma memória ao mesmo tempo. Esta relação é mostrada na Figura 28b.
A paralelização do processamento das sequências de decodificação foi definida conforme a
Tabela 2.
Tabela 2: Relação entre o Tamanho do Bloco de Dados e a Quantidade de Processadores Utilizados na
Decodificação
1
2
3
4
O processamento em paralelo gera um grande problema relacionado com o
desconhecimento das condições iniciais, pois o turbo-code tem como pressuposto que a
máquina de estados se inicie e termine no estado em que todos os registradores se encontram no
valor lógico zero. Portanto, os valores da probabilidade de estado não são muito confiáveis nos
pontos de corte da janela a ser processada. A solução adotada foi estender o cálculo da
informação extrínseca de forma a prover uma melhor realimentação. A solução é mostrada na
Figura 29.
Figura29: Separação dos Blocos a serem Processados
2.3. IMPLEMENTAÇÃO
Todos os processos para a realização do fluxo completo de desenvolvimento do projeto
digital foram realizados dentro do ambiente de EDA da Cadence Design Systems®, desde a
simulação até a geração do leiaute final. Exceção feita à modelagem do sistema, que no caso
específico de comunicação digital se optou por utilizar o Matlab por motivos explicados
posteriormente.
48
Após a especificação do projeto, as definições das arquiteturas mostradas na seção anterior
foram realizadas em conjunto com a modelagem do sistema. Isto se deu para que houvesse a
possibilidade de testar as novas definições e estimar o desempenho atingido. O objetivo é
realizar um balanceamento entre a otimização do hardware e a queda do rendimento dos
algoritmos, sendo este balanceamento fundamental para chegar a uma solução otimizada.
O modelo do sistema foi inicialmente realizado em Matlab devido às facilidades de cálculos
matriciais e de estruturas de processamento de sinais. Outra informação importante para a
utilização desta ferramenta e sua linguagem é a da compatibilidade, já que o modelo de toda a
camada física do LTE foi descrito usando a mesma linguagem. Porém, ao partir para um
modelo mais próximo ao que seria sintetizado para hardware, o sistema se tornou muito lento,
com as simulações tomando muito tempo de processamento. A alternativa encontrada foi de
modelar os cálculos críticos em uma linguagem que permite um maior controle e que tenha
uma interface mais direta com o processador, acelerando assim o tempo de processamento. A
linguagem escolhida para este trabalho específico foi a linguagem C, já que é de fácil acesso e
de conhecimento usual, além de poder ser facilmente integrada à ferramenta Matlab.
Com a modelagem, também pode ser feita uma análise detalhada do desempenho atingido
pelo sistema. Para isso, um ambiente de simulação foi criado, com a geração de dados, um
codificador, um modulador, um modelo do canal, um demodulador e finalmente o
decodificador. A saída do decodificador deve ser igual à entrada gerada e o desempenho é
medido pela quantidade de erros nesta comparação. O ambiente de simulação é mostrado na
Figura 30.
Figura 30: Representação do Ambiente de Simulação do Sistema
Os dados de estímulo são gerados aleatoriamente e reservados para uma futura comparação.
Estes sinais passam pelo codificador que insere a redundância necessária. O modulador neste
sistema apenas mapeia alguns bits para um símbolo, que posteriormente tem seu sinal
adicionado de um ruído gaussiano. As informações tomam um formato floating-point, podendo
tomar qualquer valor, como um sinal analógico. Os dados inicialmente digitais, com valores
discretizados, passam para um formato contínuo. Para gerar a interferência inerente ao canal de
49
comunicação, são criados valores aleatórios representando um ruído branco. Esta forma de
modelar o canal é compatível com a maior parte das situações possíveis. Um ruído branco é
representado como uma função estatística gaussiana de média zero. Já a amplitude da
interferência do canal é controlada pela simulação de forma a estimular o sistema em diversas
condições.
O demodulador faz uma primeira estimativa dos valores recebidos. Finalmente, os dados
são inseridos no decodificador, que, por sua vez, realiza a decodificação dos dados. Uma das
medidas de desempenho consiste na porcentagem dos bits decodificados erroneamente, quando
comparados com a sequência original. Outro parâmetro interessante e bastante usado é o erro
de frame (Frame Error Rate – FER ou Block Error Rate – BLER), em que apenas um bit
errado implica que todos os dados estão comprometidos.
O tipo de modulação é prevista pela especificação, podendo ser BPSK (Binary Phase Shift
Keying), QPSK (Quadrature Phase Shift Keying), 16QAM (Quadrature Amplitude
Modulation) e 64QAM. Os diferentes esquemas de modulação permitem enviar mais bits em
um mesmo canal de comunicação. O aumento da quantidade de informação enviada reduz a
robustez do sistema, já que o demodulador tem menos margem para a detecção do símbolo,
sendo portanto mais suscetível ao ruído. O diagrama de constelações de cada um dos esquemas
de modulação evidencia esta relação, como ilustrado na Figura 31.
Figura 31: Diagrama de Constelação dos Esquemas de Modulação
No ambiente de simulação, esta operação se baseia apenas no mapeamento dos bits de saída
do codificador para os símbolos referentes ao esquema de modulação pretendido. Para a
aferição do desempenho atingido, dois componentes são testados: o esquema de modulação e o
ruído inserido. O desempenho é medido com base nessas duas variáveis. Quanto mais distantes
os símbolos são representados, mais imunes ao ruído, e portanto, melhor o desempenho do
decodificador.
Uma análise importante se refere à resposta para cada modulação em relação ao nível de
ruído inserido, ou seja, a imunidade ao ruído propiciada por cada esquema de modulação. Para
50
isso, o gráfico da Figura 32 mostra a resposta de cada esquema de modulação ao ruído, tendo
sido fixado o número de iterações e o tamanho do bloco:
Figura 32: Resultado do FER (ou BLER) vs SNR
Pode-se notar claramente a diferença entre os esquemas de modulação, tornando a escolha
da modulação dependente da quantidade de ruído mensurado para o canal de comunicação.
O sinal é então demodulado em um esquema de cálculo da maior probabilidade, entregando
um valor ponderado (soft-bits). Esta operação tenta reproduzir de forma simplificada o
funcionamento do decodificador MIMO, sem as melhorias geradas pelo uso de múltiplas
antenas. Estes valores que são tomados como entrada para o decodificador sendo calculados
apenas para a simulação do sistema, não representando o bloco que realmente será integrado ao
decodificador.
O bloco responsável pela detecção dos valores recebidos é também chamado de LLR já que
faz uma estimativa, entregando uma probabilidade logarítmica. Para isso, este bloco recebe os
valores complexos do sinal e gera os novos sinais de probabilidade logarítmica.
O bloco do interleaver foi realizado de forma a utilizar as otimizações previstas para o
cálculo sequencial dos valores como mostrado pelas equações (42) a (45). Assim, o hardware
fica na forma mostrada abaixo:
51
Figura 33: Arquitetura do Interleaver
52
Neste caso, o interleaver irá calcular os valores de posição dos dados em uma sequência
crescente (quando usada para o processamento da probabilidade de estados direta), assim como
na sequência decrescente (para o cálculo de ). Estas funções devem ser realizadas pelo mesmo
hardware devido à inicialização no caso de se fazer na ordem decrescente. Porém, como
descrito anteriormente, o processamento se iniciará pela probabilidade , o que leva à operação
do interleaver a começar um ciclo antes, de forma a completar o cálculo até o fim, para deixar
o sistema no estado adequado.
A operação do interleaver é feita em duas etapas. Na primeira, o acúmulo da constante
representando a componente ((( ( ) ) ) ) da equação (45). Este
registrador é inicializado com o valor de para representar estes componentes na equação
(45), já que este valor deve ser adicionado em todos os ciclos de cálculo.
A segunda etapa de processamento, representada na Figura 33, realiza a parte incremental
do valor do acumulador com o endereço anterior calculado pelo interleaver. Alguns
comparadores e subtratores (soma para a operação decrescente) são usados para a operação de
módulo.
Como citado anteriormente, alguns sinais foram inseridos para facilitar a tarefa de controle
da camada física do LTE, bem como tornar o ambiente do IP mais controlável. Desta forma, o
decodificador tem suas entradas e saídas como ilustrado na Figura 34.
53
Figura 34: Representação das Interfaces do Bloco do Decodificador
A Figura 34 apresenta todos os sinais de entrada e saída do turbo-decoder. Alguns sinais
genéricos, como a entrada do relógio e o reset do sistema, são apresentados no topo. Os sinais
de hadshaking são os controles para a comunicação entre blocos. O sinal sink_sop (sink start of
operation) representa o momento de início do recebimento de dados. Este sinal vai tomar o
valor lógico 1 apenas no começo da operação de cada bloco de processamento. Já o sink_valid
fica em estado alto por todo o período em que valores de entradas válidos são apresentados nas
entradas de dados. O sink_ready é um sinal que permite um bloco parar o processamento do
bloco anterior, de forma a não permitir que nenhum novo dado seja recebido. No caso do turbo-
code, devido à grande latência inerente à operação, sempre que o processador esteja ocupado, o
bloco não poderá receber dados novos. Operações inversas e análogas são realizadas pelos
sinais source_sop, source_valid e source_ready.
Os sinais de parâmetros são definições passadas para cada bloco de processamento, sendo
fixas por toda a operação. O tamanho do bloco é uma das informações importantes que deve
preceder os dados. Esta informação deve ser passada para os módulos posteriores da camada
física. Como a entrada pode mudar entre um bloco e outro, para manter a coerência o tamanho
do bloco que foi processado deve ser informado. O número de iterações também é um
parâmetro necessário e definido internamente ao sistema LTE, porém fora do decodificador.
54
Finalmente, são apresentadas as interfaces de dados de processamento. As três entradas são
o sistemático e as duas de paridade, todas na forma ponderada. As saídas de dados podem ser
até oito, cada uma com a saída de cada processador.
Todo o decodificador foi descrito através da linguagem Verilog, assim como alguns outros
blocos fora do turbo-code, para facilitar a integração e o processamento.
A etapa de verificação funcional é de extrema importância para garantir o correto
funcionamento do turbo-decoder. Para esta tarefa foram usadas duas abordagens, em
momentos e com finalidades diferentes.
Inicialmente foi utilizado um ambiente de verificação semelhante ao descrito para o modelo
em Matlab. Para a realização desta tarefa, alguns conceitos básicos das novas metodologias de
verificação foram usados, como programação orientada a objetos. O ambiente foi montado
usando a linguagem SystemVerilog, que representa uma extensão do Verilog com diversas
estruturas que permitem uma programação orientada a objetos. Os resultados são baseados nos
parâmetros de BER e FER, tendo que se aproximar aos encontrados na simulação do modelo
Matlab. A estrutura montada é mostrada na Figura 35.
Figura 35: Ambiente de Verificação SystemVerilog
Na Figura 35 é representada uma arquitetura mista em que os elementos de programação
orientada a objetos se integram a blocos descritivos que modelam alguns processos que
ocorrem nos sistemas de comunicação, porém sem usar um modelo de referências devido ao
longo tempo de simulação. Os dados de verificação são gerados no bloco Driver no formato de
um pacote de dados (PKT – data_item). Os dados gerados são controlados através de variáveis
de aleatoriedade, que determinam parâmetros para a geração dos dados. O pacote de dados
inclui o tamanho do bloco a ser codificado/decodificado, o número de iterações, o tipo de
55
modulação escolhida e os bits de informação. Os dados, então, são enviados ao codificador
através de um modelo funcional do barramento (BFM – Bus Functional Model), que gera sinais
de controle e sinalização, bem como a temporização da operação. O codificador é, juntamente
ao decodificador, um dispositivo sob teste (DUT – Device Under Test), já que estes são os
blocos que realmente se deseja verificar. O BFM também desempenha a função de receber os
dados decodificados e empacotá-los, para finalmente serem comparados com a entrada. O
bloco do Checker é responsável por esta análise de desempenho, computando quantos bits
errados ainda restaram após a decodificação.
Os blocos não englobados no Agent são estruturas que simulam o comportamento do
sistema de comunicação desde a codificação até a decodificação. Os dados codificados são
modulados, passam por um bloco que simula um canal sofrendo ruído branco e os dados são
demodulados. Algumas FIFOs (First In First Out) foram utilizadas para controlar o fluxo de
dados. Esta estrutura é bastante similar à apresentada para a simulação do modelo Matlab.
Uma segunda abordagem usada na verificação do turbo-code foi a de utilizar os dados da
simulação do modelo e comparar com o comportamento do sistema projetado. O modelo
Matlab criado foi modificado para que todas as variáveis atendessem a um limite de bits.
Assim, todos os valores devem ser exatamente iguais no modelo Matlab e no RTL. Este
processo é, apesar de trabalhoso e custoso, bastante interessante para manter a coerência entre
os dois modelos. Desta forma, todas as análises de desempenho podem ser feitas em um estágio
inicial apenas com os blocos descritos em Matlab. Esta metodologia de verificação é
denominada de bitmatch devido ao fato de os resultados serem exatamente iguais (bit a bit). A
Figura 36 demonstra o modelo em Matlab integrado ao ambiente. É importante lembrar que a
geração é feita anteriormente à simulação RTL.
56
Figura 36: Ambiente de Simulação Bitmatching
Nesta arquitetura, os sinais são gerados e processados no Matlab e as entradas e resultados
são guardados em arquivos de referência. Estes valores alimentam os modelos RTL e têm os
valores finais comparados aos obtidos com o Matlab. Neste caso, apenas o decoder é
verificado. Outro ambiente específico para o codificador também foi realizado.
Com o projeto devidamente verificado, a descrição RTL finalmente é processada para
realizar a síntese.
A implementação física do projeto foi realizada na tecnologia de 65 nanômetros da
fabricante (foundry) TSMC. No caso das bibliotecas das memórias, estas, foram geradas a
partir de um sintetizador provido pela empresa fornecedora de IPs, ARM, em parceria com o
fabricante. O processo de síntese foi feito de forma a atingir os requisitos necessários. Por ser
um bloco interno à camada física, os requisitos de tempo não são críticos nas portas de entrada
e saída, porém a frequência de 120 MHz é crítica, já que algumas etapas de processamento
intenso são de difícil realização no período especificado. Este valor de frequência será discutido
com maior profundidade posteriormente. Alguns blocos de soma de valores representados com
muitos bits precisaram ser alterados para atingir o requisito de tempo.
Um processo iterativo teve que ser realizado para minimizar o número de bits das variáveis
nos caminhos críticos. Este procedimento foi realizado durante a modelagem e aprimorado
conforme a projeto foi sendo desenvolvido. No ambiente de simulação do modelo, a precisão
na representação das variáveis foi alterada e ajustada, de forma a se obter a menor área de
silício estimada, e ainda atender aos requisitos de desempenho previamente estabelecidos.
Uma etapa crítica é o planejamento do posicionamento das memórias. Como a arquitetura
proposta incorre na utilização de uma grande quantidade de memória integrada, o floorplan é
57
de extrema importância para que estas estruturas sejam corretamente posicionadas. As
memórias ocupam a maior parte da área dedicada ao decodificador, especificamente 82%. Esta
etapa de floorplanning e a ocupação do espaço pelas memórias podem ser vistas na Figura 37.
Figura 37: Floorplanning
Os espaços entre as memórias são definidas pela própria fabricante, e os espaços restantes
são as localidades onde toda a lógica envolvida será implementada, ficando o leiaute final
como ilustrado na Figura 38.
Figura 38: Leiaute do decodificador
Como pode ser percebido, as memórias representaram um grande problema na
implementação do projeto de um decodificador. Esta afirmação é ratificada por [14]:
“A situação dos turbo codes é complicada de avaliar, já que a maior parte da
complexidade do decodificador reside nos requisitos de armazenamento dos grandes
blocos que necessitam de gerenciamento e processamento das memórias. As unidades
computacionais ocupam menos de 10% da área do VLSI. Porém, processar grandes
blocos é uma necessidade requerida pela complexidade do processador.”
A Figura 37 mostra as memórias usadas para as entradas dos processadores SISO e as
memórias internas a este bloco. Estas memórias são imprescindíveis para o correto
funcionamento do sistema, já que as operações são feitas iterativamente e em etapas, os
resultados parciais tendo que ser armazenados para futuro uso. Outra necessidade é a de
58
armazenar os dados de entrada do sistema, já que estes são usados diversas vezes. Todas essas
memórias foram incluídas no leiaute final, sendo consideradas como parte do sistema do
decodificador.
Das memórias mostradas nas Figuras 37 e 38, as necessárias para armazenar os dados de
entrada do decodificador são 8 memórias de 768 posições, totalizando 6144 posições para as
informações de sistemático e de paridades. As informações armazenadas nas memórias são
representadas por 9 bits, representação esta determinada por um estudo detalhado do
comprometimento do desempenho. Com o uso em conjunto com outros blocos, especialmente o
MIMO, esta representação pode mudar. Na configuração atual, o sistema requer 24 memórias
(8 para sistemático, paridade1 e paridade2) de 768 posições e 9 bits para armazenar os dados de
entrada. Já no caso da informação extrínseca, são necessários os mesmos 9 bits para representá-
la, já que esta deve ser coerente com as outras entradas da SISO.
Os processadores SISO, como visto na Figura 22, devem armazenar o resultado do cálculo
da probabilidade reversa de estados ( ). A precisão desta variável também foi bastante
estudada, já que causa um impacto grande na implementação. Este dado também é registrado
em 8 memórias de 768 posições, porém cada palavra ocupa 12 bits. Esta quantidade e o
tamanho das memórias afetaram significativamente os resultados referentes à área obtida por
este projeto.
Ao todo, a área de silício ocupada ficou , sendo a maior parte referente às
memórias.
O consumo de potência é considerado neste projeto como um requisito básico. Isto se dá
pela flexibilidade pretendida, de forma que este bloco possa ser usado no projeto de um
dispositivo móvel, o que sugere uma economia de bateria como sendo fundamental para o
sucesso do produto. Foi feito apenas um estudo do pior caso de consumo, não levando em
consideração as otimizações possíveis na implementação.
Apenas a otimização do clock-gating foi usada durante a implementação física do projeto.
Esta técnica consiste em desligar o sinal de relógio nos flip-flops onde o sinal de enable está
presente e leva o registrador a manter o estado antigo. No caso de o sinal de enable indicar que
o valor deve ser repetido, o sinal de relógio permanece estável. O registrador dissipa energia
quando o relógio está ativo, mesmo com as entradas estáveis. Portanto, esta técnica reduz o
consumo na árvore de clock e o consumo inerente ao flip-flop, porém só atinge o consumo
dinâmico, não reduzindo o leakage presente em tecnologias com menores dimensões.
Com as geometrias dos processos encolhendo abaixo de 90 nm, a corrente de fuga
(leakage) do dispositivo cresce drasticamente [27]. Com isso, diversas otimizações podem ser
59
realizadas, como multi-Vt (células com dopagem diferente, o que diminui o leakage, sendo
contudo bem mais lentas). Outra otimização é a de Power-Shutoff, que consiste em desligar a
alimentação de partes do sistema que não estão sendo usadas momentaneamente - isto leva a
uma economia tanto de potência dinâmica como estática. Esta técnica poderia ser usada no
projeto desenvolvido, pois, nos casos em que o sistema não operasse com as 8 SISOs atuando,
as inativas poderiam ser desligadas. Estas técnicas não foram usadas devido ao grande desafio
imposto, especialmente de verificação, e a não necessidade de se ter todas as possibilidades no
estágio de desenvolvimento, mas, o pior caso de consumo. Neste caso, a potência estimada
através da análise estática é 296,2 mW.
Apesar do crescimento da potência estática, a dinâmica ainda é dominante. Uma forma de
diminuir o consumo dinâmico é simplesmente promover a diminuição da frequência do
sistema, já que existe uma relação de proporção direta entre eles. Assim a frequência de todo o
projeto da camada física foi limitada a 120 MHz. Esta escolha não é aleatória, mas ditada pela
facilidade em se conseguir essa frequência na implementação de PLLs.
A redução da frequência tanto diminui o consumo diretamente, como indiretamente
contribui para a utilização de circuitos mais lentos, que consomem menos, já que com um
requisito de tempo menor, as ferramentas podem otimizar o hardware para haver uma
economia de energia.
60
3. DISCUSSÃO DOS RESULTADOS
Para um estudo apurado da eficácia do IP desenvolvido, diversos aspectos devem ser
considerados, principalmente os que se relacionam ao desempenho na correção de erros, à área
de silício ocupada, ao consumo de potência, à frequência usada e à tecnologia utilizada. O grau
de paralelismo e o número de iterações permitidas também devem ser considerados quando se
realiza uma comparação entre as soluções encontradas.
A escassez de trabalhos realizados especificamente para o padrão LTE e as diversas
definições de projeto também dificultam um estudo comparativo detalhado. A utilização do
padrão LTE permite o uso de certas técnicas de paralelismo inexistentes em outros projetos.
Alguns resultados de desempenho foram mostrados anteriormente, e ao se fazer uma análise
comparativa deve-se aprofundar este estudo. O desempenho quanto à correção de erros foi
definido como um requisito inicial do projeto. A apuração da capacidade de correção de erros
só pode ser feita a partir de simulações, para o quê é usado o modelo em Matlab. Diversos
fatores influenciam a simulação, sendo o desempenho sempre estimado com relação a estes
parâmetros.
A capacidade de correção de erros é medida através de simulações variando os seguintes
fatores:
- Tamanho do bloco de dados a ser decodificado
- Modulação empregada
- Relação sinal/ruído
- Número de iterações
- Quantidade de bits que representa cada variável
Com exceção do último parâmetro, os outros podem ser facilmente alterados para se ter
uma análise de desempenho do projeto como em [30]. A seguir, são apresentadas algumas
análises:
I) A Figura 39 mostra os resultados das simulações usando os parâmetros definidos na
Tabela 3. Como pode ser notado, desempenho do decodificador varia dependendo
do tamanho, em bits, do bloco a ser decodificado.
No caso deste trabalho, uma particularidade com relação ao paralelismo empregado
deve ser notada, já que o sistema tem uma relação fixa entre o tamanho do bloco e o
nível de paralelismo usado, não podendo dissociar estes elementos.
Pode-se notar que quanto maior o tamanho do bloco de processamento maior é sua
eficácia em corrigir erros, devido à maior distância livre. Ou seja, o codificador é
61
mais robusto. Porém, quando existem transições entre os níveis de paralelismo, esta
relação não é seguida, já que a quebra da cadeia de decodificação causa uma
operação sobre blocos menores e mais incertezas, devido à falta de continuidade na
treliça.
Tabela 3: Parâmetros para a Simulação Variando o Tamanho do Bloco de Processamento
Parâmetro de Simulação Valor
Tamanho do bloco de processamento
(bits)
576, 672 e 768
Esquema de Modulação QPSK
Número de Iterações 5
Figura 39: Desempenho do Sistema Comparando por Tamanho de Blocos
II) A Tabela 4 exibe as especificações da simulação e a Figura 32 mostra os resultados
obtidos do desempenho em função da capacidade de correção de erros para cada
tipo de modulação possível.
62
A modulação é escolhida baseada no ruído estimado. A decodificação não será
diretamente influenciada pelo esquema de modulação, mas a estimativa inicial dos
valores recebidos através do canal será menos acurada para modulações mais
complexas.
Esquemas de modulação diferentes irão atuar em faixas de ruído. O BPSK é o mais
imune a ruídos, sendo, portanto utilizado quando o sinal está com a qualidade muito
ruim. Porém, a capacidade de envio de altas taxas de fluxo de informação é limitada.
Por outro lado, o esquema 64QAM possibilita um fluxo intenso de envio de dados,
porém é muito sensível a ruídos.
Tabela 4: Parâmetros para a Simulação Variando o Esquema de Modulação
Parâmetro de Simulação Valor
Tamanho do bloco de processamento 40
Esquema de Modulação BPSK, QPSK, 16QAM, 64QAM
Número de Iterações 6
III) Na Tabela 5 são exibidos os parâmetros de simulação e os resultados para uma
variação do número de iterações são mostrados na Figura 40. O número de iterações
é um importante parâmetro a ser observado já que afeta dois dos principais
requisitos do sistema, que são: a capacidade de correção de erros e o throughput.
Quanto mais iterações, mais refinado será o resultado, diminuindo então os
resultados errados, a melhora, contudo, não sendo linear. Porém, quanto mais
iterações, maior a demora no processamento de um bloco de dados, o que leva
consequentemente a uma queda no throughput.
Tabela 5: Parâmetros para a Simulação Variando o Número de Iterações
Parâmetro de Simulação Valor
Tamanho do bloco de processamento 768
Esquema de Modulação QPSK
Número de Iterações 5, 6, 7, 8
63
Figura 40: Desempenho do Sistema Comparando os Resultados com Diferentes Valores de Iteração
Os resultados esperados e descritos em [30] podem ser comprovados através dos gráficos
mostrados nas Figuras 32, 39 e 40. Estas análises são importantes para estabelecer um
parâmetro de comparação. Outros trabalhos encontrados na literatura têm resultados diversos e
muitas vezes negligenciam a apresentação destes dados, o que dificulta a tarefa de comparação.
A próxima seção tem como objetivo a comparação entre os resultados encontrados neste
trabalho com outros existentes na literatura.
3.1. ESTUDO COMPARATIVO
A validação do projeto realizado deve ser feita comparando-se a solução encontrada com
outros trabalhos encontrados na literatura. Porém, devem-se levar em consideração os objetivos
estabelecidos para cada projeto.
Como discutido anteriormente, existem muitos fatores que influenciam a implementação do
decodificador turbo-code, tornando assim a comparação mais complexa. Devido à escassez de
trabalhos voltados diretamente à arquitetura LTE, muitos autores acabam por fazer
comparações entre decodificadores de padrões diferentes. Outra dificuldade ocorre devido à
64
diferença de tecnologia empregada na implementação física do projeto. Como dito
anteriormente, o desempenho com relação à capacidade de correção de erros também acaba
tornando este estudo mais complexo.
As principais variáveis diretas abordadas na comparação e que influenciam na mesma são:
a área de silício ocupada, o throughput e o consumo de potência. Estes parâmetros são
diretamente relacionados com definições iniciais do projeto, como, por exemplo, a frequência
de operação, a tecnologia usada, nível de paralelismo, desempenho com relação à correção de
erros. Este desempenho, por sua vez, é influenciado pela quantidade de iterações usadas e pela
precisão das variáveis (quantidade de bits).
Os trabalhos mais relevantes, bem como seus resultados são mostrados na Tabela 6.
Tabela 6: Tabela Comparativa entre o Decodificador Proposto e Congêneres
Referência [31] [32] [33] [34] [35] [36] Proposto
Algoritmo MAP LogMAP Max-Log
MAP¹
Max-Log
MAP¹ - LogMAP
Max-Log
MAP LogMAP
Níveis de
Paralelismo 64 4/8 8 1/2/4/8 32 8 1/2/4/8
Iterações 6 5,5 8 8 6 8 8
Frequência (MHz) 400 302 300 275 200 250 120
Throughput (bit/s) 1,28 G 100 M 150 M 129 M 711 M 100 M 75 M
Tecnologia (nm) 65 130 65 90 65 130 65
Área (mm²) 8,3 3,57 2,1 2,1 - 10,7 6,7
Consumo de
Potência (mW) 845 69 300 219 - - 296,2
¹ Estas arquiteturas usam uma melhoria do algoritmo Max-Log MAP tradicional com o esquema de fator de escala
extrínseco (extrinsic scaling factor – ESF)
Algumas análises podem ser extraídas dos dados mostrados na Tabela 6. É importante
ressaltar que estes resultados não são mostrados com relação à capacidade de correção de erros.
Os trabalhos mostram uma diversidade de algoritmos empregados, dividindo-se entre a
opção LogMAP, Max-Log MAP e o Max-Log MAP modificado pela técnica de fator de escala
extrínseco. O algoritmo modificado reduz o fator de correção, em cada estágio de
processamento, por uma escala no valor da informação extrínseca, incorrendo em uma perda
baixa de desempenho. A grande vantagem seria a redução da operação da inclusão do fator de
correção. Como as operações não foram uma parte crítica do projeto, esta otimização não se faz
necessária, sendo adotada apenas por alguns autores e não sendo uma solução universal.
65
O nível de paralelismo, como discutido anteriormente, afeta diretamente a latência e,
consequentemente, o throughput do sistema, já que divide operações longas em várias menores.
Neste caso, deve ser levada em consideração a perda de desempenho ocasionada pelo
processamento sobre blocos menores. Para blocos maiores esta perda é menos sentida, já que
estas configurações já têm uma melhor resposta na redução de erros. Assim, apenas trabalhos
que visam taxas de throughput muito altas usam mais níveis de paralelismo. Tais requisitos só
se fazem necessários em projetos voltados para estações rádio-base, que não é o caso do
trabalho discutido neste texto.
O número de iterações está diretamente ligado ao requisito da capacidade de correção de
dados e ao throughput. Quanto mais iterações o sistema permitir, maior a capacidade de
correção de erros. Contudo, há um momento em que o ganho associado não representa uma
vantagem se comparado com a latência inserida. Um estudo deve ser feito para atingir os
requisitos de correção de erros, sem violar o throughput especificado.
A frequência de operação do turbo-code é uma variável bastante importante, uma vez que
afeta muitos dos requisitos do sistema. A relação mais óbvia é com o throughput, já que um
aumento na frequência ocasiona um processamento mais rápido sobre um mesmo bloco de
dados. Com isso, ocorre um maior consumo de potência associado, pois estas variáveis tem
relação direta entre si.
Um aumento na frequência também tem um impacto na área ocupada pelo projeto devido às
células utilizadas para realizar uma mesma operação lógica. Existem células padrão de uma
biblioteca que podem realizar uma mesma função, porém com características físicas diferentes.
Células menores são mais lentas e consomem menos energia. Assim, ao se operar em
frequências muito elevadas, a síntese requer células mais rápidas, portanto maiores e menos
eficientes no consumo.
Como descrito anteriormente, este trabalho foi especificado para fazer parte de um projeto
da camada física do padrão LTE, portanto a frequência tem que ser compatível com o proposto
para o projeto completo. A frequência poderia ser alterada para melhorar o throughput, já que
esta relação é praticamente linear. Para o dobro da frequência, o throughput cresceria na mesma
proporção. Devido à relação com outros blocos, foi adotado o relógio com uma frequência de
120 MHz. Portanto, efetuando um escalamento de frequências, pode-se verificar que o
throughput atingido neste trabalho é da mesma ordem do throughput de trabalhos similares.
A área de silício ocupada por um projeto é um parâmetro importante na análise do IP do
turbo-code. Isso se dá pelos problemas causados por circuitos integrados muito grandes. E,
66
considerando-se que o turbo-code é apenas um dos blocos constituintes da camada física do
LTE, o tamanho do IP é bastante importante para uma solução ótima.
Circuitos integrados muito grandes sofrem com diversos problemas, como o
encapsulamento, a alimentação e principalmente a porcentagem de chips perfeitos (no que se
refere a defeitos de manufatura. Esses fatores influenciam no grau de dificuldade do projeto da
placa bem como no preço unitário do circuito integrado.
A área deste projeto de decodificador turbo-code está diretamente relacionada com o
desempenho na correção de erros, pois a área das memórias representa mais de 80% de todo o
IP. Estas memórias devem representar os dados de entrada, a informação extrínseca e uma das
probabilidades de estados. A precisão destas variáveis irá afetar tanto a área da memória quanto
o desempenho.
Este trabalho teve como objetivo original atingir um desempenho na correção de erros
superior aos trabalhos existentes na literatura, a área acabou sendo maior que a esperada
inicialmente. Porém, fazendo-se uma comparação com [32], percebe-se o uso de variáveis com
uma precisão muito inferior, o que resultará em uma queda de desempenho. Contudo, esta
análise não é simples, pois não são explicitados todos os parâmetros de simulação. O mesmo
ocorre para [33]. Por outro lado, [34] não revela dados suficientes para a comparação das
variáveis internas ao projeto.
67
4. CONCLUSÃO
O trabalho mostrou uma arquitetura proposta para o sistema turbo-code aplicada ao padrão
LTE. Foi realizada uma descrição do padrão, porém limitando-se ao tema da codificação de
canal.
O trabalho está inserido no âmbito de um projeto completo da camada física do padrão
LTE, visando a criação de um IP específico.
Para contextualizar o trabalho, foi realizada uma perspectiva histórica, desde o teorema de
Nyquist [38], que limita a taxa de amostragem, passando pelos trabalhos de Shannon [39], que
estabelecem o limite teórico do canal e os sistemas de correção de erros que perseguem este
limite, e chegando, finalmente, ao turbo-code, que apresenta um desempenho muito próximo
do limite.
Também foi mostrado o fluxo de projeto digital que foi seguido neste trabalho. Neste caso,
o embasamento teórico vem em conjunto com o conhecimento prático para a realização de
circuitos integrados em silício. Começou-se pela descrição RTL, tendo na verificação uma
importante ferramenta, e concluiu-se com a implementação física. O nível de detalhamento não
foi muito alto devido ao escopo limitado do trabalho.
Finalmente, as etapas desenvolvidas foram apresentadas. Foi dado um enfoque especial na
arquitetura do hardware, pois, é esta a grande diferenciação entre este e outros trabalhos.
Algumas etapas auxiliares se destacam, como a verificação e a criação de um modelo de
referência, no qual as ideias das arquiteturas puderam ser testadas antes da implementação.
Os resultados foram então comparados com outros trabalhos encontrados na literatura
corrente. Esta análise se mostrou complicada devido aos diferentes parâmetros que cada
trabalho assume. Porém, os resultados foram satisfatórios dentro dos requisitos propostos,
principalmente devido à grande capacidade de correção de erros.
Este projeto se mostrou superior a todos os que puderam ser comparados com relação à
capacidade de correção de erros, contudo, este ganho de desempenho causa uma deterioração
dos outros parâmetros de comparação. Ainda assim, o projeto apresentou características
similares ou superiores a outros trabalhos. Como se propôs ter uma alta fidelidade na correção
de erros, os outros parâmetros foram otimizados de forma a que esse não se deteriorasse. A área
de silício ocupada é diretamente afetada, já que para uma maior capacidade de correção, as
operações são feitas em uma precisão mais elevada, consequentemente, maior a área ocupada.
A latência também é afetada indiretamente através no número de iterações. Quanto mais
68
iterações, mais preciso o resultado, elevando consequentemente o tempo de espera para o
cálculo.
Outro fator importante na comparação foi a frequência de operação do decodificador. Como
este projeto foi pensado para ser inserido em um contexto maior, integrado a outros blocos da
camada física do padrão LTE, a velocidade de funcionamento teve que obedecer a um valor
específico, inferior ao utilizado pelos outros trabalhos descritos na literatura. Este parâmetro
tem uma relação praticamente linear com o throughput e a latência, fatores estes, fundamentais
para a comparação de resultados.
4.1. PROPOSTA DE TRABALHOS FUTUROS
Apesar do êxito alcançado para o desempenho do sistema, o projeto, por se tratar de um IP,
poderia ter uma maior flexibilidade com relação à utilização de mais otimizações, em
detrimento de uma queda no desempenho a ser avaliada pelo possível usuário. Assim, o
desempenho, dependendo da aplicação, poderia não ser o objetivo principal, mas um hardware
menor ou com um maior throughput.
Uma análise interessante para medir o desempenho do sistema é a integração dele com os
blocos mais próximos, o que permite uma visão mais ampla do funcionamento do circuito
integrado e da capacidade de correção de erros. Os principais blocos são o Rate Matching, que
trata de ajustar o número de bits de acordo com a taxa de codificação necessária, para isso
retirando ou repetindo os bits originais. Outro bloco interessante é o MIMO, que é o
responsável pela recepção dos dados através de múltiplas antenas. Assim, a análise fica mais
completa, já que adiciona a melhora de desempenho proveniente do MIMO.
69
6. REFERÊNCIAS BIBLIOGRÁFICAS
[1] - Dahlman, E., Parkvall, S., Sköld, J., Beming, P., “3G Evolution HSPA for Mobile
Broadband”, Second Edition, Academic Press - Elsevier, 2008
[2] – Cox, C., “An Introduction to LTE – LTE, LTE Advanced, SAE and 4G Mobile
Communications”, John Wiley and Sons, 2012
[3] – Sesia, S., Toufik, I., Baker, M., “LTE The UMTS Long Term Evolution – From Theory to
Practice”, Wiley, 2009
[4] – Proakis, J. G., “Digital Communications”, Fourth Edition, McGraw-Hill, 2000
[5] – Sklar, B., “Digital Communications – Fundamentals and Application”, Second Edition,
Prentice Hall P T R, 2000
[6] – Haykin, S., “Communication Systems”, Fouth Edition, John Wiley and Sons, 2001
[7] – André de Amaral Araújo, Paulo Bastos Tigre, Sérgio Bampi, Sérgio Francisco Alves
Márcio Wohlers de Almeida, “Programa Nacional de Microeletrônica – Contribuições para a
Formulação de um Plano Estruturado de Ações”, Secretaria de Política de Informática –
Ministério de Ciências e Tecnologia, Brasília 2002.
[8] – Reis, V. T., Souza, I. S., “A 65nm VLSI Implementation for the LTE Turbo Decoder”,
2011, Proceedings of the 24th
Symposium on Integrated Circuits and Systems Design, SBCCI,
pp, 155 - 160
[9] IEEE Annals of the History of Computing, Vol. 20, No. 2, 1998
[10] P.M. César, “Breve Introdução à Teoria dos Códigos Corretores de Erros”, Colóquio de
Matemática da região Centro-Oeste, Novembro 2009.
[11] P. Elias, “Coding for noisy channels”, IRE Conv. Rec., pt. IV, pp. 37-46, 1955
[12] P. Elias, “Error-free Coding”, IRE Professional Group on Information Theory, vol. 4,
issue 4, pp. 29-37, 1954
[13] A. J. Viterbi, “Error Bounds for Convolutional Codes and an Assymptotically Optimum
Decoding Algorithm”, 1967, IEEE Transactions on Information Theory 13 (2): 260–269.
[14] C. B. Schlegel, L. C. Pérez, “Trellis and Turbo Coding”, 2004, IEEE Press: John Wiley
and Sons
70
[15] L.Bahl, J.Cocke, F.Jelinek, and J.Raviv, "Optimal Decoding of Linear Codes for
minimizing symbol error rate", IEEE Transactions on Information Theory, vol. IT-20(2),
pp.284-287, March 1974.
[16] P. Robertson, P. Hoe her, E. Villenbrun, “Optimal and Sub-Optimal Maximum a
Posteriori Algorithms Suitable for Turbo Decoding”, Eur. Trans. Telecommun., Vol. 8, pp.
119-125, March/April 1997
[17] C. Berrou, A. Glavieux, and P.Thitimajshima, “Near Shannon limit error-correcting
coding and decoding: Turbo-codes” in Proc. ICC ‟93, pp. 1064-1070, May 1993.
[18] “3GPP TS 36.212 version 9.1.0 Release 9”, 3GPP
[19] “Fundamentals of Turbo Codes”, Bernard Sklar
[20] Dobkin, R., Peleg, M., Ginosar, R., “Parallel VLSI Architecture for MAP Turbo Decoder”
in PIMRC, pp. 384-388, 2002.
[21] Nimbalker, A., Blankenship, Y., Classon, B., Blankenship, T. K., “ARP and QPP
Interleavers for LTE Turbo Coding” WCNC proceedings, 2008.
[22] Dobkin, R., Peleg, M., Ginosar, R., “Parallel Interleaver Design and VLSI Architecture for
Low-Latency MAP Turbo Decoders”, IEEE Transactions on Very Large Scale Integration
(VLSI) Systems, Vol. 13, nº 4, Abril 2005.
[23] D. A. Guimarães, “Noções sobre Decodificação Turbo: Um Estudo de Caso para os
Códigos SPC-TPC”, Departamento de Telecomunicações – Inatel.
[24] M. Keating, P. Bricaud, “Reuse Methodology Manual – For System-on-a-Chip Designs”
Kluwer Academic Publishers, 3ª Edição, 2002
[25] N. Weste, D. Harris, “CMOS VLSI Design – A Circuit and Systems Perspective”, Pearson
Education, 3ª Edição, 2005
[26] “Digital VLSI Systems Design – A Design Manual for Implementation of Projects on
FPGA and ASIC Using Verilog”, S. Ramachandran, 2007, Springer
71
[27] “VLSI Circuit Design Methodology Demystified – A conceptual Taxonomy”, Liming Xiu,
Wiley-Interscience, 2007
[28] Bob Zeidman, Verilog Designer‟s Library, Prentice Hall. 1999
[29] Stephen Brown and Zvonko Vranesic, “Fundamentals of Digital Logic with VHDL
Design”, McGraw Hill, 2005
[30] Huahua, W. and Wenwen, L., “Analysis of Turbo Decoding Algorithm in LTE System”,
9th
International Conference on Fussy Systems and Knowledge Discovery, 2012
[31] Sun, Y., Cavallaro, J. R., “Efficient hardware implementation of a highly-parallel3GPP
LTE/LTE-advance turbo decoder”, INTEGRATION, the VLSI journal, Elsevier, 2011
[32] Studer, C., Benkeser, C., Belfanti, S., Huang, Q., “Design and Implementation of a Parallel
Turbo-Decoder ASIC for 3GPP-LTE”, IEEE Journal of Solid-State Circuits, Vol. 46, Nº 1,
January 2011
[33] May, M., Ilnseher, T., When, N., Raab, W., “A 150Mbit/s 3GPP LTE Turbo Code
Decoder”, Design, Automation & Test in Europe Conference & Exhibition (DATE), 2010.
[34] Wong, C. C., Lee, Y. Y., Chang, H. C., “A 188-size 2.1 mm² Reconfigurable Turbo
Decoder Chip with Parallel Architecture for 3GPP LTE System”, Symposium on VLSI Circuits
Digest of Technical Papers, 2009
[35] Sun, Y., Zhu, Y., Goel, M., Cavallaro, J. R., “Configurable and Scalable High Throughput
Turbo Decoder Architecture for Multiple 4G Wireless Standards”, IEEE International
Conference on Application-Specific Systems, Architectures and Processors (ASAP), 2008
[36] Kim, J. H., Park, I. C., “A Unified Parallel Radix-4 Turbo Decoder for Mobile WiMAX
and 3GPP-LTE”, IEEE Custom Integrated Circuits Conference (CICC), 2009
[37] Souza, I. S., Reis, V. T., “A VLSI Design for The LTE Turbo Decoder“, 2012, Journal of
Integrated Circuits and Systems, JICS, Vol. 7, nº 1, pp, 16 - 22
[38] Nyquist, H., “Certain Topics in Telegraph Transmission Theory“, 1928, Transactions of
the American Institute of Electrical Engineers, Vol. 47, Issue 2, pp, 617 - 644
72
[39] Shannon, C. E., “A Mathematical Theory of Communication“, 1948, The Bell System
Technical Journal, Vol. 27, pp, 379 - 423
[40] Hamming, R. W., “Error Detecting and Error Correcting Codes“, 1950, The Bell System
Technical Journal, Vol. 29, pp, 147 - 160
[41] Golay, M. J. E., “Notes on Digital Coding“, 1949, Proc. IRE, 37, pp, 567
