Implementação de um Codificador LDPC para um Sistema de …

Fábio Lumertz Garcia

Implementação de um Codificador LDPC para um Sistema de TV Digital usando Ferramentas de

Prototipagem Rápida

Dissertação apresentada à Faculdade de Engenharia Elétrica e Computação como parte dos requisitos exigidos para a obtenção do título de Mestre em Engenharia Elétrica. Área de concentração: Telecomunicações e Telemática. Orientador: Prof. Dr. Dalton Soares Arantes Co-orientador: Dr. Fabbryccio A. Cardoso

Campinas, SP 2006

ii

FICHA CATALOGRÁFICA ELABORADA PELA BIBLIOTECA DA ÁREA DE ENGENHARIA E ARQUITETURA - BAE - UNICAMP

G165i

Garcia, Fábio Lumertz Implementação de um codificador LDPC para um sistema de TV digital usando ferramentas de prototipagem rápida / Fábio Lumertz Garcia. --Campinas, SP: [s.n.], 2006. Orientadores: Dalton Soares Arantes, Fabbryccio Akkazzha Chaves Machado Cardoso. Dissertação (Mestrado) - Universidade Estadual de Campinas, Faculdade de Engenharia Elétrica e de Computação. 1. Televisão digital. 2. Códigos de controle de erros (Teoria da informação). 3. FPGA. I. Arantes, Dalton Soares. II. Cardoso, Fabbryccio Akkazzha Chaves Machado. III. Universidade Estadual de Campinas. Faculdade de Engenharia Elétrica e de Computação. IV. Título.

Título em Inglês: Implementation of an LDPC encoder for a digital TV system using rapid prototyping tools.

Palavras-chave em Inglês: Digital television, Error-correcting codes (Information theory), Field programmable gate arrays.

Área de concentração: Telecomunicações e Telemática Titulação: Mestre em Engenharia Elétrica Banca examinadora: Renato Baldini Filho, José Raimundo de Oliveira e Maria Cristina

Felippetto de Castro. Data da defesa: 21/12/2006.

iii

Fábio Lumertz Garcia

Implementação de um Codificador LDPC para um Sistema de TV Digital usando Ferramentas de

Prototipagem Rápida

Dissertação apresentada à Faculdade de Engenharia Elétrica e Computação como parte dos requisitos exigidos para a obtenção do título de Mestre em Engenharia Elétrica. Área de concentração: Telecomunicações e Telemática. Banca Examinadora: Prof. Dr. Dalton Soares Arantes – UNICAMP Prof. Dr. Renato Baldini Filho – UNICAMP Prof. Dr. José Raimundo de Oliveira – UNICAMP Profa. Dra. Maria Cristina Felippetto de Castro – PUCRS

Campinas, SP 2006

iv

Resumo

O objetivo deste trabalho é apresentar as diversas etapas de implementação de um codificador

LDPC para um sistema de televisão digital, desenvolvido através do emprego de algumas

tecnologias inovadoras de prototipagem rápida em FPGA. O codificador implementado foi

baseado em um código LDPC eIRA, que consiste em uma classe estendida de códigos de

repetição e acumulação irregulares, com palavra-código de 9792 bits e taxa de 3/4. Visando

agregar outras tecnologias emergentes ao projeto de TV Digital, o sistema proposto foi

desenvolvido para operar sobre o Protocolo de Internet - IP. Os esforços para a realização deste

trabalho fizeram parte de um esforço mais amplo de um consórcio de universidades brasileiras,

visando à concepção, ao projeto, à simulação e à implementação em hardware de um Sistema de

Modulação Inovadora para o SBTVD. A grande sinergia obtida neste projeto e o uso intensivo

de ferramentas de prototipagem rápida em FPGA possibilitaram a obtenção de uma prova de

conceito implementada e testada em um prazo de apenas 12 meses.

Palavras-chave: LDPC, FPGA, System Generator, Prototipagem Rápida.

Abstract

This work presents the several phases in the implementation of an LDPC encoder for a digital

television system, developed using innovative technologies for rapid prototyping on Field

Programmable Gate Array devices - FPGAs. The implemented encoder was based on an eIRA -

extended Irregular Repeat Accumulate - LDPC code with codeword-length equal to 9792 bits and

rate 3/4. The proposed system was developed to work with video streaming over the Internet

Protocol- IP. This work is part of a more ambitious project that resulted in the development of an

advanced Modulation System for the Brazilian Digital TV System - SBTVD.

Key-Words: LDPC, FPGA, System Generator, DSP Rapid Prototyping.

v

Agradecimentos

Primeiramente ao Bom Deus, fonte de todo bem, toda felicidade e toda sabedoria. Sem Ele nada

teria sentido, nem mesmo a busca do conhecimento.

Ao meu orientador, professor Dr. Dalton Arantes, pelas suas orientações, tanto as profissionais

quanto as pessoais. Faço uso destas poucas linhas para expressar minha gratidão e estima.

À minha família. Agradeço à minha mãe e aos meus irmãos pelo amor e pela presença. Apesar de

longe, nunca estivemos separados. Especialmente, agradeço à Valéria que tem sido meu porto

seguro nestes últimos anos.

Ao meu co-orientador, ao qual tenho o privilégio de chamar de amigo, Dr. Fabbryccio Cardoso.

Deus permita que eu possa um dia adquirir um pouco de sua humildade e boa vontade.

Ao meu colega, Tarciano Pegoraro, pela ajuda nas implementações e auxílio nos estudos de

codificação.

Aos colegas do laboratório ComL@b e aos companheiros de muitos almoços no RA.

À minha amiga Adriane Sartori, pela amizade desde a primeira viagem de Porto Alegre a

Campinas e pelo companheirismo, principalmente nas dificuldades do primeiro ano...

A todas as senhoras que lavaram minha roupa, limparam minha casa e prepararam minhas

refeições durante estes anos.

vi

Por último, mas não em último, aos amigos do Rio Grande do Sul. Agradeço a amizade apesar da

distância.

Ao Conselho Nacional de Desenvolvimento Científico e Tecnológico (CNPq), Financiadora de

Estudos e Projetos (Finep), bem como à Fundação de Amparo à Pesquisa do Estado de São Paulo

(Fapesp) pelo apoio financeiro e material.

vii

“Não tenhas medo homem querido. Anima-te! Sim, anima-te! Coragem!”

Daniel 10,19

viii

Sumário

Lista de Figuras .......................................................................................................................xi

Lista de Tabelas .....................................................................................................................xiv

Lista de Variáveis ...................................................................................................................xv

Lista de Siglas e Abreviações..............................................................................................xviii

1. Introdução .............................................................................................................................1

1.1 A Importância das Ferramentas de Prototipagem Rápida nas Soluções de DSP .......1

1.2 Contextualização Política e Temporal da Dissertação ................................................8

2. Tecnologias para Implementação de Sistemas em FPGAs .............................................11

2.1 Introdução as FPGAs.................................................................................................11

2.1.1 Introdução, Conceitos Fundamentais e Origem das Tecnologias .................11

2.1.2 Arquiteturas e Configurações .......................................................................23

2.1.3 Formas de Desenvolvimento e Implementação ............................................31

2.1.3.1 Linguagem Esquemática ..................................................................31

2.1.3.2 Linguagem de Descrição de Hardware (HDL) .................................34

2.1.3.3 Linguagem C, SVP e DSP ................................................................37

2.1.4 Principais Fornecedores e Parceiros .............................................................40

2.2 ISE Design Flow e System Generator .......................................................................42

2.2.1 Project Navigator ..........................................................................................42

2.2.2 System Generator .........................................................................................48

2.2.3 Simulação HDL ............................................................................................52

ix

2.3 AccelChip (AccelDSP) e AccelWare ........................................................................53

2.3.1 AccelChip (AccelDSP) .................................................................................53

2.3.2 AccelWare e Núcleos de Propriedade Intelectual (NPIs ou IP Cores) .........60

3. O Sistema de TV Digital sobre IP .....................................................................................63

3.1 Vídeo Bruto ..............................................................................................................64

3.2 Codificador/Decodificador de Vídeo .......................................................................65

3.3 Empacotador UDP/IP ...............................................................................................68

3.4 Conversor Camada MAC .........................................................................................70

3.5 Aleatorizador/Desaleatorizador ................................................................................71

3.6 Codificador/Decodificador Reed-Solomon ..............................................................71

3.7 Codificador/Decodificador LDPC ...........................................................................72

3.8 Mapeador/Demapeador e LLR .................................................................................72

3.9 Modulador/Demodulador e Alamouti ......................................................................74

3.10 Conversores A/D e D/A ..........................................................................................77

3.11 Conversores Elevador e Rebaixador ......................................................................78

3.12 Amplificador de Potência .......................................................................................79

3.13 Amplificador de Baixo Ruído e Controle Automático de Ganho ..........................79

4. Codificação LDPC ..............................................................................................................81

4.1 Introdução à Codificação de Canal............................................................................81

4.2 Reed-Solomon ...........................................................................................................86

4.3 LDPC.........................................................................................................................89

4.3.1 Codificação ...................................................................................................95

4.3.2 Decodificação ...............................................................................................97

5. Implementação do Codificador LDPC .............................................................................99

5.1 Codificador LDPC.....................................................................................................99

5.1.1 Estrutura da Codificação ...............................................................................99

5.1.2 Implementação em System Generator.........................................................101

5.2 Descrição do Hardware Empregado ........................................................................105

5.3 Detalhamento da Implementação do Sistema..........................................................111

6. Resultados, Demonstrações e Comparações ..................................................................119

6.1 Quanto ao Desempenho e Comprimento do Código LDPC....................................119

6.2 Comparações de Modelos de Implementação .........................................................121

6.2.1 System Generator Versus AccelChip ..........................................................121

x

6.2.2 System Generator Versus VHDL ................................................................122

6.2.3 Otimização em Área Versus Otimização em Velocidade ...........................124

6.3 Demonstrações de Ocupação dos Dispositivos .......................................................125

7. Considerações Finais e Trabalhos Futuros ....................................................................129

Referências Bibliográficas ...................................................................................................131

Apêndice A ...........................................................................................................................135

xi

Lista de Figuras

1 – Diagrama temporal das tecnologias relacionadas com FPGAs.........................................16

2 – Arquitetura de arranjo de células básicas com canais.......................................................18

3 – Estrutura genérica de um ASIC estruturado......................................................................20

4 – Configuração de um ASIC com FPGA associada...............................................................22

5 – Visão intercamada da FPGA................................................................................................24

6 – Diagrama esquemático de descrição de hardware.............................................................31

7 – Netlist ao nível de portas lógicas...........................................................................................32

8 – Níveis de abstração de um modelo HDL genérico..............................................................34

9 – Design Flow da Xilinx............................................................................................................42

10 – Etapa de descrição do Design Flow da Xilinx...................................................................43

11 – Interface da ferramenta Project Navigator da Xilinx......................................................44

12 – Interface da ferramenta IMPACT.....................................................................................47

13 – Browser das bibliotecas do Simulink mostrando os toolboxes da Xilinx........................49

14 –Fluxo de desenvolvimento a partir do System Generator até a etapa de download na

FPGA............................................................................................................................................51

15 – Fluxo de desenvolvimento da ferramenta AccelChip (Accel DSP).................................53

16 – Interface do AccelChip para definição das ferramentas utilizadas................................55

17 – Interface do AccelChip mostrando a tabela de quantização...........................................56

18 – Interface do AccelChip mostrando o recurso de exportação para o System

Generator......................................................................................................................................57

19 – Interface do AccelChip mostrando o relatório final de desenvolvimento......................58

20 – Seleção de parâmetros da FFT do AccelWare..................................................................60

21 – Diagrama de blocos do sistema de televisão digital proposto..........................................62

xii

22 – Quadro MAC.......................................................................................................................69

23 – Mapeamento feito para a modulação QPSK.....................................................................72

24 – Mapeamento feito para a modulação 16QAM..................................................................73

25 – Diagrama de blocos de um sistema de comunicação digital............................................79

26 – Demonstração de um código de bloco binário sistemático θ(4,3)....................................81

27 – Polinômios associados às palavras-código.........................................................................84

28 – Codificação )16,20(RS com 8=rsm ......................................................................................86

29 – Exemplo de matriz de paridade H.....................................................................................88

30 - Exemplo de gráfico de Tanner............................................................................................89

31 – Diagrama simplificado do codificador LDPC...................................................................94

32 – Esquema de troca de mensagens dos nós de bit para os nós de cheque (esquerda)

e dos nós de cheque para os nós de bit (direita)........................................................................95

33 – Modelo de referência da implementação do codificador LDPC...................................100

34 – Bloco do codificador LDPC em detalhes.........................................................................102

35 – Placa Nallatech Xtreme DSP Development Kit-IV com cabo paralelo IV em

destaque......................................................................................................................................105

36 – Entradas dos conversores da placa Nallatech Xtreme DSP Development Kit-IV.......105

37 – Placa Xilinx ML-402..........................................................................................................107

38 – Equipamentos de RF da National Instruments..............................................................108

39 – Visão global da implementação com definições de hardware.......................................109

40 – Diagrama simplificado da implementação do ajuste de taxa........................................111

41 – Implementação do aleatorizador......................................................................................113

42 – Curva de desempenho de código LDPC em função do comprimento do código.........116

43 – Curva característica de um código LDPC em função do comprimento do mesmo.....117

44 – Relatório de ocupação da FPGA com o código do codificador LDPC desenvolvido em

AccelChip....................................................................................................................................118

45 – Relatório parcial de ocupação da FPGA com o código do codificador LDPC

desenvolvido no bloco M-Code do System Generator............................................................119

46 – Relatório parcial de ocupação da FPGA com o conjunto codificador LDPC

desenvolvido em VHDL.............................................................................................................120

xiii

47 – Relatório parcial de ocupação da FPGA com o conjunto codificador LDPC, com

otimização em termos de velocidade e desenvolvido em System Generator........................120

48 – Relatório parcial de ocupação da FPGA com o conjunto codificador LDPC,

otimização em termos de área e desenvolvido em System Generator...................................121

49 – Relatório parcial de ocupação da primeira FPGA empregada no protótipo. Nesta

FPGA, estão implementados o MAC Ethernet, o ajuste de taxa, o aleatorizador e o

codificador LDPC......................................................................................................................123

50 – Relatório parcial de ocupação da segunda FPGA empregada no protótipo. Nesta

FPGA, estão implementados o mapeador, o multiplexador, o modulador e Alamouti e a

inserção de prefixo cíclico.........................................................................................................123

51 – Relatório parcial de ocupação da terceira FPGA empregada no protótipo. Nesta

FPGA, estão implementados o filtro passa-baixa, o demodulador e Alamouti, o demapeador

e a LLR................................................................................................................................................................. 124

52 – Relatório parcial de ocupação da quarta FPGA empregada no protótipo. Nesta

FPGA, está implementado o decodificador LDPC.................................................................125

53 – Relatório parcial de ocupação da quinta FPGA empregada no protótipo. Nesta

FPGA, estão implementados o desaleatorizador, o ajuste de taxa e o MAC Ethernet.......125

xiv

Lista de Tabelas

2.1. Fabricantes de FPGAs ....................................................................................................39

2.2 Desenvolvedores de ferramentas completas para FPGAs ............................................40

2.3 Especialistas e desenvolvedores independentes de ferramentas para FPGAs ............40

2.4 Consultores e desenvolvedores especiais de ferramentas para FPGAs.......................41

xv

Lista de Variáveis A - Conjunto de alfabeto-código; Amap - Conjunto de símbolos ou alfabeto do mapeador; a - Número de linhas da submatriz M em um código LDPC; b - Número de colunas da submatriz M em um código LDPC; C - Conjunto de palavras-código; c - Palavra-código;

ic - I-ésimo bit da palavra-código c; dv - Maior grau de nós de bit em um código LDPC; DC – Nível contínuo de sinal; dc - Maior grau de nós de cheque em um código LDPC; GF – Corpo de Galois; G - Matriz geradora de um código;

ig - EXIT chars elementares do processo de evolução de densidade num código LDPC; H - Matriz de paridade;

1H - Parte da matriz de paridade H, com dimensões (n-k)xk;

2H - Parte da matriz de paridade H, com dimensões (n-k)x(n-k); I - Matriz identidade;

xvi

i - Grau de um ramo ou nó em um código LDPC; k - Número de símbolos de uma mensagem a ser codificada;

iL - LLR (Log-Likelihood Ratio); M - Submatriz de 1H em um código LDPC, m vezes menor do que a mesma; m - Grau de paralelização de um código LDPC, relação entre as matrizes 1H e M;

rsm - Número de bits por símbolo em um código Reed-Solomon; MM - Tamanho do conjunto X; Mmap - Número de símbolos de um alfabeto Amap; n - Número de símbolos de uma palavra-código; nmap - Número de bits utilizados para representar um símbolo do mapeador; Nquant - Número de valores de tensão representados por um conversor A/D ou D/A; P – Parte do conjunto das palavras-código correspondente às paridades; p – Parte da palavra-código correspondente às paridades associadas a x;

inp - Taxa de erro das mensagens de entrada de um código LDPC;

outp - Taxa de erro das mensagens de saída de um código LDPC; Q – Número de elementos de um dado corpo de Galois; q – Variável utilizada para representar o produto entre 1H e a mensagem a ser codificada em um código LDPC; r - Seqüência de bits recebidos em um decodificador RS; resbits – Resolução de conversor A/D ou D/A, dada em bits; S – Matriz auxiliar usada no cálculo de 1H em um código LDPC; s – Elementos da matriz S;

xvii

T – Estrutura compacta que permite emular a matriz 1H através de permutações no contexto de um código LDPC; t – Número máximo de símbolos que pode ser corrigido por um código; u – Mensagem de um nó de cheque para um nó de bit em um código LDPC; v – Mensagem de um nó de bit para um nó de cheque em um código LDPC; X – Conjunto de mensagens a ser codificado; x – Mensagem a ser codificada;

ix - I-ésimo bit da palavra-código x; θ – Notação de código;

xλ - Fração dos ramos conectados a nós de bit de grau x;

vw - Número total de nós de bit em um código LDPC; cw - Número total de nós de cheque em um código LDPC;

xρ - Fração dos ramos conectados a nós de cheque de grau x;

xviii

Lista de Siglas e Abreviações

• AGC – Automatic Gain Control;

• ARP – Address Resolution Protocol;

• ASIC – Application Specific Integrated Circuit;

• ASSP – Application Specific Standard Part;

• AVHDL – Altera Very high speed Hardware Description Language;

• bps – Bits por segundo;

• C – Linguagem de programação de propósito geral;

• C++ – Linguagem de programação de propósito geral, orientada a objeto, baseada em C;

• CI – Integrated Circuit;

• CAD –Computer Aided Design;

• CAE – Computer Aided Engineering;

• CPLD – Complex Programmable Logic Device;

• DAC – Developing Automation Conference;

• DCM – Digital Clock Manager;

• EDA – Electronic Design Automation;

• EEPROM – Electrically Erasable Programmable Read Only Memory;

• EPROM – Erasable Programmable Read Only Memory;

• FIFO – First In First Out;

• FPGA – Field Programmable Gate Array;

• GAL – Gate Array Logic;

• Gbps – Giga bits por segundo;

xix

• GHz – Giga Hertz;

• Hz – Hertz;

• IEEE – Institute of Electrical and Electronics Engineer (http://www.ieee.org);

• IP – Internet Protocol;

• IP (2) – Intellectual Property;

• ISP – In System Programmable;

• ITU – International Telecommunication Union (http://www.itu.int/home/);

• JTAG – Joint Test Action Group (IEEE 1149.1);

• Kbps – Kilo bits por segundo;

• KHz – Kilo Hertz;

• LDPC – Low Density Parity Check;

• LNA – Low Noise Amplifier;

• MAC – Media Access Control;

• Mbps – Mega bits por segundo;

• MHz – Mega Hertz;

• MOSFET MOS – Metal Oxide Semiconductor Field Effect Transistor;

• MPEG – Moving Picture Experts Groups (www.mpeg.org);

• MSPS – Mega Sample Per Seconds;

• NPI – Núcleo de Propriedade Intelectual;

• OFDM - Orthogonal Frequency Division Multiplexing;

• PAL – Programmable Array Logic;

• PCI – Peripheral Component Interconnect;

• PLD – Programmable Logic Device;

• PLL – Phase-locked loop;

• PMCD – Phase Matched Clock Divider;

• PROM – Programmable Read Only Memory;

• RAM – Random Access Memory;

• RFP – Requisição Formal de Proposta;

• ROM – Read Only Memory;

• RS – Reed-Solomon;

xx

• RTL – Register Transfer Level;

• SBTVD – Sistema Brasileiro de Televisão Digital;

• SPLD – Simple Programmable Logic Device;

• SVP – Silicon Virtual Prototyping;

• TTL – Transistor-Transistor Logic;

• UDP – User Datagram Protocol;

• USB – Universal Serial Bus;

• Verilog – Linguagem de Descrição de Hardware (IEEE 1364);

• VHDL –Very high speed Hardware Description Language (IEEE1164);

• VHSIC – Very High Speed Integrated Circuit;

1

1

Capítulo 1 Introdução 1.1 A Importância das Ferramentas de Prototipagem Rápida nas

Soluções de DSP

Aplicações que envolvem Processamento Digital de Sinais (DSP) são cada vez mais

freqüentes e importantes na vida cotidiana, e a utilização de ferramentas que possibilitem seu

desenvolvimento e emprego é de essencial importância. Em um mundo que exige cada vez mais

rapidez e agilidade na demonstração de resultados de pesquisas científicas e no desenvolvimento

de novos produtos, encontrar soluções de uma forma eficiente e rápida é fundamental para

manter-se competitivo. Desta forma, este trabalho apresenta a implementação de um codificador

LDPC (Low Density Parity Check) para um sistema de televisão digital, desenvolvido através do

emprego de tecnologias inovadoras de prototipagem rápida baseadas em FPGA (Field

Programmable Gate Array).

A concepção de um projeto de DSP, assim como qualquer outro projeto, demanda alguns

cuidados que antecedem à etapa de aplicação das ferramentas de desenvolvimento. Ao iniciar-se

um projeto, o primeiro passo é determinar quais as suas finalidades, objetivos e quais

necessidades que ele visa suprir. Depois, necessita-se definir quais serão os recursos empregados.

Em seguida, deve-se especificar uma metodologia de desenvolvimento bem definida a ser

empregada. Finalmente, determinam-se quais serão as ferramentas utilizadas para executar-se o

projeto. Um bom e simples exemplo de comparação para esta concepção é o projeto de

construção de uma casa. Inicialmente o arquiteto necessita definir as finalidades do projeto, ou

Capítulo 1 – Introdução 2

seja, delimitar questões iniciais relativas ao seu objetivo, como, por exemplo, quantas pessoas

habitarão a casa, qual o tamanho da mesma, quantas peças ela terá etc. Depois, visando aos

objetivos do projeto da casa, ele deverá determinar os recursos que serão empregados, se a casa

será construída de madeira, de alvenaria, com acabamentos de gesso etc. A próxima etapa refere-

se à metodologia empregada, ou seja, por qual parte começará a obra, quais as primeiras paredes

a serem alicerçadas, entre outras. Finalmente ele deverá especificar as ferramentas a serem

utilizadas de acordo com os recursos escolhidos, por exemplo, espátula e betoneira, caso a obra

seja de alvenaria, serra e plaina, caso a casa seja de madeira e assim por diante.

Assim, tal qual o arquiteto deparando-se com o projeto da casa, quando uma equipe de

desenvolvimento está diante de uma aplicação de DSP a ser implementada, ela depara-se com o

mesmo tipo de processo descrito anteriormente: objetivos, recursos, metodologias e ferramentas.

Para a definição desses pontos, fatores diretamente relacionados a questões como custo,

qualidade e tempo de desenvolvimento do produto são fortemente pertinentes, bem como

questões tais quais: a solução será implementada em software ou hardware? Se em software, usar

processadores de uso geral (Power PC ou ARM) ou processadores de uso específico (Analog

Device Sharc e Blackfin, Texas Instruments C6000 ou Motorola i350)? Se a implementação for

feita em hardware, utilizar FPGA, ASIC ou ASIC estruturado? Será possível utilizar algum

Núcleo de Propriedade Intelectual (NPI ou IP Core) existente? Qual linguagem de

desenvolvimento deve ser utilizada (C, C++, VHDL, Matlab)? Essas são questões que

corriqueiramente encontram-se na mente de desenvolvedores nas etapas iniciais de projeto [1].

Os processadores de DSP de uso geral apresentam uma grande penetração de mercado,

especialmente por disporem de uma flexibilidade relativamente elevada, uma vez que seu

desenvolvimento é totalmente baseado em software, o que facilita a correção de erros e

atualizações. Além disso, geralmente apresentam plataformas de desenvolvimento relativamente

amigáveis, utilizando, em sua maioria, linguagens de programação difundidas como C ou C++.

No entanto, os requisitos atuais dos sistemas eletrônicos e de comunicações excedem a

capacidade dos processadores de DSP de uso geral, ou seja, eles estão deixando de atender a atual

demanda de processamento [2] [1]. A lacuna criada entre a capacidade de desempenho dos

processadores de DSP de uso geral e os requisitos das novas tecnologias de comunicações tende a


aumentar ainda mais nos próximos anos [1]. A solução para os desenvolvedores de sistemas em

processadores de DSP de uso geral é colocar seus algoritmos “em silício” para uma “aceleração”

em hardware, uma vez que a demanda de desempenho de sistemas de DSP está forçando os

limites das tecnologias de software existentes e a capacidade de desempenho em hardware está

aumentando. Ademais, os processadores DSP de uso geral possuem recursos fixos e cada

processador possui um número limitado de funções computacionais básicas.

As principais tecnologias disponíveis para implementação de sistemas de DSP em

hardware são FPGA, ASIC, ASIC estruturado e processadores de DSP. Quando da

implementação em silício, as principais questões que são consideradas são relativas ao

desempenho, flexibilidade ou capacidade de reprogramação, custo por unidade, tempo de

fabricação e flexibilidade dos recursos dos dispositivos (recursos ditos embarcados) como

memórias, somadores etc. Algoritmos de DSP implementados em ASIC, quando comparados

com FPGAs, têm a vantagem de ter o melhor desempenho, pois operam com freqüências de

relógio (clock) maiores do que 1GHz. A implementação em FPGA reduz o desempenho em

comparação ao ASIC, atingindo uma freqüência de operação máxima em torno de 500MHz.

Além disso, as implementações em FPGA exigem o maior custo por unidade e possuem a menor

flexibilidade dos recursos embarcados, dependendo da família de dispositivos adotada. Ademais,

dispositivos ASIC possibilitam um menor custo por unidade quando produzidos em larga escala.

Entretanto, os ASICs sacrificam a flexibilidade ou capacidade de reprogramação, possuem um

alto custo inicial de implementação e um longo processo de prototipagem (algo em torno de seis

meses de desenvolvimento mais três meses de fabricação, de acordo com [1]), além de exigirem a

compra de ferramentas de desenvolvimento relativamente caras. Por sua vez, os algoritmos de

DSP implementados em FPGAs possuem a vantagem de apresentar o menor tempo de fabricação

(tipicamente de um a três meses, de acordo com [1]) e o maior grau de flexibilidade ou

capacidade de reprogramação. Uma vantagem das FPGAs sobre processadores DSP é que elas

permitem que o desenvolvedor “ajuste a arquitetura ao algoritmo”. Isso significa dizer, por

exemplo, que é possível implementar na FPGA um grau de paralelismo tal qual necessário para

atingir-se o desempenho desejado. Como nos processadores de DSP de uso geral os recursos são

fixos no dispositivo, ocorre que o “algoritmo tem que ser ajustado à arquitetura”. Já a solução de

desenvolvimento em ASIC estruturado é uma solução híbrida entre as soluções em ASIC e


FPGA. Assim, ela proporciona ao desenvolvedor uma solução intermediária entre os dois tipos de

solução.

Diante do desenvolvimento das novas famílias de FPGAs, especialmente dos maiores

fabricantes como Xilinx e Altera, uma nova e viável alternativa de hardware tornou-se disponível

para desenvolvedores de algoritmos de DSP, combinando as vantagens dos processadores de DSP

de uso geral com as vantagens de desempenho dos ASICs. Soluções de alto desempenho que

antes só eram atingidas através de ASICs agora são implementáveis em FPGA [3].

Além da determinação do uso do recurso (no caso a FPGA), a metodologia e as

ferramentas de desenvolvimento são determinantes para o sucesso de um projeto. Durante os

anos 70, observou-se uma proliferação dos semicondutores, aflorada principalmente pela

introdução de sistemas como o IC CAD. A tecnologia das memórias dinâmicas explodiu nos anos

80, quando ferramentas de simulação permitiram que um modelo preciso do comportamento das

células de memórias fosse simulado, aumentando significativamente a capacidade das memórias.

Também as tecnologias de microprocessadores, ASICs e FPGAs, deram um grande salto nos

anos 90 quando os desenvolvedores deixaram de lado suas velhas ferramentas esquemáticas e

acreditaram nas metodologias de fluxo top-down de síntese lógica e em linguagens como o

VHDL. Todo crescimento rápido, em qualquer setor de tecnologia, necessitou da introdução de

uma nova metodologia de desenvolvimento e ferramentas para aumentar consideravelmente a

produtividade. O desafio com o qual os desenvolvedores de DSP se deparam hoje é o mesmo

com o qual os desenvolvedores de ASIC se depararam nos anos 90: quais as mudanças em termos

de ferramentas e em suas metodologias de desenvolvimento que devem ser feitas para utilizar

FPGAs ao invés de processadores de DSP de uso geral; como obter essas habilidades; como

migrar de uma tecnologia para outra sem perder os projetos atuais? Comercialmente, muitas

vezes, ao escolher-se a ferramenta de desenvolvimento, a metodologia de projeto já está incutida

no fluxo de utilização da própria ferramenta.

O desenvolvimento tradicional de soluções de DSP, geralmente, dá-se dividido entre duas

equipes, uma de desenvolvimento de sistemas/algoritmos e outra de implementação em

software/hardware. Algumas vezes, em grandes empresas, essas equipes chegavam a ficar


fisicamente distantes umas da outras. Desenvolvedores de algoritmos deveriam criar, analisar e

refinar os algoritmos de DSP, usando ferramentas de análise matemática, visando a um

comportamento que não se preocupasse com a arquitetura de hardware ou software que seria

implementada [2]. Enquanto estes experientes desenvolvedores de sistemas possuem

familiaridade com implementação de algoritmos em software, eles, em geral, apresentam

dificuldades na hora de adaptar seus projetos às limitações de silício. Na outra equipe por sua

vez, o engenheiro de implementação também necessita conhecer teoria de comunicações e

processamento de sinais para poder interpretar a especificação escrita pelos engenheiros de

algoritmo. Além disso, o processo de criar um RTL (Register Transfer Mode) para a

implementação em hardware consome um longo período de trabalho devido à necessidade de

verificação manual do RTL com o modelo feito em Matlab ou em outra linguagem utilizada pela

equipe de desenvolvimento de algoritmo [2]. Esse processo se mostra lento, custoso e pouco

produtivo para a atualidade. Assim que o modelo RTL e o ambiente de simulação são criados, o

engenheiro de implementação interage com os engenheiros desenvolvedores do algoritmo para

analisar desempenho, ocupação de área de silício etc. É bastante comum que o algoritmo original

necessite ser modificado, porque os engenheiros de algoritmo não possuem uma visão física do

projeto durante o desenvolvimento. Existe a necessidade de iteração nos processos.

A produção de circuitos integrados em larga escala continua seguindo um avanço

exponencial (lei de Moore) gerando um incremento no desempenho e no número de componentes

lógicos, enquanto a produtividade de projeto, no entanto, avança linearmente [4]. Desta forma,

existe a criação de uma nova lacuna entre o número de portas lógicas realmente disponíveis e o

número de portas lógicas “projetáveis”, de tal forma que novos produtos acabam sendo

particularmente vulneráveis a se tornarem prematuramente produtos de uma tecnologia obsoleta.

Segundo [4], “o único desafio com o qual se deparam os engenheiros de projeto/desenvolvimento

atualmente é conceber sistemas cada vez mais complexos em um time-to-market (janela de tempo

de desenvolvimento até sua chegada ao mercado) comprimido, para produtos que possuem ciclos

de vida cada vez mais curtos”.

O cenário mostrava que, embora FPGAs oferecessem grandes vantagens como baixo

consumo de energia e bom desempenho, sua programação ainda parecia difícil quando


comparada com a programação dos processadores de DSP. Anteriormente, enquanto para

programar-se um processador de DPS bastava escrever um programa em C, para programar-se

uma FPGA necessitava-se de um vasto conhecimento da arquitetura de hardware e um

conhecimento avançado em uma linguagem de implementação em hardware como, por exemplo,

VHDL. Felizmente, a comunidade científica observou esse problema e trabalhou no sentido de

alcançar um modo que tornasse mais viável e mais rápido o caminho do desenvolvimento à

implementação. Os novos modelos de desenvolvimento em FPGA provêm do uso de fontes de

núcleos de propriedade intelectual (NPIs) e de programação feita em linguagens de mais alto

nível, como Matlab e Simulink, e são conhecidos como geradores ou sintetizadores. Linguagens

de uso geral como C, C++, SYSTEM C, VHDL e VERILOG não oferecem eficiência para criar

funções matemáticas complexas de uma maneira eficiente em termos de tempo de

desenvolvimento. Atualmente, Matlab sozinho corresponde ao desenvolvimento de 90% das

aplicações de DSP [5].

Em [4], é apresentado um exemplo de comparação entre a implementação, desde a

especificação do projeto até a etapa de verificação e layout, feita em ASIC pelo modo tradicional

de desenvolvimento e utilizando a metodologia de projeto com geradores de VHDL. Observou-se

uma redução de três a dez vezes no tempo de projeto com as novas tecnologias, dependendo da

complexidade do mesmo. O ponto-chave das novas tecnologias de desenvolvimento é o suporte

para rápida exploração de relações de compromisso (trade-offs) de área, velocidade e consumo de

energia do algoritmo e da arquitetura já nas etapas iniciais do projeto. O poder dos geradores está

no encapsulamento do conhecimento e do know-how do especialista em arquitetura e micro-

arquitetura, pois os parâmetros dos geradores providenciam um mecanismo de especificação de

alto nível para características como paralelismo e ocupação. Quando se busca aumentar o

desempenho de um sistema através de técnicas de pipelining e ou de paralelismo, há um aumento

da ocupação de área de silício do dispositivo. Com o uso de ferramentas de desenvolvimento

rápido, essa relação de compromisso pode ser facilmente acompanhada e o projeto facilmente

reestruturado de forma a atingir-se a relação de compromisso ideal. Este recurso de exploração de

relação de compromisso é essencialmente útil para traçar-se, ainda na etapa de desenvolvimento,

a curva de desempenho versus área ocupada, o que pode auxiliar na determinação da família de

dispositivos a ser utilizada e na avaliação de fatores que constituem o custo final da solução.


Um fato bastante considerável é que até pouco tempo atrás, apenas companhias com

experientes engenheiros e grandes orçamentos podiam dispor de implementações em hardware

como FPGAs e ASICs. Atualmente, com a nova classe de ferramentas disponíveis, existe a

possibilidade que implementações de algoritmos de DSP possam ser amplamente empregadas,

introduzindo um novo paradigma no desenvolvimento de DSP que é a síntese de algoritmos.

Como já exposto anteriormente, velocidade de desenvolvimento e o time-to-market são vitais no

desenvolvimento de um produto. Transcendendo a questão comercial, porém, existe também a

questão do crescimento científico e tecnológico da sociedade. Este crescimento pode ser

impulsionado pela disponibilidade de ferramentas que possibilitem, em um período relativamente

curto de tempo, a obtenção de um protótipo capaz de comprovar conceitos teóricos e de alicerçar

o desenvolvimento de tecnologias futuras.

Um perfeito exemplo de quão custoso pode ser o desenvolvimento de uma tecnologia sem

a possibilidade de uma rápida implementação é a forma como se deu o avanço das técnicas de

OFDM, ao qual foi aplicado o codificador LDPC. A origem do desenvolvimento do OFDM deu-

se no final dos anos 50 com a introdução da multiplexação por divisão de freqüência (FDM) para

a comunicação de dados. Em 1966, um engenheiro chinês chamado Chang patenteou a estrutura

do OFDM e publicou o conceito do uso de freqüências ortogonais. Em 1971, outro engenheiro,

Weinstein, introduziu a idéia de usar transformada discreta de Fourier (DFT) para a

implementação da geração e de recepção de sinais OFDM, eliminando os bancos de osciladores

analógicos que eram necessários até então. Estes avanços proporcionaram uma implementação

menos complexa do OFDM, especialmente com o uso posterior da transformada rápida de

Fourier (FFT) ao invés da DFT. Isto conduz a pensar que a forma mais fácil de implementar

técnicas de OFDM é através de processadores de DSP que possibilitem a implementação de FFT.

Contudo, a viabilidade desse tipo de implementação é bem recente. A dependência da

implementação da FFT “amarrou” a difusão do OFDM durante o seu desenvolvimento, e seu

emprego de uma forma mais ampla só se deu nos anos 80, quando o uso de processadores de DSP

tornou-se mais viável, quase 30 anos depois do início dos trabalhos.

Diante do exposto, considerando-se custo e desempenho das atuais FPGAs, combinados

com outras de suas vantagens, as FPGAs tornaram-se a melhor alternativa para implementação de


aplicações de DSP de alto desempenho. Por esta razão, as ferramentas de rápido desenvolvimento

de soluções baseadas nestes dispositivos constituem o foco central desta dissertação. Desta

forma, este texto apresenta ainda nesta introdução uma contextualização temporal e política dos

trabalhos desenvolvidos. Posteriormente, é delineada uma introdução às FPGAs, descrição de

algumas ferramentas e metodologias de desenvolvimento - especialmente às aplicadas no projeto

do sistema de televisão digital em que está inserido este trabalho-, uma breve introdução teórica

no que tange às principais tecnologias envolvidas no projeto de televisão digital e uma descrição

sobre a codificação de canal utilizada no projeto. Em seguida, os detalhes de implementação são

apresentados e também os mais significativos resultados obtidos. Por fim, apresentam-se as

considerações finais e as sugestões para trabalhos futuros.

1.2 Contextualização Política e Temporal da Dissertação

No ano de 2005, entre os meses de março e dezembro, o Governo Federal brasileiro

financiou pesquisas científicas visando ao desenvolvimento de um sistema brasileiro de televisão

digital (SBTVD). Esse projeto, financiado pelo Ministério das Comunicações, deveria empregar

as técnicas mais inovadoras de radiodifusão. O SBTVD tinha como objetivos, ao menos

teoricamente: promover a inclusão social e a diversidade cultural do país visando à

democratização da informação; estimular a pesquisa e o desenvolvimento e propiciar a expansão

de tecnologias brasileiras e da indústria nacional relacionadas à tecnologia de informação e

comunicação; planejar o processo de transição da televisão analógica para a digital, de modo a

garantir a gradual adesão de usuários a custos compatíveis com sua renda; aperfeiçoar o uso do

espectro de radiofreqüências; contribuir para a convergência tecnológica e empresarial dos

serviços de comunicações e aprimorar a qualidade de áudio, vídeo e serviços, consideradas as

atuais condições do parque instalado de receptores no Brasil [6].

Para alcançar os seus objetivos, o SBTVD foi dividido em vinte e dois grupos,

denominados consórcios, onde a distribuição dos trabalhos foi realizada através de Requisições

Formais de Propostas (RFPs). Estes consórcios foram formados por setenta e nove universidades

e instituições brasileiras de pesquisa e contou com a atuação de mais de mil e trezentos


pesquisadores em todo o país. Um dos consórcios responsáveis pelo segmento do projeto

denominado Modulação Inovadora (MI-SBTVD), correspondente à RFP18, foi constituído pelo

Instituto Nacional de Telecomunicações (INATEL), Universidade Estadual de Campinas

(UNICAMP), Universidade Federal de Santa Catarina (UFSC), Centro Federal de Educação

Tecnológica do Paraná (CEFET-PR) e pela Linear Equipamentos Eletrônicos S.A. Esta

dissertação de mestrado, por sua vez, foi desenvolvida no âmbito deste consórcio. Desta forma,

os conhecimentos adquiridos nos trabalhos desenvolvidos durante o SBTVD auxiliaram na

elaboração desta dissertação e vice-versa, apesar das propostas serem parcialmente diferentes.

Até a data da elaboração desta dissertação, a comunidade científica, bem como toda a

sociedade brasileira, não tem uma definição sobre o futuro da televisão digital no Brasil. Neste

cenário, faz-se importante destacar que os trabalhos propostos pelo SBTVD foram

satisfatoriamente concluídos e apresentados ao Ministério das Comunicações brasileiro.

10

10

11

11

Capítulo 2 Tecnologias para Implementação de Sistemas em FPGAs 2.1 Introdução às FPGAS 2.1.1 Introdução, Conceitos Fundamentais e Origem das Tecnologias

Dispositivos FPGAs (Field Programmable Gate Arrays) são circuitos integrados digitais

que contêm blocos reconfiguráveis de lógica com interconexões entre eles. Programadores

podem configurar estes dispositivos de forma a desempenhar as mais diferentes tarefas. A parte

do nome referenciada como “campo programável” refere-se ao fato de que sua programação se

dá “em campo”, diferentemente dos dispositivos nos quais as funcionalidades internas são

fortemente “amarradas” pelo fabricante. Isto significa que as FPGAs podem ser configuradas

tanto nos laboratórios como podem ser modificadas depois de já estarem em seus locais

definitivos de operação.

Uma questão bastante interessante é saber por que as FPGAs são tão empregadas, sendo

que existem muitos tipos de circuitos integrados – alguns deles já comentados no capítulo

introdutório deste trabalho – onde as FPGAs poderiam ser apenas mais um deles. Assim, buscar-

se-á expor as tecnologias de dispositivos lógicos programáveis (PLDs), ASICs, ASSPs

(Application Specific Standard Part) e FPGAs. O histórico e os conceitos apresentados neste

capítulo são amplamente difundidos e encontram-se pleonasticamente disponíveis em inúmeras

Capítulo 2 – Tecnologias para Implementação de Sistemas em FPGAs 12

bibliografias. Para tanto, este trabalho fundamentalmente baseou-se em [3], considerando o

reconhecido know-how e autoridade deste autor sobre o tema.

PLDs são dispositivos os quais, apesar da arquitetura interna ser pré-determinada pelo

fabricante, são criados de maneira a serem programados por desenvolvedores para

desempenharem inúmeras funções. A grande dificuldade em trabalhar-se com estes dispositivos

encontra-se no número relativamente baixo de portas lógicas disponíveis quando comparados às

FPGAs e na natureza simples e pequena das funções que podem implementar. No outro extremo

encontram-se os ASSPs e os ASICs (estes brevemente abordados no capítulo introdutório), que

podem conter centenas de milhares de portas lógicas e serem usados para implementar funções

bastante grandes e complexas. Tanto os ASICs quanto os ASSPs são desenvolvidos para

aplicações específicas, onde a principal diferença é que um ASIC é projetado e construído

endereçado a uma única empresa, enquanto um ASSP é destinado a inúmeros clientes. Como já

apresentado anteriormente, apesar dos ASICs oferecerem a melhor solução em tamanho,

capacidade de processamento e desempenho, eles possuem um alto custo de desenvolvimento,

consomem um grande período de desenvolvimento até sua chegada ao mercado (time-to-market),

além de não possuírem flexibilidade alguma. Assim, dentre as soluções de implementação em

hardware, as FPGAs representam um meio termo entre os PLDs e os ASICs, porque sua

funcionalidade pode ser customizada em campo como os PLDs e, ao mesmo tempo, eles podem

conter milhões de portas lógicas. Também, o custo de desenvolvimento de soluções em FPGA é

muito menor do que em ASICs, além das FPGAs apresentarem um time-to-market muito menor.

Quando da aparição das primeiras FPGAs no mercado, em meados dos anos 80, elas eram

usadas apenas para implementar as chamadas “lógicas de cola” (lógicas simples usadas para

“colar” grandes blocos ou dispositivos lógicos), máquinas de estado de complexidade média e

algumas simples tarefas de processamento. No começo dos anos 90, com o aumento da

capacidade lógica das FPGAs, seu uso começou a crescer principalmente estimulado pelo

mercado das telecomunicações, o qual necessitava de grandes blocos de processamentos de

dados. Posteriormente, iniciou-se o uso das FPGAs também na indústria automobilística e em

outras aplicações industriais. Freqüentemente, as FPGAs são usadas para implementar protótipos

de ASICs e para comprovar a implementação de algoritmos em hardware. Entretanto, devido ao


seu baixo custo de desenvolvimento e curto time-to-market, mais e mais FPGAs são usadas para

produtos finais, competindo diretamente com os ASICs.

No começo dos anos 2000, o desempenho das FPGAs deu um grande salto,

disponibilizando milhares de portas lógicas, microprocessadores embarcados, além de pinos de

alta velocidade para serem usados como entradas e saídas. O resultado disto foi que hoje FPGAs

são usadas para implementar basicamente tudo, incluindo dispositivos de comunicações, funções

de DSP, funções de processamento de imagens, entre outros. Resumindo, as FPGAs estão

ganhando fatias importantes de mercado que antes pertenciam aos ASICs, DSPs, micro-

controladores e circuitos integrados de comunicações de camada física. As FPGAs criaram um

novo mercado, conhecido como computação reconfigurável.

Sabe-se que a regra básica para distinguir uma FPGA de um ASIC é o termo

reconfigurável, presente na composição do nome FPGA. Porém, para que um dispositivo de

hardware seja reconfigurável, alguns mecanismos básicos devem estar presentes no mesmo. O

primeiro passo dado pelas tecnologias de hardware configurável foi a tecnologia de fusão de

conexão (fusible link), uma das primeiras técnicas que permitia ao usuário programar o seu

próprio dispositivo de hardware. Nesta técnica, o componente é fabricado com várias conexões

nas quais existem fusíveis que podem ser fundidos (rompidos) pelo usuário. Em seu estado

inicial, todas as conexões encontram-se intactas e para montar a lógica desejada, ao usuário é

permitido fundir o fusível (rompendo a conexão) de forma irreversível.

Posteriormente, surgiu a tecnologia de antifusão de conexão (antifuse link). Nesta

tecnologia, em seu estado inicial de programação, cada caminho ou trilha possui uma resistência

tal que o circuito pode ser considerado um circuito aberto. Assim, estes dispositivos podem ser

facilmente programados através da aplicação de pulsos de corrente com tensão relativamente

elevada em suas entradas. Então, em termos físicos, a conexão pode ser formada através de

saturação do material semicondutor utilizado na sua fabricação. Um período de tempo

ligeiramente anterior ao das tecnologias de fusão e antifusão de conexões, os dispositivos

programados por máscaras (mask-programmed devices) surgiram, fazendo uso de memórias

apenas de leitura (ROM) e de memórias de acesso randômico (RAM).


Memórias são componentes fundamentais na constituição de um dispositivo eletrônico e

por essa razão é necessário conhecê-las, ao menos, ao nível básico. As memórias ROM são ditas

não voláteis, pois os dados, uma vez gravados, permanecem nas mesmas ainda quando a energia

do sistema é retirada. Em geral, memórias ROM são de baixa capacidade de armazenamento. Já

as memórias do tipo RAM são ditas voláteis por perderem todos os dados uma vez retirada a

energia do sistema. Memórias ROM básicas são ditas programadas por máscara, pois todos os

dados contidos nelas são gravados durante a construção do dispositivo através de foto-máscaras,

as quais são usadas para criar os transistores e as faixas de metal que os conectam ao silício do

chip.

A geração seguinte às memórias ROM foi a das memórias programáveis somente de

leitura (PROM), criadas em 1970 para solucionar o problema de que as memórias programadas

por máscara eram feitas a partir de um processo altamente custoso. Além disso, para obter-se as

memórias programadas por máscara, muitos componentes eram usados nas etapas de

desenvolvimento e precisavam ser alterados freqüentemente, o que não era possível. As

memórias PROM foram criadas baseadas na tecnologia de fusão de conexão. Em seu estado não

programado, tal qual entregue pelo fabricante, todas as fusões de conexões estão intactas. Assim,

engenheiros de desenvolvimento podem selecionar as conexões a serem fundidas (rompidas).

Quando rompida a conexão, a célula lógica desta dada conexão aparece com nível lógico ‘1’.

Faz-se importante destacar que estes dispositivos eram inicialmente desejados para serem usados

como memórias capazes de armazenar programas de computador e valores constantes de dados.

Entretanto, engenheiros notaram sua grande utilidade para implementar simples funções lógicas

como tabelas de lookup. A grande vantagem da memória PROM para a ROM é que a primeira

poderia ser gravada pelo usuário, ainda que uma única vez.

O passo seguinte na evolução de dispositivos de memória foi o da criação, em 1971, pela

Intel, da memória apenas de leitura programável e apagável (EPROM). As memórias existentes

até então (ROM e PROM) só podiam ser programadas uma única vez, pois eram baseadas em

fusão ou antifusão de conexões, processos ditos irreversíveis e, por isso, menos eficientes em

termos de ocupação de silício. Havia a necessidade de poder-se programar, apagar e reprogramar

uma memória não volátil com novos dados. A estrutura básica de uma memória EPROM é a


mesma de uma PROM, com a diferença de que ao invés de um diodo, é utilizado um transistor do

tipo MOS e no lugar do fusível para a fusão da conexão é utilizado um transistor MOS com gate

flutuante. Assim, através de tensões relativamente altas, consegue-se armazenar carga no gate

flutuante. Então, se o gate tem carga, na linha de endereço selecionada aparecerá o nível lógico

zero, do contrário, se o gate não estiver carregado, aparecerá o nível lógico ‘1’. As memórias do

tipo EPROM são regraváveis através de descarga de elétrons no gate flutuante, aplicadas através

de uma pequena janela de quartzo. A energia necessária para tal processo é provida por raios

ultravioletas. O principal problema do uso deste tipo de memória é o custo da janela de quartzo e

o longo tempo (em torno de vinte minutos) necessário para apagar os dados do dispositivo.

O degrau subseqüente na evolução das memórias apenas de leitura foi o surgimento da

memória apenas de leitura programável e apagável eletricamente (EEPROM). Uma célula de

memória EEPROM é aproximadamente duas vezes e meia maior do que sua equivalente na

versão EPROM, pois possui dois transistores onde na EPROM era apenas um. Uma alteração na

dopagem do silício é o que torna possível que a propriedade de apagar os dados seja feita de

forma elétrica. Após (não necessariamente em ordem cronológica, mas em ordem de evolução)

as memórias EPROMs, foram apresentadas as memórias flash. O nome flash surgiu justamente

da comparação com o longo tempo que as EPROMs despendiam para apagar dados, uma vez que

as memórias flash podiam apagar os dados eletricamente, embora não parcialmente.

Chegando ao campo das memórias de acesso randômico (RAM) depara-se com dois tipos

dessas memórias, uma tecnologia de memória dinâmica de acesso randômico (DRAM) e outra de

memória estática de acesso randômico (SRAM). No caso das memórias DRAM, cada célula é

formada por um par transistor/capacitor que consome muito pouco silício. O adjetivo “dinâmica”

é usado porque o capacitor perde sua carga a cada ciclo de tempo e, então, cada célula deve

periodicamente recarregar-se, se a mesma necessitar manter o dado. A esta operação é dado o

nome de refresh. Quando o custo das operações de refresh é amortizado pelos milhões de bits em

uma memória DRAM, esse modelo se torna muito viável, especialmente por possuir um consumo

de energia muito baixo e por ter uma alta densidade de integração. O custo de uma memória

DRAM é bem mais baixo que o de uma SRAM. Já as memórias do tipo SRAM guardam os dados

enquanto as mesmas forem alimentadas por energia, sem precisar do recurso de refresh. Estas


operam em uma freqüência dez vezes superior às memórias DRAM, mas possuem capacidade de

integração bastante baixa e consumo de energia e de silício bastante significativos.

Muitos dos dispositivos desenvolvidos no passado possuíam um time-to-market

relativamente grande em comparação a outros, ou seja, alguns chegaram ao mercado tão logo

foram desenvolvidos, enquanto outros levaram grandes períodos de tempo para serem

efetivamente absorvidos pelo mercado. A Figura 1 apresenta o time-to-market de diversas

tecnologias. Como pode ser observado na mesma figura, por exemplo, as FPGAs, desenvolvidas

em meados dos anos 80, só foram incorporadas ao mercado em meados nos anos 90. Assim, ao

longo deste capítulo, apresentar-se-ão alguns dados referentes ao surgimento das tecnologias

presentes nas FPGAs ou que, de alguma forma, contribuíram para o surgimento das mesmas.

Em dezembro de 1947, nos laboratórios Bell nos Estados Unidos, surgia o primeiro

transistor, desenvolvido por William Shockley e Walter Brattain, obtido a partir de germânio. Já

nos anos 50, viu-se o emprego de transistores bipolares (BJT), os quais eram mais baratos e

fáceis de serem fabricados. No final dos anos 50, os transistores começaram finalmente a ser

fabricados com silício, elemento bem mais barato. Com os transistores BJT, surgiram as portas

lógicas implementadas nos famosos TTL (lógica transistor-transistor), que eram relativamente

rápidos e possuíam um consumo de energia consideravelmente elevado. Surgiram também as

portas lógicas implantadas nos ECL (lógica par emissor), que eram mais rápidas que os TTLs e

consumiam ainda mais energia. Em 1962, surgiram os transistores MOSFET, desenvolvidos nos

laboratórios RCA por Steven Hofstein e Frederic Heiman. A grande vantagem destes transistores

era o preço baixo, dimensões físicas menores e um consumo de energia significativamente

menor. Os transistores MOSFET deram origem aos transistores CMOS, ainda menores e de

consumo de energia bastante pequeno, comparado ao seu principal concorrente, a família dos

transistores TTL.

As discussões acerca da implementação de circuitos inteiros em pequenas peças de

semicondutores foram apresentadas em 1952 por um britânico especialista em radar, chamado

Dummer. No entanto, o primeiro circuito integrado foi apresentado em 1958 por Jack Kilby que

desenvolveu nos laboratórios da Texas Instruments um CI oscilador de fase que continha cinco


componentes. Em meados dos anos 60, a Texas Instruments difundiu de uma forma bastante

significativa diferentes famílias de CIs implementadas em famílias TTL. Apenas em 1968, a

RCA desenvolveu CIs equivalentes utilizando tecnologias CMOS.

1945

Transistor

1950 1955 1960 1965 1970 1975 1980 1985 1990 1995 2000

CI (Geral)

SRAM e DRAM

Microprocessadores

SPLDs

CPLDs

ASICs

FPGAs

- Fabricação

- Real entrada no mercado

1945

Transistor

1950 1955 1960 1965 1970 1975 1980 1985 1990 1995 2000

CI (Geral)

SRAM e DRAM

Microprocessadores

SPLDs

CPLDs

ASICs

FPGAs

- Fabricação

- Real entrada no mercado

Figura 1 – Diagrama temporal das tecnologias relacionadas com FPGAs.

No final dos anos 60 e início dos anos 70, dava-se um desenfreado desenvolvimento no

âmbito dos CIs. Em 1970, a Intel apresentou a primeira memória DRAM de 1.024 bits e no ano

seguinte, o primeiro microprocessador, com aproximadamente 2.300 transistores e a capacidade

de executar até 60.000 operações por segundos. A razão para esta seção abordar as tecnologias de

memórias SRAM e microprocessadores está no fato de que, além da importância desta análise da

evolução dos dispositivos, as atuais FPGAs são baseadas em memórias SRAM e podem possuir

núcleos de microprocessadores embarcados no dispositivo.

Os primeiros CIs programáveis disponíveis no mercado foram os PLDs, que sugiram por

volta dos anos 70 e, pode-se afirmar, eram simples memórias PROMs [3]. Apenas no final dos

anos 70 surgiram versões mais complexas de PLDs. Assim, as versões mais rudimentares de PLD

foram denominadas de SPLDs e as posteriores e mais desenvolvidas denominadas PLDs


complexos ou CPLDs. Além disso, a categoria dos dispositivos lógicos programáveis menos

complexos (SPLDs) é dividida entre PROM (sua primeira versão), PLA, PAL e GAL e outras.

Entre os circuitos integrados de aplicação específica, ASICs, tais quais conhecidos

atualmente, existem quatro tipos que, por ordem de complexidade, são: arranjo de portas lógicas

(Gate Arrays), ASIC estruturados, célula padrão e ASIC completamente customizado. Assim, os

tipos de dispositivos ASICs serão brevemente abordados nos parágrafos seguintes.

O ASIC completamente customizado surgiu quando só existiam dois tipos de circuitos

integrados (sem considerar os circuitos de memória). Um era a categoria mais simples, vendido

como padrão para qualquer usuário e o outro era a categoria desenvolvida para uma única

aplicação específica, o ASIC completamente customizado. Neste tipo de ASIC, os engenheiros de

desenvolvimento possuem um total controle sobre cada camada da máscara usada para fabricar o

chip de silício. O fabricante não pré-desenvolve qualquer componente no silício e não provê

qualquer biblioteca de lógica pré-definida. Através de ferramentas próprias, é possível controlar

as dimensões de cada transistor e assim criar funções de alto nível baseadas nestes componentes.

O desenvolvimento de um ASIC completamente customizado é extremamente complexo, além de

exigir um período de tempo bastante longo. Entretanto, o resultado final é um chip com máxima

otimização, com uma grande quantidade de lógica em uma área otimizada de silício.

A concepção de arranjo de portas lógicas (Gate Arrays) surgiu em companhias como IBM

por volta dos anos 60, mas apenas para uso interno. Para o mercado, seu “surgimento” foi bem

posterior. O conceito de arranjo de portas lógicas é baseado na idéia de uma célula básica

constituída a partir de uma coleção de transistores e resistores desconectados. Cada fabricante de

ASIC determina qual é a combinação ideal de componentes para formar uma célula básica. Os

fabricantes começam pré-fabricando chips de silício contendo arranjos destas células básicas. Em

geral estas células básicas são representadas por arranjos de colunas, simples ou duplas, e uma

área livre entre elas chamada de canal. A Figura 2 apresenta a arquitetura de arranjo de portas

lógicas com canais e arranjos de células básicas em colunas duplas. No caso de dispositivos livres

de canais, as células básicas são representadas como um grande e único arranjo. A superfície do

dispositivo é coberta em um “mar” de células básicas e não existem canais dedicados para


interconexões. Assim, estes dispositivos, nesta configuração, são comumente chamados de “mar

de células”. O fabricante ASIC define o grupo de funções lógicas (multiplexadores, registradores

etc.) que podem ser usados pelo desenvolvedor. Cada um desses blocos de funções é referenciado

como célula – que não é a célula básica – e o grupo de funções suportadas pelo fabricante ASIC é

conhecido como biblioteca de células. Arranjos de portas lógicas oferecem vantagens em termos

de custo, uma vez que o transistor e outros componentes são pré-fabricados. Assim, somente as

camadas de metalização são customizadas. As desvantagens deste tipo de componente são que

muitos recursos internos podem acabar não sendo utilizados, a posição dos gates de entrada e

saída são fixos e o roteamento das trilhas internas não é otimizado.

CélulasBásicas

Canais

Células deEntradae Saída

CélulasBásicas

Canais

Células deEntradae Saída

Figura 2 – Arquitetura de arranjo de células básicas com canais.

Para tentar superar algumas das desvantagens do arranjo de portas lógicas, no começo dos

anos 80 tornaram-se disponíveis os CIs de célula padrão, que contêm muitas semelhanças com o

arranjo de portas lógicas. Também neste tipo de tecnologia o fabricante define a biblioteca da

célula que pode ser usada pelo desenvolvedor. O fabricante também disponibiliza bibliotecas de


elementos como processadores, funções de comunicações e funções de memória RAM e ROM.

Ademais, o desenvolvedor pode optar por reutilizar funções previamente desenvolvidas ou

comprar blocos de funções de propriedade intelectual. Diferentemente do arranjo de portas

lógicas, os dispositivos de célula padrão não utilizam o conceito de célula básica e nem

componentes pré-fabricados no chip. O conceito de célula padrão permite que cada função lógica

possa ser criada usando o menor número de transistores sem a redundância de componentes, e as

funções podem ser dispostas de forma a facilitar as conexões entre elas. Desde a introdução dos

dispositivos de célula padrão, a indústria previu uma queda nos dispositivos de arranjo de portas

lógicas, entretanto o uso desta tecnologia continuou tendo seu nicho de mercado e, contrariando a

previsão de algumas indústrias, vem apresentando um forte ressurgimento nos últimos anos.

A tecnologia dos circuitos integrados estruturados apareceu no começo dos anos 90,

quando os fabricantes de ASIC iniciaram uma grande busca por uma forma inovadora para

reduzir os altos custos e tempo de desenvolvimento destes circuitos integrados de aplicação

específica. Cada ASIC estruturado inicia com um elemento fundamental chamado módulo, o

qual pode conter uma combinação de lógica genérica pré-desenvolvida (tabelas de lookup,

multiplexadores etc.), um ou mais registradores e uma memória RAM local. Um arranjo destes

elementos é então pré-desenvolvido na face do chip. Alternativamente, outras estruturas iniciam-

se com uma célula base (ou módulo base) contendo apenas lógica genérica na forma de portas

lógicas, multiplexadores ou tabelas de lookup pré-desenvolvidas. Um arranjo desse tipo de base

forma então uma base mestra (ou módulo mestre) e, mais uma vez, um arranjo dessas unidades

mestras é pré-fabricado na face do chip. Não obstante, blocos de RAM e geradores de relógio são

especialmente úteis e, por isso, geralmente encontram-se embarcados no dispositivo. A Figura 3

exibe um modelo genérico de ASIC estruturado com quatro blocos de memória RAM e entradas

e saídas pré-desenvolvidas.

A idéia do ASIC estruturado é de que o dispositivo pode ser customizado usando somente

as camadas de metalização (assim como o padrão arranjo de portas lógicas, sendo que a diferença

é que, devido a maior sofisticação da estrutura do módulo do ASIC estruturado, a maioria das

camadas de metalização também é pré-definida). Assim, muitas arquiteturas de ASIC estruturado

necessitam customizar apenas duas ou três camadas de metalização, o que reduz drasticamente o


tempo e o custo de desenvolvimento. Estima-se que os ASIC estruturados consomem três vezes

mais silício e apresentam um consumo de energia duas vezes maior do que dispositivos de célula

padrão, para implementar a mesma função, embora estes resultados possam variar de acordo com

o tipo de projeto e de arquitetura.

Entradase Saídas

Pré-fabricadas

Blocos deRAM

Embarcados

Arranjo deMódulos

Entradase Saídas

Pré-fabricadas

Blocos deRAM

Embarcados

Arranjo deMódulos

Figura 3 – Estrutura genérica de um ASIC estruturado.

Dentre as opções de implementação em hardware disponíveis em meados dos anos 80,

parecia evidente a existência de dois extremos. Em uma ponta, encontravam-se os práticos e de

fácil desenvolvimento SPLDs e CPLDs, os quais possuíam grandes limitações que

impossibilitavam o desenvolvimento de funções complexas. No outro extremo, permaneciam os

ASICs, que podiam suportar funções robustas, entretanto sob pena de um alto custo e um longo

tempo de desenvolvimento, além de sua característica de inflexibilidade. Assim, visando

aproximar estes extremos, a Xilinx desenvolveu, em 1984, a primeira FPGA, a qual era baseada

em CMOS e utilizava células SRAM para configuração. Apesar de este primeiro modelo

apresentar uma pequena capacidade de implementação e poucos pinos de entrada e saída, muitos

aspectos de sua arquitetura são utilizados nos FPGAs atuais. Estes primeiros dispositivos foram

baseados no conceito de blocos lógicos programáveis, os quais continham três tabelas de lookup

(LUTs), um registrador que poderia funcionar como flip-flop ou latch, um multiplexador e outros

elementos menores. Assim, cada FPGA possuía um grande número destes blocos lógicos


programáveis, além de células SRAM apropriadas, as quais permitiam que cada um desses blocos

pudesse ser configurado de forma a desempenhar uma função diferente. Cada registrador poderia

ser configurado para conter um valor lógico de inicialização. Uma FPGA completa possui um

grande número de blocos lógicos programáveis ilhados em um “mar” de interconexões. Estas

conexões, por sua vez, podem ser caminhos de interconexões globais, os quais podem transportar

sinais através do chip sem ter que passar por elementos múltiplos e roteamento.

Existem casos nos quais núcleos de FPGAs são utilizados como parte de um projeto de

ASIC de célula padrão, caracterizando uma solução híbrida FPGA-ASIC. Uma razão para

embarcar material de FPGA em ASIC é que isso facilita o desenvolvimento de uma plataforma

de conceito. Neste caso, a plataforma seria o ASIC e o material da FPGA embarcado poderia

formar um dos mecanismos usados para customizar e diferenciar subprojetos. Uma outra razão é

que nos últimos anos tem-se percebido um crescente aumento no emprego de FPGA para

desenvolvimento de ASICs. Neste cenário, vê-se ainda uma alternativa com um grande e

complexo ASIC que possui uma FPGA associada, localizada muito próximo à placa do ASIC.

Esta configuração pode ser visualizada na Figura 4.

A razão para este cenário está no fato de ser extremamente custoso, além de consumir

muito tempo, corrigir um eventual erro de programa em ASIC ou modificar suas funcionalidades

de forma a acomodar qualquer mudança em sua especificação original. Entretanto, se o ASIC for

desenvolvido de maneira correta, a FPGA associada pode ser usada para implementar qualquer

modificação de atualização. Um problema nesta configuração é o tempo gasto pelos sinais para

navegarem entre o ASIC e a FPGA, pois estes sinais que trafegam entre os componentes não

terão a mesma velocidade das conexões internas do chip. Sendo este o problema, a solução é

realmente utilizar um modelo híbrido com material da FPGA embarcada no ASIC. Uma área de

interesse para estruturas híbridas FPGA-ASIC são os ASIC estruturados porque eles também

podem ser considerados como dispositivos baseados em blocos. Isto significa dizer que, quando

se procura por ferramentas de desenvolvimento, fabricantes de ASIC estruturados falam com

fornecedores de tecnologias de síntese e roteamento de FPGAs, além de ASIC. Em suma, isso

significa que soluções híbridas FPGA-ASIC baseadas em ASICs estruturados apontam para uma

ferramenta unificada ao fluxo de desenvolvimento, pois as mesmas ferramentas de síntese e


roteamento baseadas em blocos poderiam ser usadas para ambas as partes do projeto, FPGA e

ASIC.

Ligação para outrochip da placa



ASICFPGA




ASICFPGA




ASICFPGA

Figura 4 – Configuração de um ASIC com FPGA associada.

2.1.2 Arquiteturas e Configurações

A maioria das FPGAs atuais é desenvolvida baseada no uso de configurações de células

SRAM, o que significa que elas podem ser configuradas inúmeras vezes. A principal vantagem

desta técnica é que novas idéias de projeto podem ser rapidamente implementadas e testadas.

Outra grande vantagem do modelo baseado em SRAM é que seus dispositivos estão em uma

posição de vantagem tecnológica, pois muitas empresas do ramo de memórias investem bastante

em pesquisa de desenvolvimento. Além disso, as células SRAM foram desenvolvidas usando

exatamente tecnologia CMOS. Assim, nenhum novo processamento especial é necessário para

criar esses componentes. Uma desvantagem dos dispositivos baseados em SRAM é que uma

memória SRAM, por ser volátil, deve ser recarregada toda vez que o sistema for reinicializado.

Frente a isto, é necessário o uso de memória externa especial, não volátil.

As atuais FPGAs baseadas em SRAM suportam o conceito de criptografia bitstream. Os

dados da configuração final do sistema são criptografados em um bitstream antes de serem


armazenados na memória externa. A chave criptográfica é carregada para um registrador especial

baseado em SRAM através de sua porta JTAG. Assim, em conjunto com lógica adicional, esta

chave criptográfica permite que o bitstream criptografado seja interpretado e carregado no

dispositivo. O processo de carregar o bitstream criptografado automaticamente desabilita a

capacidade de leitura reversa (read-back) da FPGA. Isso significa que o desenvolvedor usará

dados de configuração não criptografados durante o processo de desenvolvimento (onde se

necessita usar read-back) e iniciar o uso de dados criptografados somente quando for mover os

dados para o dispositivo. Em geral, na maioria das plataformas de desenvolvimento, esse

processo é transparente ao usuário. O principal aspecto deste esquema é a necessidade de uma

bateria de backup na placa do circuito para manter o conteúdo do registrador da chave

criptográfica na FPGA quando a energia é removida do sistema. No entanto, esta bateria terá uma

vida útil de anos ou décadas.

Diferentemente das FPGAs baseadas em SRAM, as quais são programadas enquanto

residentes no sistema, FPGAs baseadas em antifusão de conexão são programadas em off-line

usando um dispositivo programador especial. Os proponentes das FPGAs baseadas na tecnologia

de antifusão de conexão orgulham-se em apontar uma variedade de vantagens. Primeiramente,

esses dispositivos não são voláteis (as configurações são mantidas, mesmo quando a energia é

subtraída do circuito), o que significa dizer que estes componentes estão prontos para serem

usados tão logo seja aplicada energia ao sistema. Também por serem não voláteis, estes

dispositivos não necessitam de bateria externa para armazenar as suas configurações. As FPGAs

baseadas nesta tecnologia também apresentam a grande vantagem de serem relativamente imunes

aos efeitos de radiação. Essa é uma vantagem extremamente útil no desenvolvimento de

aplicações para fins militares e aeroespaciais, especialmente porque FPGAs baseadas em SRAM

podem ter suas configurações de células de configuração alteradas quando expostas à radiação.

FPGAs baseadas em antifusão de conexão consomem apenas vinte por cento da energia

consumida por uma FPGA equivalente baseada em SRAM, aproximadamente, além dos atrasos

provocados por interconexões serem menores e de seus componentes serem fisicamente de menor

porte [3]. Obviamente que a grande desvantagem na operação com FPGAs baseadas em antifusão

de conexão é que uma vez programado o dispositivo, as fusões estão rompidas e uma nova

programação não pode ser feita, tornando este tipo de dispositivo muito pouco competitivo no


cenário de desenvolvimento e de prototipagem. FPGAs podem ainda ser baseadas em memórias

EPROM, EEPROM e em soluções híbridas flash-SRAM. Contudo, são soluções rejeitadas tanto

pelos fabricantes quanto pelo mercado e, portanto, não serão abordadas neste trabalho.

InterconexõesReprogramáveis

BlocoLógico

BlocoLógico

BlocoLógico

BlocoLógico

BlocoLógico

BlocoLógico

InterconexõesReprogramáveis

BlocoLógico

BlocoLógico

BlocoLógico

BlocoLógico

BlocoLógico

BlocoLógico

Figura 5 – Visão intercamada da FPGA.

Freqüentemente, as FPGAs são caracterizadas por sua granularidade. É importante

lembrar que o que diferencia as FPGAs de outros componentes é que sua construção se dá

baseada em um grande número de “ilhas” de blocos lógicos reprogramáveis relativamente

simples em meio a um “mar” de conexões programáveis, conforme pode ser observado na Figura

5. No caso da arquitetura de granularidade fina, significa que cada bloco lógico pode ser usado

para implementar apenas uma única e simples função. Elas são capazes de implementar de forma

satisfatória “lógicas de cola” e estruturas irregulares como máquinas de estado. Em suma,

arquiteturas de granularidade fina são eficientes para implementar funções nas quais os

benefícios derivam da implementação massiva de estruturas paralelas. Por volta de 1995,

arquiteturas finas de FPGA foram bastante utilizadas, entretanto com o passar do tempo viu-se

que a esmagadora maioria das FPGAs desenvolvidas é de arquitetura espessa. As arquiteturas de

FPGAs denominadas espessas quanto à granularidade são aquelas onde cada bloco lógico possui

uma quantidade relativamente grande de lógica. É conveniente destacar que as implementações


em arquiteturas finas necessitam de um número muito maior de conexões dentro e fora dos

blocos lógicos, comparando-se com as arquiteturas espessas. Inversamente proporcional ao

aumento da granularidade dos blocos, está o número de conexões dos blocos. Este aspecto é

especialmente importante no estudo dos efeitos dos atrasos no transporte de sinais, causados

pelas interconexões de blocos. Um fato concreto é que os grandes fabricantes de FPGAs não têm

mostrado interesse pela fabricação de dispositivos com arquiteturas de granularidade fina,

diminuindo assim o número de nós de conexões dos dispositivos. As FPGAs atualmente

fabricadas baseadas em tabelas de lookup são, em geral, consideradas de granularidade média.

Existem basicamente duas formas para que blocos lógicos sejam usados como

arquiteturas de granularidade média. São elas, arquiteturas de multiplexadores (Mux) e

arquiteturas de tabela de lookup (LUT). No modelo baseado em multiplexadores, o dispositivo

pode ser programado de forma que cada entrada do bloco lógico é representado por um sinal

digital, verdadeiro ou falso, proveniente de outro bloco lógico ou da entrada primária do

dispositivo. Isso permite que cada bloco seja configurado de inúmeras maneiras para implementar

uma grande quantidade de possibilidades de funções. Já o conceito do modelo baseado em

tabelas de lookup é bastante simples. Um grupo de sinais de entrada é usado com um indexador

(ponteiro) de uma tabela de lookup. O conteúdo desta tabela é organizado de forma que a célula

apontada por cada combinação das entradas contenham o valor desejado. A tabela de lookup pode

ser desenvolvida em cima de memórias SRAM, EEPROM ou células flash. Em termos práticos, o

modelo LUT é bastante eficiente quanto à utilização de área de silício e de atrasos de entrada e

saída de sinais e quando se deseja implementar uma grande quantidade de lógica com muitas

camadas de profundidade. A expressão “muitas camadas de profundidade”, neste caso, significa

uma grande quantidade de lógica entre as entradas e as saídas. Entretanto, a desvantagem das

arquiteturas baseadas no modelo de LUT aparece quando se deseja implementar uma função

pequena em algum lugar do projeto, pois a mesma ocupará a mesma tabela de lookup inteira para

essa simples implementação. Este fato gera um grande desperdício de recursos, podendo resultar

em atrasos na implementação de funções simples. É o famoso caso do “canhão utilizado para

matar um simples pássaro”.

Após os anos 90, as FPGAs foram amplamente utilizadas em aplicações de

telecomunicações e em soluções de redes. Estas aplicações requeriam, e de fato ainda requerem,


processamento de grandes quantidades de dados, onde arquiteturas baseadas em LUT

apresentavam o melhor desempenho. Ademais, com o crescimento dos projetos e da capacidade

dos dispositivos e com a sofisticação das tecnologias de síntese, o desenvolvimento manual de

circuitos acabou virando coisa do passado. O resultado disso é que, atualmente, a maioria das

FPGAs possui arquiteturas baseadas em LUT. Um dos pontos-chave no desenvolvimento das

FPGAs é o questionamento sobre a dimensão de entrada da LUT, da qual depende também o

número de combinações de funções lógicas. Adicionando-se mais entradas, permite-se

representar funções mais complexas, entretanto para cada nova entrada adicionada, dobra-se o

número de memórias (em geral SRAM) onde as LUTs são implementadas.

Alguns fabricantes permitem que as células que formam uma LUT sejam usadas como

pequenos blocos de memória RAM. Este mecanismo é conhecido como RAMs distribuídas, por

dois motivos. Primeiro, porque as LUTs são distribuídas ao longo da superfície do chip e,

segundo, porque isto diferencia estas memórias dos grandes blocos de memórias conhecidos

como BRAMs. Resumindo, uma vez programado o dispositivo, alguns fabricantes permitem que

o projetista use a célula SRAM que forma a LUT como um registrador.

Um detalhe importante na configuração das FPGAs é que cada fabricante possui um nome

diferente para as partes que constituem os dispositivos. Neste trabalho serão apresentadas apenas

as nomenclaturas utilizadas pelos dois maiores fabricantes, Xilinx e Altera. No caso da Xilinx, o

bloco lógico é chamado de LC (célula lógica) e contém uma LUT de quatro entradas (a qual pode

exercer a função de uma RAM de 16x1 ou de um registrador de deslocamento de 16 bits), um

registrador e um multiplexador. O registrador oferece a possibilidade de ser usado com um flip-

flop ou como latch. Além destes elementos principais, a LC possui ainda outros elementos

menores como, por exemplo, bit de transporte (carry) lógicos rápidos especiais. Para os

dispositivos Altera, o bloco lógico é denominado elemento lógico ou LE. Um conceito

importante é o que a Xilinx chama de slices, podendo ter outras denominações para outros

fabricantes. A definição de slice é uma forma de medição de células lógicas. É importante

destacar que a quantidade de células lógicas que caracterizam um slice pode variar, bem como a

definição de célula lógica.


Subindo um nível na hierarquia da construção das FPGAs, chega-se até o que a maioria

dos fabricantes (entre eles a Xilinx) chama de CLB ou bloco lógico configurável. A definição

sobre o que constitui um CLB pode também variar com o passar do tempo. Inicialmente, um

CLB era composto por duas LUTs de três entradas e um registrador. Outras versões posteriores

suportavam duas LUTs de quatro entradas e dois registradores. Atualmente, um CLB contém

quatro slices, onde cada slice contém duas LUTs de quatro entradas e dois registradores. A

importância de ter-se a hierarquia da FPGA bem definida (um bloco lógico configurável – CLB –

que é formado por quatro slices, onde um slice é formado por duas células lógicas – LC –) está na

possibilidade de se definir uma hierarquia equivalente para as interconexões. Assim, existem

conexões rápidas entre LCs em um slice, conexões mais lentas entre slices dentro de um CLB e

ainda conexões entre os CLBs. O objetivo principal desta hierarquia de interconexões é conectar

os elementos sem ocasionar atrasos excessivos de conexões.

Conforme visto anteriormente, cada tabela de lookup (LUT) de quatro entradas pode ser

usada como uma memória RAM de 16x1. Assumindo o já exposto (de se possuir quatro slices

por CLB), pode-se então implementar, através de um slice, qualquer uma das alternativas abaixo:

• RAM de porta simples de 16x8 bits;

• RAM de porta simples de 32x4 bits

• RAM de porta simples de 64x2 bits

• RAM de porta simples de 128x1 bit

• RAM de porta dupla de 16x4 bits;

• RAM de porta dupla de 32x2 bits;

• RAM de porta dupla de 64x1 bit;

Utilizando-se slices (e conseqüentemente CLBs) para implementar memórias RAM,

consome-se uma área maior de silício do componente. No entanto, obtêm-se vantagens em

termos de velocidade no acesso aos dados contidos nas memórias, se comparado ao processo

equivalente concebido nos blocos específicos de memórias RAM embarcados no dispositivo, os

quais serão vistos em breve. Além disso, de forma alternativa à implementação de memórias


RAM implementadas com uso das LUTs do dispositivo, cada LUT de quatro entradas pode

também ser utilizada como um registrador de deslocamento de 16 bits.

Uma característica importante das FPGAs mais recentes são as interconexões e lógica

especial para implementar cadeias rápidas de carry. Cada LC contém um carry lógico especial

através de interconexões dedicadas entre os dois LC de um mesmo slice, entre os slices dentro de

um CLB e também entre os próprios CLBs. Este recurso melhora o desempenho de funções

lógicas como contadores e de funções aritméticas como somadores. De fato, são os carry rápidos

que, juntamente com características introduzidas pelos multiplicadores embarcados e pelos

registradores de deslocamento implementados em LUTs, viabilizam implementações de funções

rápidas de DSP em FPGAs.

Muitas aplicações implementadas em FPGAs necessitam do uso de memórias, e de fato as

FPGAs atuais possuem um número relativamente grande de dispositivos de memória RAM

embarcados, chamados de blocos de memória RAM ou simplesmente BRAMs. Dependendo da

arquitetura do dispositivo, as BRAMs podem ser distribuídas pela periferia do componente,

espalhadas pela superfície do chip ou então organizadas em colunas de BRAMs. Dependendo do

dispositivo, ele pode conter por toda parte, desde dezenas até centenas de BRAMs, provendo uma

grande capacidade de armazenamento que vai de poucas centenas a milhões de bits. Cada bloco

de memória RAM pode ser usado de forma independente, ou múltiplos blocos podem ser

combinados de forma a implementar um grande bloco. Não obstante, BRAMs podem ser usadas

para as mais diversas aplicações, como implementar memórias RAM de porta simples ou dupla,

sistemas FIFO (First In First Out), máquinas de estado, entre outras aplicações.

As FPGAs atuais também possuem outros recursos embarcados que visam otimizar suas

implementações. Algumas funções, como as desempenhadas pelos multiplicadores e somadores,

são consideravelmente lentas se implementadas através da interconexão de um grande número de

blocos lógicos. Uma vez que vários tipos de aplicações demandam estas funções, a maioria das

FPGAs já incorpora blocos especiais de multiplicadores e somadores, os quais, em geral são

localizados próximos às BRAMs, porque estas funções freqüentemente são usadas em conjunto.

Uma operação muito utilizada nas aplicações de processamento digital de sinais é exercida por


um componente conhecido como multiplicador acumulador (MAC). Como o próprio nome

sugere, em um único ciclo de relógio são efetuadas as operações de multiplicar dois números e

somar seu resultado com o valor presente em um acumulador. A maioria das FPGAs atuais

possui blocos MAC no dispositivo.

Quase todas as partes de um projeto de hardware podem ser feitas através de hardware

(portas lógicas, registradores etc.) ou software (com instruções a serem executadas por um

microprocessador). O fato é que muitos dos projetos desenvolvidos usam microprocessadores e,

até tempos atrás, estes apareciam como discretos componentes na placa. Assim, as FPGAs

começaram a disponibilizar um ou mais microprocessadores embarcados, conhecidos como

“núcleos de microprocessadores”. Neste caso, faz sentido transferir as funções que eram

realizadas por um microprocessador externo para um núcleo interno. Essa técnica oferece

algumas vantagens como, por exemplo, o fato de reduzir o custo por poupar um componente,

eliminar um grande número de trilhas, pinos e conexões na placa e ainda permitir a utilização de

uma placa fisicamente menor.

Todos os elementos de sincronismo dentro de uma FPGA necessitam de um sinal de

relógio. Como geralmente um sinal de relógio se origina do “mundo externo”, ele chega até a

FPGA através de um pino especial de relógio para então ser roteado através do dispositivo e

conectado aos registradores. Existem, também, dentro do dispositivo, estruturas chamadas de

“árvores de relógio”, que recebem este nome porque o sinal principal de relógio se ramifica

várias vezes através delas. Estas estruturas são usadas para garantir que todos os flip-flops

enxerguem a sua versão de um mesmo sinal de um relógio principal tão próximo quanto for

possível. Se o sinal de relógio fosse distribuído por uma simples trilha orientando todos os flip-

flops, um após o outro, o primeiro flip-flop enxergaria o sinal de relógio muito antes de um dos

últimos da cadeia, por exemplo. Esse efeito é denominado efeito “skew” (ou oblíquo) e pode

causar muitos problemas no circuito. Também, usando uma “árvore de relógio”, é possível que

alguns efeitos skew sejam visualizados no circuito. Ao invés de configurar um pino de sinal de

relógio para ser diretamente conectado em uma “árvore de relógio”, o pino pode ser usado para

conduzir uma função (bloco) especial denominada de gerenciador de relógio, o qual gera sinais

de relógios derivados do sinal de relógio principal e amarrados a ele. Estes sinais de relógio


derivados podem ser usados para orientar “árvores de relógio” ou usados como pinos de saída

para prover serviços de sinais de relógio para outros circuitos. No universo Xilinx, esse

gerenciador de sinais de relógio recebe o nome de DCM (Digital Clock Manager) ou gerenciador

digital de relógio.

Uma comparação inusitadamente interessante, e apresentada em [3], diz respeito à vida

útil de desenvolvimento de uma dada FPGA comparada à vida humana. Esta comparação é

apresentada da seguinte maneira: um dispositivo FPGA que tem permanecido no mercado por

dois anos corresponde a trinta anos na vida de um homem. Assim, com dois anos, pode-se

começar a pensar neste dispositivo como um dispositivo maduro, bem conhecido e no auge de

suas atividades. Após três anos, o que corresponde a quarenta e cinco anos na vida humana, a

FPGA começa a se tornar algo de meia idade. Com quatro anos, correspondendo a uma pessoa de

sessenta anos, deve-se tratar este dispositivo com respeito, certificando-se de que não se está o

maltratando com um esforço demasiadamente grande.

2.1.3 Formas de Desenvolvimento e Implementação

Definir o roteamento das conexões de um dispositivo reconfigurável era algo que parecia

viável quando os dispositivos disponíveis eram baseados em fusão de conexões do tipo PAL,

GAL etc. No entanto, estes métodos manuais são completamente inviáveis para tratar-se com

dispositivos como FPGAs. Existem muitas maneiras de se programar estes dispositivos, como

através de diagramas esquemáticos, linguagem de descrição de hardware (HDL), compiladores de

linguagens de alto nível e ferramentas de mais alto nível baseadas na síntese de algoritmos.

Desta forma, esta seção objetiva expor estes métodos.

2.1.3.1 Linguagem Esquemática

Quando do surgimento do circuito integrado, próximo aos anos 60, os diagramas dos

circuitos a serem implementados eram totalmente desenhados à mão e, posteriormente, estes

diagramas em papel eram analisados por um grupo de engenheiros. Este ato configurava o


processo de verificação da época. Evidentemente que esta forma de trabalho era por demais

custosa em termos de tempo, além de muito suscetível a erros. Apenas no começo dos anos 70,

viu-se o surgimento de algumas ferramentas rudimentares de simulação lógica.

O desenvolvimento baseado em esquemático parte de uma representação elementar ao

nível de portas lógicas, como, por exemplo, a representação mostrada na Figura 6. O primeiro

passo para viabilizar a implementação e a simulação de uma forma mais automática foi a criação

de uma representação textual, chamada de netlist ao nível de portas lógicas.

Figura 6 – Diagrama esquemático de descrição de hardware.

A Figura 7 apresenta o netlist ao nível de portas lógicas, correspondente à representação

esquemática apresentada na Figura 6.

Baseando-se em descrições de netlist ao nível de portas lógicas, surgiram as ferramentas

de simulação e verificação dos circuitos que se desejava implementar fisicamente. Essas

ferramentas eram inicialmente classificadas como CAE (Computer Aided Engineering).

Posteriormente, surgiram ferramentas de implementação que permitiam o roteamento de

conexões para os dispositivos, as quais eram classificadas como CAD (Computer Aided Design).


Finalmente, durante os anos 80, surgiu a tecnologia EDA (Electronic Design Automation), que

encampou as tecnologias CAD e CAE.

BEGIN CIRCUIT = FIGURA7INPUT CONFIG_A, CONFIG_B, DADOS, LIMPA_A, LIMPA_B;OUTPUT Q, NQ;WIRE CONFIG, DADOS_N, LIMPA;

GATE G1 = NAND ( IN1 = CONFIG_A, IN2 = CONFIG_B, OUT1 = CONFIG);GATE G2 = NOT ( IN1 = DADOS, OUT1 = DADOS_N);GATE G3 = OR ( IN1 = LIMPA_A, IN2 = LIMPA_B, OUT1 = LIMPA);GATE G4 = DFF ( IN1 = CONFIG, IN2 = DADOS_N, IN3 = CLOCK,

IN4 = LIMPA, OUT1 = Q, OUT2 = N-Q);

END CIRCUIT = FIGURA7

Figura 7 – Netlist ao nível de portas lógicas.

No final dos anos 70 e início dos 80, começaram a surgir ferramentas que permitiam a

captura gráfica do esquemático para criação iterativa de circuitos, uso de recursos como algumas

bibliotecas de símbolos esquemáticos, possibilidade de conexão através de cabos feitos

facilmente através do mouse e a geração automática de netlist. Nesta época, o arquivo netlist já

podia ser repassado a um simulador que analisava o funcionamento do circuito. Também, estas

ferramentas já possibilitavam fazer a distribuição e o roteamento das conexões dos dispositivos.

Quando as FPGAs entraram no mercado, entre os anos de 1984 e 1985, era natural que

seu desenvolvimento se desse em cima de plataformas de desenvolvimento esquemáticas, já

difundidas na época. Entretanto, as plataformas necessitaram de algumas pequenas mudanças

para migrar do mundo de desenvolvimento ASIC para o mundo FPGA. No mundo ASIC, após

obter-se o netlist do circuito, partia-se diretamente para as etapas de simulação, distribuição e

roteamento. Devido às características da estrutura da FPGA (formada por blocos lógicos

reconfiguráveis, slices, células lógica etc.) duas novas etapas foram necessárias. A primeira era o

mapeamento, que se refere ao processo de associar entidades, como funções descritas no netlist

ao nível de portas lógicas, com as LUTs disponíveis na FPGA. O mapeamento não é uma função

trivial, especialmente porque existe uma infinidade de formas destas associações serem feitas. A

segunda nova etapa acrescida com o surgimento das FPGAs foi o empacotamento, no qual os


LUTs e os registradores são empacotados para os CLBs específicos. Também o empacotamento

não é um processo trivial devido ao grande número de possibilidades existentes, onde uma

possibilidade ótima deve ser buscada. Após estas duas novas etapas inclusas à metodologia,

segue-se a seqüência habitual do processo, com as etapas de simulação e de distribuição e

roteamento de conexões. O desenvolvimento feito através de linguagem esquemática ainda é

utilizado, muito embora para muitos engenheiros conceber seus projetos de forma esquemática é

algo muito distante na memória. Alguns fabricantes dispõem de apenas alguns recursos de

desenvolvimento baseados nesta forma para seus dispositivos mais novos e mantêm suas

bibliotecas completas para dispositivos mais antigos. Contudo, a captura esquemática ainda

encontra seu espaço no mercado, principalmente entre engenheiros mais antigos e entre pessoas

que precisam fazer pequenas alterações em seus legados de projetos.

2.1.3.2 Linguagem de Descrição de Hardware (HDL)

Ao longo dos anos 80, os projetos foram crescendo significativamente em complexidade e

tamanho, de forma que ferramentas esquemáticas não suportavam mais o desenvolvimento dos

mesmos de uma forma eficiente. Além disso, grandes projetos desenvolvidos em esquemático

mostravam-se por demais sensíveis a erros e consumiam muito tempo de desenvolvimento. Foi

neste cenário que algumas empresas desenvolvedoras de ferramentas de EDA começaram a

produzir ferramentas e fluxos de desenvolvimento baseados em linguagem de descrição de

hardware (HDL). Inicialmente, serão apresentados conceitos genéricos e comuns a todos HDL,

uma vez que existem diferentes HDLs padronizados (como VHDL e Verilog), além de HDLs

proprietários.

A idéia contida em uma linguagem HDL, considerando-se inicialmente um HDL

genérico, é que a funcionalidade de um circuito digital pode ser representada através de diferentes

níveis de abstração e que diferentes HDLs suportam estes níveis de abstração até um grau maior

ou menor. O primeiro e mais baixo nível de abstração corresponde ao nível de switch, o qual se

refere à habilidade de descrever um circuito como um netlist de transistores. Subindo um pouco o

nível de abstração, tem-se o nível das portas lógicas, o qual se refere à capacidade de descrever

um circuito como um netlist de funções de portas lógicas primitivas. Tanto o nível de switch


como o nível de portas lógicas, podem ser classificados como representações estruturais. O

próximo nível na escala superior de abstração HDL é a habilidade em suportar representações

funcionais, descrevendo funções usando equações booleanas, através de uma linguagem genérica

para qualquer tipo de HDL. O nível funcional de abstração engloba a representação de nível de

registro de transferência (RTL). O termo RTL cobre uma multidão de ações, mas a maneira mais

fácil de descrever este conceito é um projeto formado por uma coleção de registradores

interligados através de lógica combinacional. Na lógica combinacional que interconecta estes

registradores, comandos como when, rise, if, then, else são palavras-chave das quais a semântica

é definida pelo HDL específico. O nível de abstração mais alto suportado pelos HDL tradicionais

é conhecido como behavioral ou comportamental, o qual se refere à capacidade de descrever o

circuito usando construções como loops e processos. Este nível de abstração mais elevado

também suporta elementos como multiplicadores e somadores em equações. A Figura 8 apresenta

os diferentes níveis de abstração suportados por um HDL genérico.

Figura 8 – Níveis de abstração de um modelo HDL genérico.

Em 1985 surgiu no mercado a linguagem HDL chamada Verilog, desenvolvida pela

Gateway Design Automation. O Verilog era apresentado juntamente com um simulador lógico


chamado Verilog XL. Como linguagem, o Verilog original mostrava-se razoavelmente forte

quanto ao nível de abstração estrutural (níveis de switch e de portas lógicas), nível de abstração

funcional (equações booleanas e RTL), além de suportar algumas construções ao nível de

comportamento (algoritmos). Em 1989, a linguagem Verilog foi adquirida pela Cadence Design

Systems e, posteriormente, em 1995, o Verilog foi padronizado pela norma IEEE1364 devido à

popularidade obtida ao longos dos anos.

Em 1980, o departamento de defesa americano lançou o programa do circuito integrado

de altíssima velocidade (VHSIC), o qual objetivava avançar o estado da arte na tecnologia de CIs.

Baseado no VHSIC, em 1981, foi lançado o VHDL (Very high integrated circuit Hardware

Description Language), processo no qual a indústria se envolveu desde o começo, diferente do

ocorrido com o Verilog. Em 1983, um grupo de empresas iniciou um trabalho de padronização do

VHDL o que de fato ocorreu em 1985, mas de forma definitiva em 1993 através da norma

IEEE1076. Como linguagem, o VHDL possui fortes níveis de abstração funcional (equações

booleanas e RTL) e de comportamento (algoritmo) e ainda suporta alguma construção de

desenvolvimento ao nível de sistemas. Entretanto, se comparado ao Verilog, o VHDL é um

pouco fraco no que tange ao nível de abstração estrutural (nível de switch e de portas lógicas),

especialmente considerando sua capacidade de modelagem de atrasos. Facilmente, percebeu-se

que o VHDL não possui suficiente precisão de timing para ser usado como simulador. Por esta

razão, a conferência de desenvolvimento e automação (DAC) lançou em 1992 o VITAL, uma

solução para possibilitar ao VHDL habilidades para modelagem de timing tanto em FPGAs

quanto em ASICs.

Finalizando, torna-se importante destacar que devido ao uso de linguagens de descrição

de hardware mistas e pela chamada “guerra dos HDL” (ocorrida no começo dos anos 90), alguns

fabricantes optaram por lançar soluções proprietárias de HDL, como foi o caso do AHDL pela

Altera e do UDL/I pela associação japonesa de desenvolvimento da indústria eletrônica. Estas

soluções eram baseadas principalmente em Verilog e VHDL. Acredita-se que a razão de,

atualmente, o VHDL possuir uma penetração de mercado bem maior que o Verilog é que o

VHDL apresenta maior capacidade de reusabilidade, melhor estrutura de gerenciamento de

projeto além de suportar replicação de estruturas. Ou seja, enquanto o Verilog avança pouco ao


nível de abstração de comportamento (algoritmo) o VHDL preenche totalmente este nível

chegando a alcançar um nível de abstração superior, que seria o nível de sistema.

2.1.3.3 Linguagem C, SVP e DSP

Trabalhando-se com dispositivos que contêm milhões de portas lógicas, como, por

exemplo, ASICs, tem-se o problema de que, operando-se através do fluxo padrão de

desenvolvimento, muitos detalhes do projeto não são perceptíveis até a análise de timing. Este

fato suscitou a necessidade de visualização de alguns comportamentos específicos do sistema

antes de toda a etapa de desenvolvimento do dispositivo mostrar-se concluída. Uma solução

encontrada foi a criação da prototipagem virtual em silício (SVP). SVP é uma representação de

projeto que pode ser gerada de uma maneira relativamente rápida e que contém um nível mínimo

de informações, de forma a permitir que os desenvolvedores identifiquem e localizem problemas

em potencial antes de perder tempo desempenhando as tarefas de distribuição e roteamento de

conexões dos dispositivos. Teoricamente, o tempo investido em iterações no projeto usando SVP

é medido em horas, enquanto o tempo gasto em iterações no projeto, depois das etapas de

distribuição e roteamento, é medido em dias ou semanas. Um aspecto fundamental do fluxo SVP

é a habilidade deste ser gerado de uma forma fácil e rápida. A maioria dos SVPs para ASIC são

baseados na representação de netlist ao nível de portas lógicas. Como, em geral, as ferramentas

de síntese são pesadas e lentas, os SVPs utilizam um tipo de síntese “suja" e rápida.

Com o desenvolvimento das FPGAs atuais, com milhões de portas lógicas, o mesmo

problema com o qual se depararam os ASICS, depararam-se também as FPGAs, incluindo o fato

de que seu desenvolvimento consome tempo de distribuição, roteamento de conexões e análise de

timing. Assim, surgiram os SVPs para FPGAs. Um aspecto negativo deste processo é que, para

qualquer mudança que seja feita no projeto, as etapas de síntese, roteamento de conexões e outras

devem todas ser refeitas. Visando resolver este problema, muitos desenvolvedores de ferramentas

de desenvolvimento começaram a oferecer suporte ao conceito de SVP. Os geradores SVPs

desempenham seu próprio método de disposição e roteamento dos recursos (LUTS, CLBs, slices,

BRAMs etc.) oferecendo ao usuário uma análise prévia do funcionamento e ocupação dos

recursos do dispositivo. Em termos práticos, é importante antecipar que este tipo de recurso está


presente nas ferramentas que constituem os fluxos de desenvolvimento modernos, as quais serão

apresentadas em seções seguintes.

Uma opção de desenvolvimento que merece ser citada, muito mais por mostrar-se

interessante do que por sua receptividade entre desenvolvedores, é o modelo no qual a captura

inicial do projeto é feita usando a linguagem de programação C ou sua extensão C++. Um

exemplo deste tipo de modelo é o que utiliza uma ferramenta denominada System C, a qual pode

oferecer simulações de cinco a dez vezes mais rápidas que em VHDL ou Verilog, para

posteriormente ferramentas de síntese converterem programas em System C para netlist ao nível

de portas lógicas. Na verdade, System C, que é um ambiente open-source, é uma classe de

bibliotecas que facilita a representação de noções como timing, concorrência em execuções e

pinos de entrada e saída. Através destas bibliotecas, desenvolvedores poderiam capturar projetos

ao nível RTL de abstração. O lado fraco deste modelo, além de sua baixa penetração entre

desenvolvedores, está em ser consideravelmente mais difícil capturar um projeto ao nível RTL

em System C do que diretamente em VHDL. De acordo com [3], quando do surgimento das

ferramentas de síntese baseadas na linguagem C, seu foco principal era operar com fluxos de

desenvolvimento para ASICs, e assim, elas não desempenharam um bom trabalho direcionado

para FPGAs, apresentando especialmente problemas relacionados ao uso de elementos como

BRAMs, multiplicadores e assim por diante.

Outras ferramentas de desenvolvimento baseadas em linguagem C, C++ foram

desenvolvidas posteriormente, entretanto estas, tais quais o System C, não apresentaram uma

satisfatória penetração de mercado e não constituem o foco deste trabalho. A principal diferença

entre os fluxos de desenvolvimento baseados em linguagem C, C++ refere-se ao nível de

abstração que cada uma delas pode suportar. Em geral, apesar de elas oferecerem um bom nível

de sistema (algoritmos) e satisfatória capacidade de modelagem ao nível de transição, seus

conjuntos de funções sintetizáveis apresentam um nível de abstração relativamente baixo. Essa

falta de abstração de síntese faz com que as representações baseadas em C, C++ sejam utilizadas

apenas para aplicações específicas e não para qualquer tipo de projeto. Para uma difusão deste

modelo, existe a necessidade de um incremento considerável no conjunto de funções

sintetizáveis, bem como na confiabilidade das mesmas.


Conforme apresentado anteriormente neste trabalho, aplicações de DSP são as aplicações

mais promissoras e atraentes implementáveis em FPGA. Os projetos desenvolvidos atualmente,

mais e mais, requerem mais velocidade, tamanho e complexidade. Visando resolver este

problema e aumentar a produtividade, é necessário continuar-se aumentando o nível de abstração

usado para capturar as funcionalidades dos sistemas. Por esta razão, o desenvolvimento baseado

em linguagem esquemática apresentado previamente foi superado pela representação em VHDL.

Também, a tentativa de fluxos de desenvolvimento baseados em linguagem C, C++ deu-se

devido ao desejo de capturar aplicações e conceitos complexos de uma forma mais simples e

direta. No caso de áreas especializadas como DSPs, arquiteturas de sistemas podem alcançar um

fabuloso aumento de produtividade através de linguagens específicas de domínio (DSLs), as

quais oferecem uma forma mais concisa de representar tarefas específicas do que linguagens

como VHDL ou C. Algumas destas linguagens são Matlab e Simulink, as quais permitem que

desenvolvedores de DSP utilizem funções complexas que podem ocupar até mesmo uma FPGA

inteira, através de uma simples linha de comando ou um bloco de operação. Segundo [3], é uma

realidade que o padrão atual da indústria para verificação de algoritmos de DSP é Matlab.

Atualmente o termo Matlab se refere tanto a uma linguagem de desenvolvimento como a um

ambiente de simulação.

O nível de sistemas de desenvolvimento e ambientes de simulação são, conceitualmente,

de mais alto nível do que DSLs. Um bom exemplo disto é o Simulink, que, para uns, é apenas a

interface gráfica do Matlab e, para outros, é uma aplicação de modelagem dinâmica. O ponto-

chave desta questão é que não há uma regra fixa para a definição. Alguns desenvolvedores de

DSP preferem usar Matlab como ponto inicial de seus projetos, enquanto outros optam por

Simulink. Alguns dizem que isso depende da experiência de cada desenvolvedor, se este é mais

voltado para FPGA ou para DSP. Entretanto, esta divisão tende a sumir. Independentemente de se

optar pelo trabalho em Matlab ou Simulink, o primeiro passo é sempre a modelagem feita em

ponto flutuante. Números em ponto flutuante possuem a vantagem de oferecer uma precisão

extremamente. Entretanto, tentar operar com algoritmos em ponto flutuante em dispositivos como

FPGA exige um consumo demasiadamente grande de silício, além de que as operações tornam-se

bastante lentas. Assim, em algum momento do desenvolvimento, existirá a migração de ponto


flutuante para ponto fixo, uma representação que determina um número fixo de bits para

representar cada elemento. A este processo é dado o nome de quantização.

Anteriormente, algumas equipes de desenvolvimento iniciaram um processo de conceber

suas aplicações de DSP e fazer suas validações em Matlab para, posteriormente, migrar suas

aplicações manualmente para hardware, através de VHDL ou Verilog. Como já apresentado no

capítulo introdutório deste trabalho, este fluxo apresentava muitos problemas relacionados ao

tempo empregado no desenvolvimento, a grande complexidade envolvida e a vulnerabilidade a

erros. Também, eram encontradas dificuldades devido a grande diferença entre os domínios de

sistemas/algoritmos e o domínio RTL. Muitas vezes, o que significava uma otimização em um

domínio, não necessariamente representava a mesma otimização no outro, ou, ainda pior, poderia

até mesmo significar uma piora no desempenho do sistema.

Diante do exposto nesta seção, verificou-se a capacidade das FPGAs de atenderem as

aplicações de DSP. Entretanto, verificou-se também a necessidade de um fluxo de

desenvolvimento mais dinâmico, direto e confiável. Desta forma, estes fluxos de

desenvolvimento serão abordados nas Seções 2.2.2 e 2.3.1 deste trabalho.

2.1.4 Principais Fornecedores e Parceiros

O foco deste trabalho não é concentrar-se exclusivamente no estudo das FPGAs e nem

tampouco apresentar soluções de fabricante ‘A’ ou ‘B’. No entanto, torna-se especialmente útil a

seção presente, tanto para consulta como para conhecimento, a qual objetiva proporcionar uma

lista de fabricantes de FPGAs e de soluções relacionadas a simulações e implementações nas

mesmas.

Fabricantes de FPGAs:

Companhia Website

Actel Corporation www.actel.com

Altera Corporation www.altera.com


Anadigm Incorporated www.anadigm.com

Atmel Corporation www.atmel.com

Lattice Semiconductor Corporation www.latticesemi.com

QuickLogic Corporation www.quicklogic.com

Xilinx Incorporated www.xilinx.com Tabela 2.1 – Fabricantes de FPGAs.

Desenvolvedores de ferramentas completas de automatização de projetos eletrônicos

(EDA) para FPGAs:

Companhia Website Comentário

Altium Limited www.altium.com Ambiente de desenvolvimento em software e hardware

Cadence Design Systems www.cadence.com Ferramentas de simulação e ambiente de desenvolvimento inicial

Mentor Graphics Corporation www.mentor.com Ferramentas de simulação e síntese

Synopsys Incorporated www.synopsys.com Ferramentas de simulação e síntese Tabela 2.2 – Desenvolvedores de ferramentas completas para FPGAs.

Especialistas e desenvolvedores independentes de ferramentas de automatização de

projetos eletrônicos (EAD) para FPGAs:


0-In Design Automation www.0-in.com Verificação

AccelChip Incorporated www.accelchip.com Soluções de DSP para FPGAs

Aldec Incorporated www.aldec.com Simulação de linguagens misturadas

Celoxica Limited www.celoxica.com Síntese e desenvolvimento de sistemas

Elanix Incorporated www.elanix.com Soluções de DSP e algoritmos de verificação

Fintronic USA Incorporated www.fintronic.com Simulação

First Silicon Solution Incorporated

www.fs2com Processadores embarcados e instrumentação de chip

Green Hills Software Incorporated

www.ghs.com Softwares embarcados

Hier Design Incorporated www.hierdesign.com Prototipagem virtual


Novas Software Incorporated www.novas.com Verificação e análise de resultados

Simucad Incorporated www.simucad.com Simulação

Synplicity Incorporated www.synplicity.com Síntese

The Math Works Incorporated www.mathworks.com Desenvolvimento de sistemas e verificação

TransEDA PLC www.transeda.com Verificação de propriedade intelectual

Verisity Design Incorporated www.verisity.com Linguagens e ambientes de verificação

Wind River Systems Incorporated

www.windriver.com Softwares embarcados

Tabela 2.3 – Especialistas e desenvolvedores independentes de ferramentas para FPGAs.

Consultores e desenvolvedores de ferramentas especiais para FPGAs:


Dillon Engineering Incorporated www.dilloneng.com Arquiteturas de cores

Launchbird Incorporated www.launchbird.com Linguagem de desenvolvimento de junção de sistemas e compilação

Tabela 2.4 – Consultores e desenvolvedores especiais de ferramentas para FPGAs.

2.2 ISE Design Flow e System Generator

2.2.1 Project Navigator

O fluxo de desenvolvimento utilizado neste trabalho é baseado no ISE (Integrated

Software Environment) Design Flow da Xilinx Inc. Esse fluxo de desenvolvimento é aplicado

através da ferramenta chamada Project Navigator ou então pode ser desenvolvido diretamente

através do System Generator (o qual será abordado na seção seguinte) de uma forma mais

simples e direta. O fluxo de desenvolvimento é constituído pelas etapas de descrição (entrada),

síntese e implementação do projeto, além da etapa de programação do dispositivo [7]. Estas

etapas e a relação entre elas são apresentadas na Figura 9.


A etapa de descrição do projeto pode ser feita através da forma esquemática, de

linguagem HDL, através da entrada de arquivos de terminação edif, ngc ou ngo, obtidos a partir

de ferramentas de síntese, os quais serão apresentados em seguida, ou ainda através de projetos

em System Generator. Esta escolha determinará de qual tipo será o arquivo de mais alto nível que

descreverá o sistema. Nesta etapa de descrição, também é feita a caracterização do projeto quanto

à família do dispositivo onde o projeto será implementado e a descrição das ferramentas de

simulação e síntese que serão utilizadas, conforme pode ser observado na Figura 10 para o caso

da utilização do Project Navigator.

Descrição(entrada)

Síntese

Implementação

ProgramaçãoDo

Dispositivo

DESENVOLVIMENTO VERIFICAÇÃO

Simulação deComportamento

Simulação deFuncional

Análise de Timing

Simulação de Timing

Verificaçãono circuito

Descrição(entrada)

Síntese

Implementação

ProgramaçãoDo

Dispositivo

ProgramaçãoDo

Dispositivo

DESENVOLVIMENTO VERIFICAÇÃO





Análise de Timing

Análise de Timing



Verificaçãono circuitoVerificaçãono circuito

Figura 9 – Design Flow da Xilinx.

Uma vez determinado o dispositivo e a forma de descrição do projeto, o usuário pode

operar normalmente na interface do Project Navigator, mostrada na Figura 11.

O ponto número um da Figura 11 mostra a barra de ferramentas da interface. O ponto

número dois apresenta a janela de fontes, ou seja, a janela dos arquivos fontes que constituem o

projeto. Um projeto completo é constituído por várias fontes e diferentes tipos de arquivo. O

ponto número três da figura indica a janela de processos. Os processos como síntese, simulação,

geração da implementação, entre outros, ficam disponíveis nesta janela e podem ser acessados de


uma forma direta através da mesma. O ponto número quatro aponta a área de trabalho. Por

exemplo, se um arquivo do tipo esquemático for selecionado, a interface gráfica esquemática

estará disponível na área de trabalho. Se for selecionado um arquivo do tipo VHDL, o editor

VHDL estará visível na área de trabalho. Por fim, a área representada pelo ponto número cinco

da figura é a janela de transcrição, onde é exibido o status das operações em processamento bem

como das já processadas.

Figura 10 – Etapa de Descrição do Design Flow da Xilinx.

Na etapa de descrição do projeto, podem ser utilizados Núcleos de Propriedade Intelectual

(NPI ou IP Cores), tanto se a entrada for feita na forma esquemática quanto na forma textual de

VHDL ou Verilog. Existe uma ferramenta do Design Flow chamada CORE Generator, que

oferece um grande leque de funções já otimizadas para linguagens de descrição de hardware.

Através desta ferramenta, cria-se um componente NPI desejado (um decodificador de Viterbi, por

exemplo) e adiciona-se este componente ao projeto. A inserção no Project Navigator é dada de

uma forma direta e intuitiva apenas acrescentando o arquivo gerado ao projeto. Uma vez o NPI

inserido no projeto ele já encontra-se disponível para ser utilizado. No caso da entrada ser através

de descrição HDL, é necessário apenas criar um componente e utilizá-lo normalmente, o que é

uma tarefa relativamente usual para programadores de HDL. Para o caso da entrada do sistema

ser feita de forma esquemática, é necessário criar-se o símbolo esquemático a partir do arquivo


gerado pelo CORE Generator e o componente aparecerá disponível junto à biblioteca de símbolos

esquemáticos. O tema núcleos de propriedade intelectual será abordado em mais detalhes na

Seção 2.3, mas desde já é importante destacar que, para ser possível a criação do componente a

partir do NPI desejado, o mesmo deve estar disponível. Núcleos de propriedade intelectual mais

complexos, na maioria das vezes, são comercializados de forma independente e, em geral,

apresentam um custo consideravelmente elevado.

Figura 11 – Interface da ferramenta Project Navigator da Xilinx.

Após a etapa de descrição estar finalizada, o usuário pode ainda, antes de partir para as

etapas de síntese e implementação, criar restrições de timing para o sistema, bem como definir o

mapeamento dos pinos de entrada e saída do dispositivo. Caso o usuário opte por não criar

restrições de timing, um arquivo padrão será criado pelo sistema no momento da síntese. O

arquivo que determina o mapeamento das portas de entrada e saída do dispositivo deve

obrigatoriamente ser elaborado, no máximo, durante a etapa de implementação. Sem a elaboração

deste arquivo (de terminação UCF - User Constraint File), o processo de implementação não é


iniciado, pois é ele que determina para quais pinos do dispositivo as entradas e saídas do sistema

serão mapeadas.

O processo de síntese é desempenhado pelo XST (Xilinx Synthesis Technology), uma

ferramenta da Xilinx que sintetiza o projeto após sua descrição para criar um arquivo específico

de netlist chamado NGC (Netlist File). O arquivo NGC é um netlist que contém tanto dados

lógicos como restrições que levam aos arquivos EDIF (Electronic Design Interchange Format) e

NCF (Netware Command File). O processo de implementação é dado pelo próprio ISE com

interação com o XST.

Em geral, os projetos são compostos de macros e lógica combinatória. Exemplos de

macros são registradores, acumuladores, multiplexadores, operadores aritméticos e RAMs. A

utilização de macros pode melhorar consideravelmente o desempenho da síntese de projetos.

Assim, é importante usar algumas técnicas de codificação para modelar os macros de forma que

estes possam ser processados da melhor maneira possível pelo XST. Durante a execução, a

ferramenta XST primeiro tenta identificar o maior número de macros possíveis, que são passados

para o próximo nível - Low Level Optimization. Informações detalhadas sobre o processamento

de macros podem ser encontradas no arquivo XST LOG, que apresenta informações como o

conjunto de macros e sinais associados inferidos pela ferramenta XST com código VHDL,

estatísticas totais de reconhecimento de macros e o número e tipos de macros preservados pelo

Low Level Optimization. Os passos executados pelo XST durante a síntese e otimização são o

mapeamento e otimização numa entity/module por entity/module basis além da otimização global

em todo o projeto.

As etapas de síntese e implementação podem ser otimizadas para melhorar o desempenho

de velocidade ou para minimizar a área ocupada de circuito. A otimização para velocidade

prioriza a redução no número de níveis lógicos e, além disso, aumenta a freqüência de operação

do circuito. Por outro lado, na otimização para minimização de área, a prioridade é a redução da

quantidade de lógica utilizada para execução do projeto. No final da síntese, a ferramenta XST

relata informações de timing para o projeto. O relatório mostra a informação para todos os

domínios possíveis do arquivo netlist. A ferramenta XST também tenta mapear lógica para

memórias RAM do dispositivo durante a etapa de síntese avançada. Se algumas das exigências de


velocidade ou timing não forem satisfeitas, o XST não mapeia a lógica para blocos de memória

RAM e gera uma mensagem de advertência. Se a lógica não puder ser colocada em um único

bloco RAM, o XST pode ainda utilizar vários blocos de memória RAM para implementá-la.

É considerável o fato de que existe a possibilidade de utilizar-se outras ferramentas de

síntese além do XST que constitui o Design Flow da Xilinx. Ferramentas de síntese como

Leonardo Spectrum da Mentor Graphics Corporation e Synplify da Synplicity Incorporated

podem ser perfeitamente integradas ao fluxo de desenvolvimento, embora elas, ainda que

reconhecidamente eficientes, apresentem um valor de compra bastante elevado e,

conseqüentemente, um acréscimo no custo de desenvolvimento.

Além disso, na etapa de implementação é feito também o roteamento e a definição física

dos recursos lógicos do dispositivo que serão utilizados.

O um ponto interessante de se trabalhar com o Project Navigator está no fato de que as

etapas descritas anteriormente podem, cada uma delas, ser acompanhada pela janela de

transcrição, apontada como item cinco da Figura 11.

A etapa de implementação física do projeto consiste na programação do dispositivo e

também na geração do arquivo binário que será efetivamente gravado na FPGA. Essas tarefas são

diretamente selecionadas na janela de processos, indicada pelo número três na Figura 11. Para

este processo é gerado então um arquivo bitstream de extensão .bit (para ser gravado diretamente

na FPGA). Posteriormente, é possível gerar um arquivo específico para ser gravado na memória

flash que acompanha a FPGA (formato este que pode ser .bit, .tec, .ufp, .exo, .hex, .bin, .isc).

Embora possuam diferentes formatos, todos estes arquivos carregam a mesma informação. A

vantagem da geração de arquivos destinados à memória flash é que, uma vez gravado na

memória, o projeto será automaticamente carregado para a FPGA toda vez que o circuito for

alimentado. No caso de arquivos de extensão .bit gravados diretamente na FPGA, a cada

interrupção na alimentação, o dispositivo deve ser reprogramado pelo usuário, via computador. A

programação dos dispositivos, tanto diretamente na FPGA como via memória flash, é dada

através da ferramenta IMPACT, que também constitui o Design Flow e também pode ser


acessada via Project Navigator. A interface do IMPACT, mostrada na Figura 12, é bastante

intuitiva. Uma observação pertinente a ser feita sobre esta figura é que a placa identificada pelo

IMPACT no momento da captura da mesma possui cinco dispositivos programáveis,

representados pelas cinco estruturas de cor cinza, localizadas na parte superior da figura.

A última etapa do fluxo de desenvolvimento, que não é uma etapa obrigatória uma vez

que ela se dá após o programa estar efetivamente rodando no dispositivo, refere-se à verificação

do circuito já gravado na FPGA. Esse processo se dá com o uso da ferramenta da Xilinx

denominada ChipScope. O ChipScope é um analisador lógico avançado que serve para que os

sinais internos do projeto possam ser analisados. É importante destacar que a memória de

amostragem do ChipScope será limitada pelos recursos da própria FPGA, onde estará rodando o

circuito gravado. Outro detalhe significativo está na taxa de amostragem do ChipScope que será

definida através da escolha de um sinal de relógio entre os disponíveis no circuito.

Figura 12 – Interface da ferramenta IMPACT.

2.2.2 System Generator

O System Generator é a ferramenta de linguagem de mais alto nível que faz parte do

Design Flow da Xilinx. O System Generator oferece um ambiente de desenvolvimento para

modelagem de sistemas, bem como uma forma de implementação fiel ao sistema modelado. A


grande vantagem do System Generator, no entanto é que ele é desenvolvido sobre a plataforma

Simulink do Matlab, como descrito na Seção 2.1, uma referência no desenvolvimento de

algoritmos de DSP. No System Generator, a partir do esquema modelado, é possível gerar o

código do projeto para implementação em hardware. O System Generator não visa substituir o

VHDL ou Verilog, mas ele torna possível focar outras dificuldades de projeto que não a

linguagem, obtendo-se um ganho de produtividade bastante significativo [8].

A implementação em System Generator torna-se especialmente eficiente a partir do uso

dos núcleos de propriedade intelectual (NPIs), dos mais simples aos mais complexos, de

operações aritméticas até algoritmos complexos de DSP, que aparecem dispostos nos toolboxes

do Simulink tal qual mostrado pela Figura 13.

A chave para utilização do System Generator é o emprego de dois blocos chamados

Gateway In e Gateway Out. O bloco Gateway In representa a entrada do sistema. Em

desenvolvimentos e simulações feitas no ambiente Simulink, ele representa a interface entre o

universo de ponto flutuante, Simulink, e o universo de ponto fixo, que é efetivamente

implementada no hardware. Em termos de implementação, cada bloco Gateway In representa

uma entrada (fisicamente falando, pinos da FPGA) do dispositivo. No Gateway In é necessário

informar o tipo de dado de entrada (booleana, ponto fixo com sinal ou ponto fixo sem sinal) e o

tamanho, em bits, do mesmo. Já o Gateway Out, por sua vez, representa a saída do universo de

ponto fixo para ponto flutuante, quando em simulação no Simulink, e representa pinos de saída

no dispositivo (pinos do chip) em termos de implementação.

Todo sistema desenvolvido em System Generator deve obrigatoriamente possuir um

bloco também denominado System Generator, disponível nos toolboxes Xilinx do Simulink e o

qual pode ser identificado no canto superior direito da Figura 13. Este bloco determina

características do projeto como a família do dispositivo a ser utilizado, freqüência de operação do

circuito, ferramenta utilizada para síntese, linguagem de descrição de hardware utilizada (VHDL

ou Verilog) além do tipo de compilação a ser feita. O tipo de compilação pode ser, por exemplo,

HDL netlist. Nesta compilação, é gerado um arquivo de netlist baseados em arquivos VHDL ou

Verilog que contém tanto a lógica quanto às informações de restrição de desenvolvimento. Isso

significa que todo HDL, NPIs e arquivos de restrição que correspondem ao System Generator


estarão interligados por um netlist através de um arquivo ngc. O arquivo gerado pode ser

considerado um NPI e ser então aproveitado para reutilização em outros projetos.

Figura 13 – Browser das bibliotecas do Simulink mostrando os toolboxes da Xilinx.

Uma alternativa considerável de compilação é o modo bitstream. Com este modo de

compilação, a partir do System Generator, gera-se diretamente o arquivo binário para ser gravado

na FPGA. No caso deste tipo de compilação, duas observações são importantes. Primeira, todos

os blocos Gateway In e Gateway Out devem ser informados sobre os pinos do dispositivo para os

quais serão mapeados, possibilitando desta forma, a geração do arquivo de terminação .ucf.

Segunda, depois de gerado, o arquivo bitstream deverá ser normalmente carregado para a FPGA,

através da ferramenta IMPACT mostrada na Figura 12.


Outra importante opção de compilação é a compilação para co-simulação em hardware.

Este recurso de co-simulação em hardware é bastante importante, pois permite que um sistema

inteiro seja modelado e apresentado dentro de uma “caixa preta” para ser utilizado no ambiente

Simulink, enquanto, na verdade, sua função é executada na FPGA. A interface de transferência

de dados entre a FPGA e o microcomputador pode ser feita, durante a co-simulação em hardware,

através de um barramento PCI ou de um cabo JTAG/Paralelo proprietário Xilinx. O que esta

compilação faz, na verdade, é gravar o projeto na FPGA e disponibilizar um bloco no ambiente

Simulink que representa este projeto. Desta forma, duas grandes vantagens são obtidas. A

primeira refere-se ao tempo de simulação. As restrições para processamento de funções

complexas passam do processador do computador para a FPGA. Segunda, este recurso torna

possível incorporar uma FPGA diretamente no ambiente Simulink, podendo-se, assim, observar

seu efeito dentro de um sistema. A partir desta co-simulação em hardware, a FPGA acrescentada

ao Simulink passa a ser também uma “caixa preta” no projeto.

Percebe-se que, no momento da compilação, tudo que estiver entre os Gateway In e

Gateway Out serão convertidos para a linguagem de hardware. É importante destacar que, entre

os blocos de Gateway In e Gateway Out, somente podem existir funções do universo Xilinx,

toolboxes que podem ser identificados por serem estilizados com um logotipo da Xilinx,

conforme podem ser observados na coluna do lado direito da Figura 13. Destes blocos, não todos

constituem núcleos de propriedade intelectual. Alguns, como os da biblioteca de elementos

básicos casualmente mostrados na Figura 13, são apenas operadores que poderiam ser

desenvolvidos com poucas linhas de código. Porém, existem NPIs mais complexos que, em geral,

apenas suas versões para demonstração acompanham o kit básico de desenvolvimento, como é o

caso da maioria dos codificadores de canal utilizados em telecomunicações.

Um outro importante recurso disponível no System Generator é o bloco chamado “Black-

Box”. Ele permite que uma função ou até mesmo um projeto inteiro, já descrito em VHDL, possa

ser incorporado ao projeto. A vantagem deste recurso está primeiramente na reutilização de

antigas funções escritas em VHDL, e depois, na integração em um único arquivo de mais alto

nível para a geração do arquivo bitstream. Além disso, com o emprego de um outro bloco

denominado “ModelSim” é possível inclusive integrar a simulação do HDL com a simulação de

todo o circuito. Este recurso da integração da simulação HDL com a integração Simulink é


essencialmente importante quando o desenvolvedor não possui uma placa disponível para realizar

a co-simulação em hardware, por exemplo.

O fluxo de desenvolvimento, a partir do System Generator até a etapa de gravação do

programa na FPGA, é exibido pela Figura 14.

Figura 14 – Fluxo de desenvolvimento a partir do System Generator até a etapa de download na FPGA.

2.2.3 Simulação HDL

Algumas ferramentas, como as que compõem o Design Flow da Xilinx, são projetadas

para serem usadas de forma integrada com várias ferramentas de simulação. O simulador HDL

torna-se importante na medida em que valida toda a implementação feita em linguagem de

hardware, independentemente da forma de entrada do projeto (seja ela em VHDL, esquemático

ou System Generator). Enquanto a simulação feita, por exemplo, no System Generator se dá pelo

modelo de simulação do próprio Simulink, a simulação realizada por simuladores HDL é feita a

partir do netlist após a síntese.


O modelo padrão de simulação HDL do Design Flow da Xilinx é o ModelSim da Mentor

Graphics Corporation. O ModelSim é um ambiente de simulação HDL onde podem ser

verificados os modelos de funções, timing do projeto e o código fonte HDL. Além disso, o

ModelSim é otimizado para ser usado com todas as configurações do Design Flow. Tanto o

System Generator quanto o Project Navigator, geram um arquivo para utilização do simulador

ModelSim durante a etapa de síntese. Na etapa de síntese do Project Navigator, existe uma “sub-

etapa” chamada de “Geração de Modelo de Simulação”. Através desta tarefa, o netlist em

linguagem de hardware gerado contém as primitivas e a biblioteca de simulação (denominada

UNISIM) para ser usada pelo ModelSim. As simulações podem ser executadas de forma

independente ou associadas ao Project Navigator. No entanto, antes que o projeto seja compilado,

faz-se necessária a compilação das suas bibliotecas (NPIs) com o ModelSim. Há basicamente

duas maneiras de se compilar bibliotecas de NPIs: a primeira é através da interface gráfica,

utilizando o Project Navigator; a segunda é mais complexa e exige compilação via linha de

comando. No entanto, as duas opções nem sempre estão disponíveis, já que são disponibilizadas

dependendo da versão do programa que compila as bibliotecas via linha de comando [9]. No

System Generator, para a criação dos arquivos de simulação, é necessário selecionar a opção

“Create Testbench” no momento da compilação. Por fim, cabe ressaltar a existência de outras ferramentas de simulação HDL que podem

também ser utilizadas, como o Riviera da Aldec Incorporation e o NC-Sim da Cadence Design

Systems.

2.3 AccelChip (AccelDSP) e AccelWare

2.3.1 AccelChip (AccelDSP)

AccelDSP é uma ferramenta de síntese de alto nível que permite transformar projetos do

Matlab, descritos em ponto flutuante, para um módulo de hardware, em ponto fixo, para ser

implementado em silício. O AccelChip, ferramenta de desenvolvimento também utilizada nos

trabalhos apresentados nesta dissertação, foi desenvolvido pela AccelChip Incorporation,

empresa até então localizada na Califórnia. No primeiro semestre de 2006, a AccelChip foi


adquirida pela Xilinx, a qual alterou o nome da ferramenta de AccelChip DSP para AccelDSP e

fez com que esta passasse a fazer parte das soluções do Xilinx Xtreme DSP. Como durante o

desenvolvimento dos trabalhos práticos a ferramenta possuía um nome e durante a elaboração

deste documento possuía outro, ainda que sendo a mesma ferramenta, ambos os nomes são

apresentados. Em termos práticos, o fluxo de desenvolvimento e os recursos disponíveis, apesar

da alteração de nome, continuaram os mesmos. Contudo, destaca-se que os relatórios e imagens

de interfaces com usuário foram obtidos a partir do AccelChip, recurso efetivamente utilizado ao

longo do projeto. A única mudança substancial foi que a possibilidade de operar-se com FPGAs

de diferentes fabricantes foi substituída pela utilização restrita a FPGAs Xilinx.

Modelo RTL

(VHDL/ Verilog)

1

2

3

4 5

6

7

8 9

1011

Netlist(EDIF)

ArquivoConfig

Modelode

SimulaçãoHDL

Relatóriode

Simulação

Relatóriode

Simulação

Diretóriode

Projeto

Modeloem

Ponto Fixo

Modeloem

Ponto Flutuante

Diretivasde

Projeto

Projetona

Memória

VerifyFloating

Point

Verify Fixed PointProject

Generate Fixed PointAnalyse

Verify RTL Synthesize RTL

Generate RTL

ImplementVerify Gate Level

Comparação

PONTO FIXOPONTO FLUTUANTE

Verificação do código fonte

Modelo RTL

(VHDL/ Verilog)

11

22

33

44 55

66

77

88 99

10101111

Netlist(EDIF)

ArquivoConfig

Modelode

SimulaçãoHDL

Relatóriode

Simulação

Relatóriode

Simulação

Diretóriode

Projeto

Modeloem

Ponto Fixo

Modeloem

Ponto Flutuante

Diretivasde

Projeto

Projetona

Memória

VerifyFloating

Point

Verify Fixed PointProject

Generate Fixed PointAnalyse

Verify RTL Synthesize RTL

Generate RTL

ImplementVerify Gate Level

Comparação

PONTO FIXOPONTO FLUTUANTE

Verificação do código fonte

Figura 15 – Fluxo de desenvolvimento da ferramenta AccelChip (Accel DSP).


A Figura 15 apresenta as onze etapas do fluxo de desenvolvimento, dadas através do

AccelChip. No interior desta figura, é possível observar pequenos blocos com legendas em

inglês, os quais assim foram intencionalmente mantidos para indicar que estas são as etapas

acessadas através da interface do AccelChip e que estes são os ícones que representam cada

etapa, tal qual empregados no programa. Estas etapas serão descritas em seguida e mostradas

através da janela de processos, localizada no canto esquerdo das Figuras 16, 17 e 18.

O ponto de partida para a implementação em hardware através do AccelChip é o mesmo

utilizado pela maioria dos desenvolvedores de programas de DPS, que é escrever o algoritmo em

ponto flutuante, usando o Matlab. No entanto, o programa deve ser escrito de forma a respeitar

algumas regras de implementação impostas pelo AccelChip, as quais são descritas no “Guia de

Estilo de Matlab para Síntese” [10]. Uma vez escrito o programa respeitando tais regras, o

usuário pode começar a interagir com a ferramenta. Essa etapa corresponde ao item um da Figura

15.

O programa a ser implementado deve ser organizado em forma de função (M-File

Function), sendo os parâmetros de entrada da função os próprios pinos de entrada da FPGA, e os

parâmetros de saída, os pinos de saída do dispositivo. Um outro programa (do tipo Script M-File)

deve ser criado. Neste segundo arquivo, os parâmetros de entrada devem ser inicializados, e o

primeiro programa deve ser chamado de dentro de uma rotina de repetição (loop) feito por um

comando do tipo for. Esta rotina de repetição deverá variar do valor um até o número de amostras

desejado. Tendo-se estes dois arquivos, pode-se abrir a interface gráfica do AccelChip e iniciar-se

o uso da ferramenta, caracterizando-se desta maneira a etapa descrita pelo item número dois da

Figura 15.

Dentro do ambiente AccelChip, o primeiro passo é a criação do projeto. O projeto poderá

ser inteiramente novo ou pode-se fazer uso de algum NPI disponibilizado pelo AccelWare, o qual

será visto na seção seguinte. No ato da criação do projeto, o usuário deverá informar o tipo de

FPGA a ser utilizada e a linguagem de hardware para qual o projeto deve ser sintetizado, se

VHDL ou Verilog. O passo seguinte, descrito pela Figura 16, representa a indicação das

ferramentas de síntese, roteamento, simulação HDL, bem como versão do System Generator e

Matlab utilizados.


O usuário deverá então fazer a verificação e análise do programa em ponto flutuante,

clicando no ícone correspondente na janela de processos, à esquerda na Figura 16. De fato, todos

os processos são iniciados desta forma. Quando essas operações são solicitadas, o AccelChip

executa o próprio Matlab, que é o responsável pela análise em ponto fixo. Após estas etapas, o

usuário deverá iniciar o processo de geração do programa em ponto fixo. Os parâmetros de

entrada e saída, bem como as variáveis internas do algoritmo, são todas quantizadas e um

relatório é apresentado, tal qual mostrado na Figura 17. Destaca-se que essas quantizações são

todas auto inferidas pela ferramenta, entretanto as quantizações podem ser livremente alteradas

pelo usuário, através da janela de propriedades, entre a janela principal e a janela de processos,

exibida na Figura 17.

Figura 16 – Interface do AccelChip para definição das ferramentas utilizadas.


O processo de verificação de ponto fixo, o qual corresponde ao sexto passo no fluxo de

desenvolvimento, é vital para uma correta implementação do algoritmo, inicialmente

desenvolvido em Matlab. Uma cautelosa análise é imprescindível para observar se a quantização

se deu de forma satisfatória ou não. Pode ocorrer da quantização ser realizada com um número

não ideal de bits. Excesso de bits causará uma ocupação desnecessária de área de silício do

dispositivo e maior tempo de processamento, enquanto a escassez de bits pode conduzir a não

convergência do algoritmo. Outra informação importante fornecida pela ferramenta é a

ocorrência ou não de erros de overflow. Um recurso bastante útil para este tipo de comparação é

graficar os resultados do algoritmo em ponto fixo e em ponto flutuante e compará-los, tal qual

mostrado na parte superior direita da Figura 15. Para tanto, basta inserir um comando plot no

corpo do arquivo do tipo Script M-File.

Figura 17 – Interface do AccelChip mostrando a tabela de quantização.


A sétima e oitava etapas no fluxo de desenvolvimento referem-se à geração e à

verificação do modelo em RTL (Register Transfer Level, como já apresentado na Seção 2.1, em

VHDL ou Verilog), respectivamente. Após, finalmente, chega-se à nona etapa, a de síntese RTL.

Um dos melhores recursos do AccelChip, provavelmente o mais interessante deles, é que, após a

etapa de síntese, é disponibilizada ao usuário a opção de exportar todo o projeto para o System

Generator, conforme mostra a Figura 18. Em outras palavras, todo o projeto convertido para

linguagem de hardware torna-se agora disponível no System Generator, como mais uma

biblioteca dos toolboxes do Simulink, disponíveis para implementação em hardware. Além da

facilidade de uso, essa facilidade possibilita um recurso adicional extraordinário, o da

reusabilidade diretamente no ambiente Simulink.

Figura 18 – Interface do AccelChip mostrando o recurso de exportação para o System Generator.


As etapas seguintes são as de implementação e verificação, etapas dez e onze

respectivamente. A etapa de implementação é dada através das ferramentas de roteamento (no

caso da Xilinx, o XST) e a etapa de simulação através do simulador HDL. Após, pode-se operar o

projeto no ISE para geração do arquivo binário para gravação no dispositivo.

Após cada etapa do processo, é exibido, na área de trabalho da ferramenta, um relatório,

como pode ser observado, por exemplo, nas Figuras 17 e 18. No entanto, após a última etapa, é

apresentado um relatório sobre os dados de implementação, baseado em aproximações fornecidas

pelo software, mostrado na Figura 19. Este relatório apresenta informações importantes como

área de silício que o programa ocupará no dispositivo, taxa atingida, ocupação dos pinos de

entrada e saída, entre outros dados [11].

Figura 19 – Interface do AccelChip mostrando o relatório final de desenvolvimento.


2.3.2 AccelWare e Núcleos de Propriedade Intelectual (NPIs ou IP Cores)

Os projetos atualmente desenvolvidos para FPGA são tão grandes e complexos que é

praticamente inviável criar-se cada parte do sistema a cada novo projeto. Uma solução para este

problema é a reutilização de partes prontas como solução para grandes sistemas. Qualquer bloco

funcional existente é tipicamente referenciado como núcleo de propriedade intelectual (NPI ou IP

Core). As três fontes principais destes núcleos são, em ordem, blocos criados em projetos

anteriores, blocos fornecidos por fabricantes de FPGA e blocos fornecidos por desenvolvedores

de NPIs [3].

Em geral, os NPIs oferecidos são feitos ao nível de netlist, pois os desenvolvedores destes

núcleos não pretendem que seus códigos fontes, descritos em linguagem RTL (VHDL/Verilog),

circulem sem algum tipo de proteção. Para o usuário final, a única vantagem de operar com esta

forma de núcleos é que eles são bastante otimizados se comparados aos que porventura são

oferecidos em linguagem RTL. Geralmente neste tipo de caso, o desenvolvedor do núcleo oferece

também (o que é transparente ao usuário final) um modelo de verificação para viabilizar

simulações. Infelizmente, não existe uma padronização quanto à criptografia dos núcleos de

propriedade intelectual oferecidos, e cada desenvolvedor usa seu próprio método. Assim, núcleos

desenvolvidos por fabricantes de FPGAs como Xilinx e Altera são implementáveis apenas nos

chips de seus respectivos fabricantes. A principal vantagem deste cenário é que os provedores

dos núcleos já investiram bastante tempo e esforço na síntese avançada e na otimização de

funções, alcançando assim uma implementação ótima.

O AccelWare é um vasto conjunto de bibliotecas de funções do Matlab sintetizáveis para

FPGA, ou seja, um conjunto de núcleos de propriedade intelectual de funções disponíveis no

Matlab, o qual é oferecido juntamente com o AccelChip. Uma grande vantagem do AccelWare,

até antes da aquisição da AccelChip pela Xilinx, era que os núcleos oferecidos pelo AccelWare

eram implementáveis em FPGAs de qualquer fabricante. Após a aquisição, por razões comerciais

óbvias, estes núcleos passaram a ser implementáveis apenas em FPGAs Xilinx.

O Accelware oferece um caminho direto para implementações em hardware a partir de

complexos toolboxes do Matlab. Tanto é possível mapear as funções do AccelWare para modelos


RTL, sintetizáveis para a inclusão em um projeto em RTL maior, quanto o código AccelWare

também pode ser chamado a partir do arquivo Matlab para ser sintetizado pelo AccelChip. As

funções do Accelware são criadas usando código Matlab voltadas para implementação. Por

exemplo, a função FFT original do Matlab calcula a resposta em freqüência de um sinal sem o

senso de throughput de relógio. Entretanto, o throughput realizado em hardware é determinado

pelas configurações de BRAMs, pontos de amostra etc., e pode variar em centenas de ciclos de

relógio dependendo da escolha destes parâmetros. As funções do AccelWare possibilitam a

configuração de uma série de parâmetros de implementação, como no caso da FFT, mostrado na

Figura 15.

Figura 20 – Seleção de parâmetros da FFT do AccelWare.


Adicionalmente, os NPIs do AccelChip utilizam automaticamente métodos heurísticos

para selecionar a arquitetura ótima de hardware para uma função auto inferida. Por exemplo, uma

função seno auto inferida será implementada utilizando CORDIC (algoritmo de rotação de

coordenada usado para calcular funções trigonométricas), tabelas bipartidas ou uma arquitetura

com tabelas de lookup interpoladas linearmente, incluindo diferentes combinações de

compartilhamento de recursos pipelining, baseado nas requisições feitas pelo usuário como

tamanho de variáveis, ocupação e área de silício. O AccelChip considera todos estes fatores antes

de selecionar qual será a arquitetura ótima para a função ser auto inferida.

63

63

Capítulo 3 O Sistema de TV Digital sobre IP

O desenvolvimento de um sistema de televisão digital envolve diversas tecnologias de

diferentes áreas. Por isso, é essencial que uma visão sistêmica global dos assuntos relacionados a

este trabalho seja apresentada. A proposta inicial do modelo a ser implementado é apresentada na

forma de diagrama de blocos, de acordo com a concepção do autor, na Figura 21. Desta maneira,

busca-se, neste capítulo, introduzir, de uma forma simples e direta, as principais tecnologias

envolvidas neste trabalho, enquanto os tópicos considerados mais pertinentes ao mesmo serão

abordados com mais detalhes nas seções posteriores.

Vídeo “Bruto”

Codificadorde Vídeo

Empacotador UDP / IP

Conversor Camada

MAC

CodificadorReed Solomon

Mapeador Codificador LDPC

Conversor D/A

Amplificador de Potência

Moduladore

Alamouti

LNAe

AGC

ConversorA/D

Demapeador e LLR

DesempacotadorUDP / IP

Decodificadorde Vídeo

Reprodutor de Vídeo

Demoduladore

Alamouti

DecodificadorLDPC

Aleatorizador

ConversorRebaixador

Conversor Camada

MACDesaleatorizador

DecodificadorReed

Solomon

TRANSMISSOR

RECEPTOR

ConversorElevador

Figura 21 – Diagrama de blocos do sistema de televisão digital proposto.

Capítulo 3 – O Sistema de TV Digital sobre IP 64

3.1 Vídeo Bruto

Para representar uma imagem bidimensional preto-e-branco com uma tensão

unidimensional, na produção/reprodução do vídeo, ocorre uma rápida varredura de feixe de

elétrons no sentido horizontal e lenta no sentido vertical, captando-se a intensidade de luz. O

resultado dessa varredura é denominado quadro. O vídeo colorido adota o mesmo princípio de

funcionamento, diferenciando-se no fato de que, ao invés da utilização de um único feixe, três

deles são utilizados. Os padrões de cor mais utilizados na captura e na reprodução, de acordo com

[12], são o RGB (vermelho, verde e azul), o CMY (ciano, magenta e amarelo) e o YIQ

(luminância, em fase e quadratura).

A varredura do vídeo pode ser entrelaçada ou progressiva. Na varredura entrelaçada, o

quadro é formado por dois campos tomados em instantes distintos. O primeiro campo é formado

pelas linhas pares do quadro, e o segundo, pelas linhas ímpares. Além disso, o tipo do quadro

também pode variar. Por exemplo, no padrão de TV analógica em cores NTSC, o quadro

apresenta 525 linhas de varredura, uma relação horizontal/vertical (razão de aspecto) 4:3 e uma

taxa de reprodução de 30 quadros por segundo. Por sua vez o padrão PAL (B, G, H, I e N) possui

quadros com 625 linhas e taxa de 25 quadros por segundo.

Posteriormente a essas tecnologias, surgiu o conceito de televisão de alta definição

(HDTV) que proporcionava um significativo incremento na qualidade devido ao aumento do

número de linhas de varredura. Finalmente, surgiu a digitalização do vídeo e o uso de tecnologias

digitais para suas respectivas gerações, transmissões e reproduções. O primeiro sistema de alta

definição foi analógico, desenvolvido pela NHK Science and Technical Research Laboratories

(STRL) em 1980, apresentava uma resolução de 1125 linhas e foi denominado MUSE.

Entretanto, o sistema não teve penetração de mercado, devido às limitações técnicas da época e

pelo advento dos padrões digitais.

O sistema digital mais rudimentar é dado através da seqüência de quadros, os quais são

formados por elementos de imagem chamados pixels. Assim, uma imagem é formada por vários

pixels. Um pixel deve conter no mínimo um único bit no caso de uma imagem monocromática


elementar. Uma imagem pode também ser representada com pixels de 8 bits, onde cada pixel

representa um dos 256 níveis possíveis de uma escala de cinza. Dessa forma, é possível

representar-se uma imagem preto-e-branco de alta resolução. Em geral, as imagens coloridas são

compostas por pixels de 24 bits, onde 8 bits representam a componente de luminância (Y) e cada

8 bits restantes representam uma componente de crominância (Cb, Cr).

3.2 Codificador/Decodificador de Vídeo

Imaginando-se um sistema de televisão digital de alta definição com 25 quadros por

segundos, cada quadro na resolução de 1920x1080 pixels e cada pixel com 24 bits, seria

necessária uma banda de 1,24 Gbps para permitir a transmissão de tal sistema. De uma maneira

pragmática, percebe-se que a transmissão de vídeo sem codificação é algo inviável. De fato, a

codificação de vídeo é, na verdade, um algoritmo de compressão, e a decodificação, um

algoritmo de descompressão.

As compressões de imagens de vídeo podem ser classificadas em dois tipos: sem perdas

(lossless compression) e com perdas (lossy compression). Compressão sem perdas é aquela na

qual o decodificador reconstitui completamente o sinal, de forma que as amostras de entrada e

saída do sistema de codificação são idênticas. Compressão com perdas é aquela na qual não se

necessita de dados idênticos na entrada e saída do sistema e, neste caso, define-se a quantidade de

dados que pode ser perdida. A maioria dos processamentos de compressão de áudio e vídeo é

com perdas e, devido a essas perdas, eles são chamados de processos irreversíveis.

Em sinais de áudio e vídeo, existem redundâncias consideráveis em alguns fatores que

diminuem a quantidade de informação que necessita ser efetivamente transmitida [13]. A

redundância espacial (correlação entre os pixels de um mesmo quadro) e a redundância temporal

(correlação entre quadros vizinhos) estão entre os principais fatores que possibilitam a

compressão de vídeo [13].


Para o sistema proposto, o perfeito funcionamento dar-se-á com qualquer tipo de

codificação de vídeo, desde que esta opere dentro da taxa de transmissão do sistema, como será

visto posteriormente. Os principais codificadores de vídeo atualmente são o MPEG-2 e o H.264

(MPEG-4 V10).

O primeiro padrão MPEG foi publicado no ano de 1993, apresentando um modelo que

compreendia aspectos de sistema, codificação de áudio e codificação de vídeo. Desta forma, o

MPEG-1 (norma ISO/IEC 11172) foi desenvolvido para suportar operações com taxas de até 1,5

Mbps. Posteriormente, em 1994, foi publicado o padrão MPEG-2 (ISSO/IEC 13818 ou ITU

H.262), concebido inicialmente para suportar aplicações de 5 a 10Mbps e depois expandido para

aplicações de alta definição com taxas de transmissão de até 30Mbps. Em seguida, no ano de

1999, foi publicado o padrão MPEG-4 (ISSO/IEC 14496) visando abranger as áreas de televisão

digital, aplicações gráficas iterativas e multimídia iterativa para internet. Em 2003, foi publicado

o MPEG-4 parte 10 (ISO/IEC 14496-10 ou ITU H.264) ou, como é conhecido, o H.264 (devido à

nominação do ITU para codificação de vídeo) ou ainda codificação avançada de vídeo (AVC). O

MPEG-4 surgiu objetivando um padrão capaz de prover boa qualidade de vídeo para taxas de

transmissão mais baixas do que os padrões até então existentes.

O mais interessante dos padrões MPEG é que eles definem apenas a sintaxe, a semântica

das seqüências de bits e a metodologia de decodificação. Eles não determinam como é a

codificação, possibilitando assim liberdade para propostas de codificação que podem ser voltadas

a aplicações específicas. A seguir, serão apresentadas algumas das principais técnicas utilizadas

nos padrões MPEG.

Uma das técnicas de compressão utilizada no padrão MPEG é a subamostragem de cor.

Essa técnica é baseada na característica humana de percepção de cores, de tal forma que a

percepção da diferenciação de intensidade luminosa pelo sistema olho-cérebro é maior do que

para diferenciação de cores. Por esta razão, freqüentemente os quadros de crominância

apresentam metade ou um quarto da quantidade de pixels dos quadros de luminância e raramente

uma quantidade equivalente.


Os padrões MPEG se utilizam também da transformada discreta do co-seno (DCT) para

extrair redundância espacial por meio da concentração da energia do sinal em um número

relativamente pequeno de coeficientes. A transformada co-seno discreta é aplicada a cada um dos

blocos subconjuntos da matriz de luminância ou de uma das matrizes de crominância e o tamanho

deste bloco é de 8x8 pixels no MPEG-1 e no MPEG-2. A transformada DCT é um processo

reversível o qual realiza o mapeamento da representação bidimensional da imagem para a sua

representação no domínio da freqüência, onde o primeiro elemento, denotado (0,0), indica o valor

médio ou nível DC da luminância ou de uma das crominâncias, dependendo da matriz que se está

utilizando. É significativo enfatizar que a DCT não reduz de forma direta o número de

coeficientes. O resultado da DCT sobre um bloco de n elementos será um bloco de n coeficientes.

A redução de informação, através da remoção de redundância, provém da característica da DCT

de, para blocos de imagens naturais, concentrar a energia nos coeficientes de baixa freqüência

próximos ao elemento do valor médio. Assim, as demais componentes têm valor próximo a zero

e podem ser descartadas. Após a aplicação da transformada DCT e da respectiva quantização dos

coeficientes, utilizam-se métodos de varredura em Zig-Zag, codificação run-length e codificação

de comprimento variável (VLC) para então se eliminar a redundância espacial. Por não se

referirem ao escopo deste trabalho, estes tópicos não serão abordados. Entretanto, para os

mesmos, sugere-se como referência [14] e [15].

Outra técnica utilizada pelos padrões MPEG para compressão é a predição interquadros

com compensação de movimento, que visa remover a redundância temporal. Segundo [16] a

forma mais eficiente de se remover redundância temporal é através de predição interquadro com

compensação de movimento. Essa técnica é baseada na característica de que inúmeras vezes em

um vídeo, um quadro muda relativamente pouco em comparação ao seu predecessor ou ao seu

sucessor. Esse gênero de predição visa compensar movimentos de translação que tenham

ocorrido entre um dado bloco codificado e o seu respectivo bloco no quadro de referência. A

forma mais difundida de como encontrar o movimento ocorrido entre o bloco codificado e o

quadro de referência é denominada block-matching. Os padrões MPEG permitem que a predição

por compensação de movimento seja obtida por vários métodos. Por exemplo, a predição pode

ser feita por predição para frente (a partir de uma imagem futura), para trás (a partir de uma

imagem passada) ou interpolada através da média de ambas. Não obstante, é possível fazer uma


predição nula (Intra). Desta forma, os padrões MPEG adotam os seguintes tipos de quadros para

tornar possíveis essas predições:

Quadro tipo I (Intracodificado) - quando o quadro é codificado sem referência a outros quadros,

com predição nula. Proporciona pontos de referência, pontos de acesso onde pode começar a

decodificação e por isso eles são fundamentais ao sistema. Apresenta compressões pequenas,

similares à compressão JPEG.

Quadro tipo P (Preditivo) - quando o quadro é codificado em relação ao quadro anterior a partir

de outro quadro tipo P ou tipo I. Em geral, apresenta um terço do tamanho de um quadro tipo I.

Quadro tipo B (Bidirecional) - quando o quadro é codificado a partir da interpolação entre um

quadro anterior do tipo I ou P e um quadro posterior do tipo I ou P. Os quadros tipo B possuem

alto grau de compressão, da ordem de duas a cinco vezes maior que de um quadro P.

Quadro tipo D (Codificação DC) - quando o quadro é codificado a partir da média de blocos para

possibilitar recurso de avanço rápido. Não são todas as versões do padrão MPEG que apresentam

este tipo de quadro.

3.3 Empacotador UDP/IP

O bloco denominado Empacotador UDP/IP do esquema de televisão digital representado

pela Figura 21 corresponde à camada de transporte e à parte da camada Inter-Redes do modelo de

referência TCP/IP de uma rede de transmissão de dados. Os dados ingressantes no bloco são

dados de vídeo codificado que são empacotados para o protocolo de rede IP (Internet Protocol) e

para o protocolo de transporte UDP (User Datagram Protocol). Para fazer esse empacotamento

de vídeo codificado para pacotes UDP/IP é utilizado o software VLC, o qual é um executor de

mídia e servidor de streaming gratuito [17].


O protocolo IP é o protocolo da camada de rede que mantém a internet interligada e foi

projetado com o objetivo de fornecer a melhor forma possível de transportar datagramas da

origem para o destino, independentemente dessas máquinas estarem na mesma rede ou haver

outras redes entre elas [18]. Por datagramas entendem-se as unidades de mensagem com as quais

protocolos (como o IP) lidam e são transportados pela rede de computadores, ou ainda as

entidades de dados completas e independentes que contêm informações suficientes para serem

roteadas da origem ao destino sem precisar confiar em permutas anteriores entre essa fonte, o

destino e a rede de transporte [19]. Para a transmissão de dados, a camada de transporte recebe os

fluxos de dados e os divide em datagramas e cada um destes é transmitido, talvez fragmentado.

Quando todos esses fragmentos chegam ao destino, eles são remontados pela camada de rede e

entregues à camada de transporte. Um datagrama IP é constituído de um cabeçalho e de uma

parte de texto. O cabeçalho IP apresenta uma parte fixa de vinte bytes e uma parte opcional de

tamanho variável. Informações como versão do protocolo, tempo de vida do datagrama, endereço

de origem e de destino, tipo de serviço, tamanho total do datagrama, identificação de ordem do

datagrama e informações de fragmentação são expressas no cabeçalho do protocolo. Os

endereços IPs são constituídos de trinta e dois bits que informam a rede, a sub-rede e a máquina

específica proprietária daquele dado endereço. Basicamente, um endereço IP é dividido entre os

bits que informam a rede a qual pertence aquele endereço e o host que o abriga. Dependendo de

como é feita a alocação destes bits entre o endereço de rede e o de host, o endereço IP recebe uma

dada classe A, B, C ou D (esta última usada para transmissões de broadcasting). As

considerações citadas sobre o protocolo IP referem-se à sua versão mais difundida, o IPV4,

embora haja uma tendência, ainda não muito clara, da futura utilização da versão mais recente do

protocolo, o IPV6. Para informações complementares sobre o protocolo IP, como informações de

cabeçalho, versões e opções, sugere-se consultar [18].

Em um sistema de transmissão de dados, o usuário não tem controle sobre a camada de

rede, mas sim sobre a camada de transporte, pois é a camada de transporte que define como os

datagramas irão trafegar pela rede. O protocolo UDP é um protocolo de transporte sem conexões

que faz esta definição. Um transporte orientado a conexões consiste em ocultar as imperfeições

do serviço da rede, de modo que os processos do usuário possam simplesmente supor a existência

de um fluxo de bits livre de erros. Por outro lado, a camada de transporte também pode oferecer


um serviço não-confiável de datagramas, este determinado serviço sem conexão [18]. Assim, o

UDP oferece uma forma simples para as aplicações enviarem datagramas IP encapsulados sem

que seja necessário estabelecer uma conexão. Ele transmite segmentos que formam um cabeçalho

de oito bytes seguido pela carga útil. O cabeçalho do protocolo UDP apresenta apenas quatro

campos: porta de origem, porta de destino, tamanho de datagrama UDP e um campo de

verificação. É importante destacar que, em contrapartida à simplicidade do UDP, ele não realiza

importantes tarefas como controle de fluxo, controle de erros, retransmissão. O que o UDP faz é

prover uma interface simples ao protocolo IP com o recurso adicional de multiplexação de vários

processos que utilizam as portas. Para maiores conhecimentos sobre o protocolo UDP, sugere-se

consultar [20] e [18].

3.4 Conversor Camada MAC

Após o encapsulamento do vídeo codificado para pacotes UDP/IP, percebe-se que a

informação ainda está dentro de um microcomputador. A forma mais convencional de saída dos

dados de um microcomputador é através de sua placa de rede, utilizando a interface Ethernet

(padrão IEEE 802.3) com conector do tipo RJ-45. Inclusive, por razões convenientes ao sistema

de televisão proposto, é extremamente vantajoso que a saída de dados seja desta forma, devido à

compatibilidade com as interfaces do hardware utilizado.

6 Bytes 6 Bytes 2 Bytes 1344 Bytes

EndereçoMAC Destino

EndereçoMAC Origem

InformaçãoTi-po

Figura 22 – Quadro MAC.

Embora os pacotes UDP/IP já contenham os endereços IP de origem e destino, os pacotes

ainda não podem ser enviados, pois o hardware (neste caso a interface Ethernet) não compreende

endereços IP. O tipo de endereço utilizado pelas interfaces Ethernet é o endereço MAC (Controle

de Acesso de Mídia). Os endereços MAC são identificadores únicos de quarenta e oito bits (6


bytes), padronizados e distribuídos pelo IEEE. Assim, deve existir algum mecanismo responsável

por fazer com que o endereço IP (compreendido pelos protocolos de rede) seja mapeado para um

endereço MAC (compreendido pela interface Ethernet) e vice-versa. Esta é justamente a função

do protocolo de resolução de endereço (ARP). Desta forma, a comunicação entre

microcomputador e hardware de implementação do sistema será feita através do protocolo MAC.

A Figura 22 apresenta o formato do quadro MAC.

3.5 Aleatorizador/Desaleatorizador

Antes da seqüência de bits ser entregue à codificação de canal propriamente dita, ela

necessita ser aleatorizada. Para um sistema de transmissão OFDM, o qual será abordado

posteriormente, deve-se utilizar um aleatorizador a fim de evitar a repetição de longas seqüências

de bits. Sem a aleatorização dos dados, pode-se gerar, após a transformada inversa de Fourier

implementada no modulador, uma forte concentração de energia em uma única amostra no

tempo, o que seria extremamente danoso em termos de Relação entre Potência Média e de Pico

(PAPR -Peak-to-Average Power Ratio). Além disso, o aleatorizador possibilita a melhor

utilização do espectro e facilita a sincronização do receptor.

3.6 Codificador/Decodificador Reed-Solomon

Reed-Solomon é um código corretor de erros baseado na superamostragem de um

polinômio construído a partir dos dados. Representando o polinômio com bem mais pontos do

que o necessário, é possível corrigir erros de um bloco de dados pela recuperação dos

coeficientes do polinômio que desenharam a curva polinomial original. Para dar uma idéia da

capacidade de correção, no codificador proposto pelo MI-SBTVD, é possível corrigir até 8 bytes

de um bloco de 188 bytes, codificados em uma palavra de 204 bytes (188 bytes originais mais 16

bits de paridade). O codificador/decodificador Reed-Solomon constituem a primeira parte da

codificação de canal do sistema proposto e, portanto, serão apresentados no capítulo seguinte, o

qual aborda exclusivamente codificação de canal.


3.7 Codificador/Decodificador LDPC

A codificação LDPC (Low Density Parity Check) é um código corretor de erros baseado

em matrizes de baixa densidade. É uma técnica de inserção de redundância utilizada na

codificação de canal do sistema apresentado. Assim como o Reed-Solomon, o codificador e

decodificador serão apresentados mais detalhadamente no capítulo seguinte.

3.8 Mapeador/Demapeador e LLR

A saída do codificador de canal será uma seqüência de bits, que é uma forma de

informação discreta no domínio do tempo. Então, antes desta informação ser entregue ao

modulador propriamente dito para ser transformada em um sinal contínuo no domínio do tempo,

ela necessita ser mapeada para uma representação vetorial, a qual determinará o tipo de

modulação empregado. Esta é a função do mapeador e o processo inverso é a função do

demapeador. Os tipos mais comumente utilizados de modulação digital são PSK (baseada em

fase) e QAM (Modulação em amplitude de duas portadoras defasadas de 90°). Assim, os bits

oriundos da saída da codificação de canal serão agrupados em um número nmap de bits sendo

mapeados em Mmap símbolos de um alfabeto (ou constelação) Amap. Independentemente se a

modulação utilizada for baseada em fase ou amplitude, o alfabeto Amap deve possuir média zero

visando evitar um nível contínuo (nível DC) residual o que implica perda de potência útil à

transmissão de informação [16]. Novamente, observa-se aqui a importância do aleatorizador

explicado na Seção 3.5.

Quando a modulação PSK é utilizada, todo o conjunto de símbolos Amap pode ser

representado sobre um círculo, uma vez que todos os símbolos possuem a mesma amplitude (o

mesmo nível DC), diferenciando-se apenas em fase. Por exemplo, na modulação quaternária PSK

(QPSK) o conjunto Amap possui quatro elementos e os bits da saída do codificador de canal são

agrupados de dois em dois (nmap =2). Esse exemplo pode ser visualizado através da Figura 23.


11

01

Q

I

10

00

Figura 23 – Mapeamento feito para a modulação QPSK.

Quando a modulação QAM é empregada, os símbolos possuem dois valores de amplitude,

um para cada uma das portadoras que estão em quadratura, ou seja, cada um dos Mmap símbolos

do alfabeto é um número complexo e, devido à simetria dos quadrantes da constelação, existirão

4mapM

diferentes níveis de amplitude. A Figura 24 apresenta um exemplo de mapeamento

16QAM.

Na recepção, dificilmente um símbolo coincide exatamente com o ponto para o qual ele

foi mapeado no transmissor, mas sim para uma região em torno dele. Esse desvio, ou erro dado

pela dispersão do canal, pode fazer com que um símbolo possa ser interpretado erroneamente na

recepção. A interferência dada entre símbolos, denominada interferência intersimbólica, é a

grandeza que mede quanto os símbolos de um sistema de comunicação digital se superpõem a

outros símbolos, como conseqüência da dispersão do canal. Quanto maior for o número de

símbolos de uma constelação, maior será também a probabilidade de erros para uma mesma

relação sinal ruído.

O teste da máxima LLR (relação de verossimilhança) é uma técnica largamente

empregada para a detecção de sinais na presença de ruído [22]. Em um sistema de modulação

digital, a detecção ótima dos símbolos é aquela que conduz à menor probabilidade de erro de


símbolo. Contudo, devido a características intrínsecas dos sistemas de comunicações digitais,

principalmente características provenientes do emprego de códigos corretores de erro binário em

conjunto com o esquema de modulação, é necessário fornecer ao decodificador uma métrica de

confiabilidade de cada bit associado ao símbolo. Essa métrica, por sua vez, depende do tipo de

mapeamento utilizado para associar os padrões de bit aos símbolos da constelação, sendo comum

o emprego do código Gray, pois o mesmo garante a ocorrência de apenas um erro de bit quando o

erro ocorre entre símbolos que possuem entre si a distância mínima [23], conforme também pode

ser observado na Figura 23.

Q

I1111

1110

1101

1100 1000

1001

1011

101001100010

01110011

01010001

01000000

Figura 24 – Mapeamento feito para a modulação 16-QAM.

Assim, a função do demapeador e da LLR é dar confiabilidade à amostra recebida

selecionando o símbolo do alfabeto Amap que corresponde à amostra. Para um estudo mais

peculiar de LLR, sugere-se consultar [22].

3.9 Modulador/Demodulador e Alamouti

O estágio da modulação no transmissor é a última parte do sistema que opera com dados

digitais. Nesta etapa, são aplicadas as últimas técnicas de transmissão antes que informações

digitais sejam entregues ao conversor digital analógico (DA). De forma equivalente, o


demodulador é a entrada dos dados digitais no sistema de recepção. O modulador e demodulador

são os blocos onde são aplicadas as técnicas de transmissão baseada em múltiplas portadoras,

através da multiplexação por divisão ortogonal de freqüência (OFDM).

Modulação é o processo pelo qual um sinal denominado portadora tem alguma

característica variada de acordo com o valor instantâneo do sinal modulante que é o sinal o qual

contém a informação que se deseja transmitir [16]. Em sistemas de radiodifusão, este conceito de

modulação é essencialmente utilizado, buscando-se a forma de modulação pela qual os dados

serão transmitidos: se por variação em fase, variação em amplitude, variação em freqüência, com

portadora única, múltiplas portadoras etc.

Na etapa do modulador é acrescida a etapa de conversor elevador digital. Até esta etapa, o

sinal encontra-se em banda básica e é, então, convertido para uma freqüência intermediária. Após

a etapa de modulação, o sinal já apresenta portadora, não contendo mais componentes complexas,

mas sim um sinal real. Uma vantagem de se utilizar essa técnica no domínio digital está na

utilização de apenas um conversor digital analógico (ao invés de dois como seria para o sinal

complexo) e a entrada do conversor elevador seguinte (responsável por passar o sinal de

freqüência intermediária para banda passante) é simplificada. Conseqüentemente, no bloco do

demodulador, encontra-se a etapa de conversor rebaixador digital onde o sinal é passado, então,

da freqüência intermediária para a banda básica novamente.

O OFDM é um esquema de transmissão cujo fundamento é a multiplexação por divisão

em freqüência, onde diferentes freqüências transportam diferentes sinais. O OFDM utiliza um

grande número de portadoras de banda estreita espaçadas em freqüência de forma regular,

formando um bloco de espectro. Então, o espaçamento de freqüência e o tempo de sincronismo

das portadoras são escolhidos tal que as portadoras sejam ortogonais. Um sinal de portadora

OFDM é, na verdade, o somatório de um número de subportadoras, com dados em banda-base

em cada sub-portadora sendo modulado independentemente [24].

Muitos benefícios são alcançados através do uso das técnicas do OFDM, principalmente

relacionados à alta eficiência do espectro de freqüência e à resistência causada pela interferência


de multipercurso. Também, a robustez a multipercurso pode ser convenientemente variada no

OFDM, simplesmente alocando mais ou menos portadoras para um dado propósito. A taxa de

transmissão é definida no tempo pelo período de amostragem da IFFT, considerando-se também

a inserção do prefixo cíclico. Isto significa que a taxa de transmissão é a mesma,

independentemente do número de subportadoras utilizadas. Conseqüentemente, um benefício

extremamente interessante, obtido pelo uso de múltiplas subportadoras, está no fato de, ao se

aumentar o número de subportadoras, cada uma passa a operar a uma taxa de transmissão

relativamente mais baixa, aumentando-se a duração do símbolo OFDM, de tal forma a manter a

taxa total de transmissão inalterada. Por exemplo, para uma dada transmissão muito elevada, de

milhões de bps, efetuada sobre um único canal, a duração de cada bit será muito curta e isso

implicará significativas limitações de sincronismo e dificuldades no cancelamento da

interferência de multipercurso. No entanto, se essa mesma taxa elevada de milhões de bps for

distribuída por várias subportadoras, a duração de cada bit será maior, diminuindo assim a

sensibilidade ao multipercurso e a dificuldade de lidar-se com sincronismo [25].

A modulação OFDM é geralmente implementada através da transformada rápida de

Fourier Inversa (IFFT). Após o mapeador (vide Figura 21), o fluxo principal é convertido de

serial para paralelo. Podem ser gerados, no sistema MI-SBTVD, 2048, 4096 ou 8192 fluxos de

mais baixa taxa, que correspondem ao número de subportadoras disponíveis. Na taxa resultante, a

cada instante de símbolo OFDM, aplica-se a IFFT aos fluxos em paralelo. Este processo gera um

novo fluxo, agora no domínio do tempo, com a mesma taxa do fluxo principal. O sinal resultante

no tempo contém todas as subportadoras multiplexadas em freqüência. A ortogonalidade das

subportadoras é gerada pela própria IFFT. Finalmente, após a IFFT, é inserido um prefixo em

cada símbolo OFDM (bloco de amostras da IFFT) correspondente a uma fração do símbolo

OFDM. Por exemplo, para 2048 portadoras, haverá 2048 amostras da IFFT no tempo. Se for

utilizado um prefixo de 1/16, então serão inseridas 128 amostras no início do símbolo OFDM.

Como as amostras inseridas correspondem às amostras finais de um símbolo OFDM, então as

mesmas são denominadas de extensão cíclica ou prefixo cíclico. Inversamente, no receptor, o

prefixo cíclico deverá ser removido, e os dados deverão ser convertidos para o domínio da

freqüência através da FFT. Desta forma, os fluxos das subportadoras são recuperados e passados

por um conversor de paralelo para serial para recuperar o fluxo original.


É importante destacar que o OFDM apresenta algumas desvantagens, como, por exemplo,

ser susceptível a desvio Doppler e problemas de sincronização de freqüência. O desvio Doppler

ocorre principalmente nas aplicações veiculares, onde o receptor pode se deslocar em alta

velocidade. Se, por um lado, a ortogonalidade das subportadoras torna a utilização do espectro

mais eficiente, eliminando a necessidade de subportadoras de guarda, por outro lado, uma

imperfeita sincronização de freqüência ou um desvio Doppler pode causar perda da

ortogonalidade das subportadoras, gerando interferência cruzada entre as subportadoras (cross-

talk), o que diminui significativamente o desempenho do sistema. Além disso, como o sinal

OFDM é um somatório de um grande número de subportadoras, ele tende a apresentar uma alta

relação entre potência de pico e potência média, o que dificulta o uso eficiente dos amplificadores

de potência [24].

O sistema de TV Digital proposto, também faz uso de um esquema de diversidade

espacial com duas antenas transmissoras e uma antena receptora. A diversidade de transmissão

foi implementada utilizando a técnica de Alamouti [26], adaptada para o OFDM, utilizando

codificação espaço-temporal em pares de símbolos OFDM.

Por fim, o desempenho do sistema poderá ser aperfeiçoado com a utilização de técnicas

robustas de sincronismo, técnicas de estimação de canal e outras técnicas de diversidade de

transmissão/recepção. Contudo, as abordagens destes tópicos evadiriam a finalidade deste

trabalho. Desta maneira, para estudos mais completo sobre técnicas de OFDM, sugere-se [24] e

[25].

3.10 Conversores A/D e D/A

Após todas as técnicas que realmente caracterizam o sistema serem aplicadas através de

dispositivos digitais, o sinal de saída do modulador é entregue ao conversor digital analógico

(DA), responsável por transformar uma seqüência de valores discretos em um sinal analógico

contínuo no tempo, representado, por exemplo, através de variações de tensão ao longo do tempo.

De forma análoga, no receptor do sistema, os sinais recebidos de forma analógica, através de


variações no nível de tensão, serão digitalizados pelo conversor analógico digital (AD) para

serem entregues ao demodulador na forma de uma seqüência discreta de valores quantizados.

A resolução de um conversor A/D ou D/A (resbits), expressa em bits, indica o número de

valores discretos que podem ser produzidos na gama de valores de tensão. O número de valores

que podem ser reproduzidos (Nquant) é a base 2 elevada à potência da resolução do conversor, ou

seja,

2 .bitsresquantN=

Como pode ser deduzido, quanto maior a resolução dos conversores A/D e D/A melhor

será a qualidade do sinal digitalizado e mais bits serão necessários para representar os sinais de

forma discreta.

3.11 Conversor Elevador e Rebaixador

O conversor elevador e o rebaixador são o que tornam possível que uma dada informação

seja transmitida por radiodifusão através do sistema indicado na Figura 21, pois há a necessidade

dos sinais serem transmitidos em freqüências elevadas e devidamente canalizados. Assim, no

transmissor, o conversor elevador eleva a freqüência do sinal para ser transmitido pela atmosfera

em uma freqüência exclusiva, ou seja, da freqüência intermediária para uma freqüência mais

elevada correspondente ao seu canal. Posteriormente, no receptor, o conversor rebaixador reduz a

freqüência do sinal de banda passante para freqüência intermediária novamente.

Segundo [27], a translação em freqüência que resulta do processo de modulação, a qual

eleva o espectro do sinal para freqüências mais elevadas, permite que a informação contida no

sinal seja transmitida para o meio físico do canal através de irradiadores de dimensão física

praticável. Isto ocorre porque a freqüência para qual o sinal é transladado possui um valor muito

mais elevado que sua freqüência intermediária e, assim, a nova freqüência necessita de um

irradiador muito menor.

(3.1)


3.12 Amplificador de Potência

No transmissor, o amplificador de potência tem como função elevar o nível de potência

do sinal de portadora de tal forma que o sinal recebido no receptor tenha um nível razoavelmente

alto para superar a degradação proveniente das interferências e ruídos intrínsecos ao canal de

transmissão.

3.13 Amplificador de Baixo Ruído e Controle Automático de Ganho

O bloco denominado ‘LNA e AGC’, ilustrado no primeiro bloco do receptor da Figura 21,

é constituído por duas partes. A primeira delas é o Amplificador de Baixo Ruído ou LNA (Low

Noise Amplifier). O LNA é um amplificador de alto ganho que amplifica o sinal de entrada para

um nível apropriado para alimentar o receptor. O LNA é desenvolvido de forma a minimizar o

ruído que é inevitavelmente adicionado ao sinal no processo de amplificação.

Já a segunda parte do bloco é o Controle Automático de Ganho ou AGC (Automatic Gain

Control). O AGC tem como objetivo controlar o ganho de um sistema, de tal forma a manter seu

desempenho apropriado, para diferentes níveis do sinal de entrada. Como a intensidade do sinal

recebido pode variar bastante de acordo com a localização do receptor e com outras

características do canal, é necessário que o AGC ajuste o ganho do receptor a fim de se obter um

sinal constante na saída, baseando-se na medição da intensidade do sinal. Quando o sinal

apresenta uma intensidade elevada o AGC tende a reduzir o ganho do sistema. Por outro lado,

quando o sinal for de baixa intensidade o AGC atuará de forma a aumentar o ganho do sistema.

81

81

Capítulo 4 Codificação LDPC 4.1 Introdução à Codificação de Canal

Nos últimos vinte anos, tem havido um crescimento significativo na busca por soluções

eficientes e confiáveis na transmissão e no armazenamento de dados digitais. Obviamente este

processo é impulsionado pelas atuais redes de dados de alta velocidade e pelas elevadas

capacidades de transmissão, armazenamento e principalmente de processamento. Contudo, o

grande obstáculo em um sistema de transmissão está relacionado ao controle de erros, o qual, se

não obtiver um resultado satisfatório, pode inviabilizar a aplicação de um dado sistema de

transmissão digital [28]. Especialmente, essa dificuldade está associada a ruídos e interferências

existentes em qualquer canal real de transmissão.

Transdutor de entrada

Canal deTransmissão

Codificadorde Fonte

ModuladorDigital

AmplificadorDe potência

Amplificadorde Sinal

DemoduladorDigital

Decodificadorde Fonte

Transdutor de saída

Transmissor Digital

Receptor Digital

Seqüência deInformação

Codificadorde Canal

Decodificadorde Canal

Seqüência Codificada

Transdutor de entradaTransdutor de entrada

Canal deTransmissão

Codificadorde Fonte

Codificadorde Fonte

ModuladorDigital

ModuladorDigital

AmplificadorDe potênciaAmplificadorDe potência



DemoduladorDigital

DemoduladorDigital





Transmissor Digital

Receptor Digital

Seqüência deInformação

Codificadorde Canal

Codificadorde Canal



Seqüência Codificada

Figura 25 – Diagrama de blocos de um sistema de comunicação digital.

Capítulo 4 – Codificação LDPC 82

Desta forma, no contexto de um sistema de comunicação digital conforme mostrado na

Figura 25, o codificador de canal, através de técnicas baseadas principalmente na inserção de

redundância, desempenha a função de manter a taxa de erro de um sistema de comunicação

dentro de um limite dado como aceitável. De fato, em um sistema de codificação de canal três

condições devem ser aspiradas, conforme [28], são elas:

• que a informação seja transmitida em um ambiente ruidoso de forma tão rápida quanto

possível;

• que a informação possa ser reproduzida de uma maneira confiável na saída do

decodificador de canal;

• que o custo de implementação da codificação e decodificação seja reduzido a limites

aceitáveis.

Estruturalmente, os códigos corretores de erro podem ser classificados como códigos

convolucionais ou códigos de blocos. Os códigos de bloco dividem a seqüência da informação a

ser codificada em blocos de k bits tal que a palavra-código resultante dependa apenas desta

seqüência. Os códigos convolucionais também separam a mensagem a ser codificada em blocos

de k bits, porém cada conjunto de informação codificada não depende apenas de sua mensagem,

mas também de conjuntos de mensagens anteriores. No presente trabalho, apenas códigos de

bloco serão usados.

Imagine inicialmente um conjunto X de mensagens a serem codificadas e um conjunto C

de palavras-código resultantes. Imagine também um alfabeto A. Um código de bloco é aquele

onde cada um dos símbolos do alfabeto fonte (conjunto X) tem associada a ele uma seqüência

fixa de símbolos do alfabeto-código A. Assim, um operador θ faz o mapeamento de cada símbolo

do conjunto X para um símbolo correspondente do conjunto A, de tal forma que }{xC θ= .

Para códigos binários, pode-se dizer que o tamanho do conjunto X será dado por K

MM 2= , onde k é o tamanho de cada mensagem de X, em bits. O resultado da codificação será


novamente o conjunto C que possuirá MM palavras-código binárias, cada uma delas com n bits.

Como o codificador de canal insere redundância à informação a ser codificada, n > k, assim, para

a especificação de um código de bloco binário, usa-se a notação ),( knθ .

1 1 1 1

Mensagem

Palavra-Código

Paridades

Observa-se que o bit “1”representa o número ímpar de ‘1’s contido namensagem [0 1 0]

0 0 00 0 10 1 00 1 11 0 01 0 11 1 0

0 0 0 00 0 1 10 1 0 10 1 1 01 0 0 11 0 1 01 1 0 0

MENSAGEM PALAVRA-CÓDIGO

Mensagem

1 1 1 1 1 1 1

Mensagem

Palavra-Código

Paridades

Observa-se que o bit “1”representa o número ímpar de ‘1’s contido namensagem [0 1 0]

0 0 00 0 10 1 00 1 11 0 01 0 11 1 0

0 0 0 00 0 1 10 1 0 10 1 1 01 0 0 11 0 1 01 1 0 0

MENSAGEM PALAVRA-CÓDIGO

Mensagem

1 1 1

Figura 26 – Demonstração de um código de bloco binário sistemático θ(4,3).

Um código de bloco também pode ser sistemático ou não. Um código é dito sistemático

quando é possível, de uma forma direta e sem manipulação alguma, identificar na palavra-código

os bits da mensagem e os bits de paridade, ou seja, os bits de paridade são justapostos à

mensagem a ser codificada, formando assim palavra-código. O exemplo mais elementar de

código sistemático é o conhecido teste de paridade. Essa codificação simplesmente justapõe um

bit ‘1’ à mensagem, caso o número total de uns da mensagem a ser codificada seja ímpar ou

justapõe um bit “0”, caso esse número seja par. Assim, pode-se deduzir que em um código de

teste de paridade 1+= kn . A Figura 26 mostra um exemplo de codificação de teste de paridade

onde é possível visualizar de forma direta que o código é sistemático.

Cada código ),( knθ possui uma matriz geradora G de n linhas por k colunas. Assim,

considera-se aqui ix a mensagem binária a ser codificada, onde o índice i indica a coluna da

matriz X, matriz esta que representa todas as mensagens a serem codificadas e seja C uma matriz

com todas as palavras-código geradas a partir das mensagens contidas em X. Cada coluna ic da


matriz C representa a palavra-código associada a ix . Desta forma, a matriz geradora G deve ser

multiplicada por cada vetor coluna ix , para obter-se a palavra-código ic , na forma

ou, na forma matricial,

1 111 1

2 2

1

.

i ik

i i

n nkni ki

c xG G

c x

Gc x

=

O conjunto C (que possui 2k palavras-código) é um subespaço de dimensão k.

Considerando-se cada coluna da matriz G como um vetor (pode-se referir como cada vetor

coluna da matriz G), é imprescindível que os k vetores coluna que constituem a matriz G sejam

linearmente independentes para gerar o subespaço C em k dimensões [28].

A partir de permutações em suas linhas e operações elementares em suas colunas,

qualquer matriz geradora G pode ser convertida a uma matriz geradora sistemática, a qual gerará

um código sistemático. A forma de uma matriz geradora sistemática G é tal que se pode, através

de uma análise intuitiva, observar que ela possui uma matriz identidade concatenada com a

própria matriz paridade, ou seja,

xx

( )x

k kn k

n k k

IG

P −

=

onde I é matriz identidade kxk e P a matriz das paridades (n-k)xk. Propõe-se daqui por diante

considerar-se sempre a matriz G como uma matriz sistemática.

,i ic Gx= (4.1)

(4.2)

(4.3)


Cada coluna ic da matriz C pode ser descrita como

ii

i

xc

p

=

onde,

.i ip Px=

Logo, como a operação é módulo dois,

0,i iPx p+ =

o que é o mesmo que

[ ] 0.in k

i

xP I

p−

=

Por definição, a matriz de paridade é representada por H e dada por

[ ],n kH P I −=

o que faz com que

0.iHc =

Conforme demonstrado, a matriz de paridade H pode ser usada tanto para obter-se uma

palavra-código a partir de uma mensagem a ser codificada (codificação) como pode ser utilizada

para obter-se a mensagem original a partir de uma palavra-código (decodificação). Também,

através da utilização da matriz de paridade H na decodificação, é possível detectar a ocorrência

de erro na transmissão de dados através da regra destacada na Equação 4.9. Sempre que a

multiplicação da matriz de paridade H pela palavra-código recebida for diferente de zero, existem

erros.

(4.4)

(4.5)

(4.6)

(4.7)

(4.8)

(4.9)


4.2 Reed-Solomon

O processo de codificação/decodificação de um código de bloco alicerça-se na teoria

algébrica de que um conjunto de palavras-código pode ser mapeado em um conjunto de

polinômios. Deste modo, os componentes do vetor de uma dada palavra-código iC

correspondem aos coeficientes do polinômio ( )iC x . De forma análoga, o conjunto de mensagens

a serem transmitidas pode também ser mapeado para um conjunto de polinômios. Por essa razão,

os códigos de bloco são também chamados de códigos polinomiais [16]. Como exemplo, a

Figura 27 exibe a representação polinomial de uma série de palavras-código onde cada uma

representa a i-ésima palavra-código associada a i-ésima mensagem a ser codificada.

0 0 00 0 10 1 00 1 11 0 01 0 11 1 01 1 1

PALAVRA-CÓDIGO POLINÔMIO

01x

x+1x2

x2+1x2+x

x2+x+1

0 0 00 0 10 1 00 1 11 0 01 0 11 1 01 1 1

PALAVRA-CÓDIGO POLINÔMIO

01x

x+1x2

x2+1x2+x

x2+x+1

( )iC xiC

Figura 27 – Polinômios associados às palavras-código.

Assim, em 1960, Irving Reed (1923-), engenheiro, matemático e doutor pelo Instituto de

Tecnologia da Califórnia, e Gustave Solomon (1930-1996), engenheiro, matemático e doutor

pelo Instituto de Tecnologia de Massachussets, apresentaram o artigo chamado “Códigos

Polinomiais em Campos Finitos” [29] e nascia dessa forma um dos mais difundidos códigos

corretores de erro, o Reed-Solomon (RS).

Os códigos Reed-Solomon são códigos usados na codificação de canal, pertencendo à

classe de códigos de bloco lineares que operam com símbolos. Esses códigos pertencem a uma

subclasse de códigos cíclicos, denominada códigos BCH (Bose – Chaudhuri - Hocquenghem)


[28]. Sua gama de aplicações é bastante amplo em comunicações digitais (comunicações

celulares, links de satélite etc.), bem como em armazenamento de dados (fitas magnéticas, CDs,

DVDs etc.).

Em um código corretor de erros, os coeficientes dos polinômios contidos em )( pCi

devem ser tais que pertençam a um campo algébrico. O conceito de campo algébrico encontra-se

claramente apresentado em [30]. Quando um campo algébrico possui um número definido Q de

elementos, ele é chamado de campo finito ou corpo de Galois ( ( )GF Q ). Para que seja possível a

formação de um corpo de Galois, é necessário que todas as operações de soma e multiplicação no

( )GF Q sejam ( )MOD Q . Isso garante que qualquer operação de soma ou multiplicação dentro

do corpo de Galois apresentará um resultado pertencente a esse mesmo campo. Os códigos Reed-

Solomon são baseados na teoria de corpo de Galois e necessitam que operações de soma e

multiplicação sejam implementadas nos procedimentos de codificação e decodificação RS. Já o

polinômio do código é calculado em função do número de símbolos da palavra-código, n, e do

número de símbolos da informação, k. De fato, o polinômio gerador representa na verdade a

matriz geradora do código, pois é através dele que se obtém a palavra-código.

Como citado anteriormente, os códigos Reed-Solomon operam com símbolos. Cada

símbolo possui rsm bits. Obrigatoriamente as operações entre os polinômios são todas realizadas

dentro de (2 )rsmGF . A notação usada para representar os códigos Reed-Solomon é ( , )RS n k . A

capacidade de correção de um código RS, dada em símbolos e denominada t, é dada por

.2

n kt −=

Por exemplo, para um código (20,16)RS com 8=rsm , a capacidade e correção t é de 2

símbolos e a paridade será de 4 símbolos, conforme se pode observar na Equação 4.10. A Figura

28 mostra o exemplo descrito.

(4.10)


n

012 098100255 120 003 233 111 077 163 000 001 088 200 101 007 208 107 221 076

2tk

n

012012 098098100100255255 120120 003003 233233 111111 077077 163163 000000 001001 088088 200200 101101 007007 208208 107107 221221 076076

2tk

Figura 28 – Codificação )16,20(RS com 8=rsm .

Como a capacidade de correção do código é dada em símbolos, o código irá corrigir no

máximo t símbolos errados independentemente do número de bits incorretos dentro do símbolo.

Supondo que t símbolos apresentem erro, no melhor caso, t bits serão corrigidos (um bit em cada

símbolo) e no pior caso serão corrigidos rsm t bits (todos os m bits de cada símbolo). Esta

característica é extremamente vantajosa para a concepção de um codificador de canal de um

sistema de telecomunicações, uma vez que o código se torna capaz de corrigir uma rajada de

erros de até rsm t bits, desde que eles ocorram dentro de um mesmo bloco Reed-Solomon.

Também, no caso do código detectar a presença de mais de t símbolos errados dentro de um

bloco RS existe a possibilidade de uma flag ser setada para avisar a ocorrência desta situação.

Além da capacidade de correção t dos códigos RS, essa classe de código também é capaz

de detectar apagamentos. Apagamentos ocorrem quando a posição de um símbolo errado é

conhecida. Um decodificador Reed-Solomon pode corrigir t símbolos ou 2t apagamentos.

Apagamentos de informação podem ocorrer freqüentemente introduzidos pelo demodulador de

um sistema de comunicação digital [31].

Um recurso bastante utilizado e útil na codificação RS é o encurtamento de código. O

encurtamento implica zerar um dado número de símbolos na codificação, não transmiti-los e

então re-inserir estes símbolos zeros no estágio de decodificação. A regra para o encurtamento de

código diz que a diferença entre número de símbolos da palavra-código (n), e o número de

símbolos da informação (k) deve ser a mesma tanto no código original (gerador do polinômio)

quanto no código reduzido. Isso significa dizer que haverá a mesma quantidade de símbolos de

paridade para uma quantidade menor de informação transmitida. Conseqüentemente, haverá um

aumento na confiabilidade do sistema de transmissão pelo canal e diminuirá a probabilidade do

código não conseguir corrigir os dados corrompidos.


Uma medida bastante importante em um sistema de comunicação digital é o ganho da

codificação. Quando um sistema de comunicação digital é projetado para operar com uma dada

taxa de erro de bit existem basicamente duas maneiras de se atingir isso. Uma forma é

aumentando a relação sinal ruído através do aumento da potência do sinal transmitido. Outra

forma é através da implementação de um código corretor, que permita atingir a mesma taxa de

erro sem o aumento de potência transmitida. Essa “economia” de potência, em decibéis, é

denominada como o ganho do código [31]. Torna-se difícil exemplificar ganhos típicos de

codificadores Reed-Solomon neste trabalho, pois ele depende essencialmente do canal de

transmissão e da taxa de erro de bit almejada.

4.3 Low Density Parity Check

Códigos Low Density Parity Check (LDPC), ou códigos de matriz de paridade de baixa

densidade, são códigos de bloco binários lineares onde a principal característica é que a matriz de

paridade H é esparsa, ou seja, de baixa densidade de elementos não nulos. Uma matriz é dita

esparsa ou de baixa densidade quando a maioria dos seus elementos é nula.

Os códigos LDPC foram apresentados pela primeira vez por Robert Gallager (1931-) em

1962 [32] e posteriormente em sua tese de doutorado em 1963 [33]. Por quase 20 anos a teoria de

Gallager ficou praticamente esquecida, até que em 1981 Tanner [34] apresentou uma nova

interpretação para o LDPC, a partir de um ponto de vista gráfico, técnica esta chamada de gráfico

de Tanner ou gráfico bipartido. Novamente o LDPC foi ignorado pelos estudiosos de codificação,

desta vez por mais 14 anos. Finalmente, em meados dos anos 90, quando do advento dos códigos

turbo e do interesse por algoritmos iterativos de decodificação, o LDPC foi como que

redescoberto, passando, então, por evoluções, especialmente no que se refere à regularidade dos

códigos [35]. Gallager também propôs um algoritmo iterativo de decodificação, conhecido como

Belief Propagation ou algoritmo de soma e produto (SPA). Apesar de Gallager ter proposto o uso

do LDPC como corretor de erro, ele não propôs um método específico para a construção

algébrica e sistemática dos códigos.


O método gráfico desenvolvido por Tanner oferece, entre outras coisas, uma forma muito

mais conveniente de representar a matriz H. O número de colunas da matriz H é representado por

pequenos círculos chamados de nós de variável (ou mais especificamente de nós de bit) e o

número de linhas é representado por pequenos quadrados chamados de nós de paridade (ou mais

comumente de nós de cheque). Cada bit na palavra-código corresponde a um nó de bit e cada

equação de cheque de paridade corresponde a um nó de cheque. A ligação entre um nó de bit e

um nó de cheque é chamada de ramo e é empregado para representar que um dado ‘1’da matriz H

pertence à coluna representada pelo nó de bit de origem do ramo e também pertencente à linha

representada pelo nó de cheque de destino do ramo. O número total de ramos corresponde ao

número total de uns da matriz de paridade H. A Figura 29 apresenta um exemplo de matriz de

paridade que facilita a compreensão deste conceito, ainda que a mesma não corresponda a um

código LDPC.

0C1 C2 C3 C8C4 C6C5 C7

V1

V2

V3

V4

1 1

1H = 1

11

1

1

1

1

10

0 0 0

0

0

0

0 0 0 0

0 0 0 0

1 1 1 1

1

Figura 29 – Exemplo de matriz de paridade H.

Para a matriz de paridade da Figura 29, é apresentado o seu respectivo gráfico de Tanner

na Figura 30 seguinte, visando facilitar o entendimento de sua construção. Observa-se que o

elemento ‘1’ em negrito e itálico (e na cor vermelha para a versão colorida deste impresso) na

matriz H aparece também com linha tracejada (e na cor vermelha para a versão colorida deste

impresso) do Gráfico de Tanner da Figura 30 para facilitar a compreensão.

O grau de um dado nó de bit ou nó de cheque pode ser determinado de duas formas.

Através da matriz H, o grau de um nó corresponde ao número de uns presentes em sua respectiva


linha - no caso de nós de cheque - ou coluna - no caso de nós de bit -. Graficamente, o grau de um

nó pode ser determinado através do número de ramos que sai do nó.

c1c1V1V1

Nós de variável(nós de bit)

Nós de Paridade(nós de cheque)

V2V2

V3V3

V4V4

c2c2

c3c3

c4c4

c5c5

c6c6

c7c7

c8c8

Figura 30 - Exemplo de gráfico de Tanner.

Outro conceito bastante importante é referente à regularidade do código. Um código é

dito regular quando o número de uns é o mesmo em todas as linhas e colunas da matriz H, ou

graficamente, quando todos os nós de cheque e todos os nós de bit apresentam o mesmo grau.

Quando Gallager desenvolveu os códigos LDPC, nos anos de 60, ele apresentou apenas códigos

regulares. Segundo [36], em termos de desempenho, os códigos irregulares são melhores do que

os regulares, embora apresentem uma complexidade maior de projeto. No exemplo da Figura 30

observa-se que se trata de um código regular, pois todos os nós de bit apresentam o mesmo grau -

grau dois - assim como todos os nós de cheque - grau quatro-.


Um ciclo dentro de um código representa um caminho fechado. Na Figura 30 percebe-se

um ciclo em destaque mostrado com linhas pontilhadas (e na cor verde para a versão colorida

deste impresso). Esse ciclo pode ser tanto percebido no gráfico de Tanner ou na matriz H. O

número de saltos dentro de um ciclo é conhecido como grau do ciclo. No exemplo do ciclo da

Figura 30 mostrado com linhas pontilhadas (e na cor verde para a versão colorida deste

impresso), referenciado acima, seu respectivo grau é quatro. Este mesmo ciclo pode ser

observado na matriz de paridade da Figura 29, através dos uns sublinhados (e na cor verde para a

versão colorida deste impresso). É conveniente ressaltar que ciclos de baixo grau são também

referenciados como ciclos curtos, devido à representação dos gráficos de Tanner.

Segundo [37], ciclos curtos, especialmente de grau quatro devem ser evitados para o

projeto de códigos eficientes, pois provocam um elevado grau de erro (saturação na probabilidade

de erro de bit - error floor).

Para um código irregular, o índice i representa o grau do ramo. Desta forma, iλ expressa

a fração dos ramos conectados a nós de bit de grau i. A distribuição de graus para nós de bit é

dada por

1

2.

dvi

x ii

xλ λ −

=

=∑

De forma análoga, para os ramos conectados aos nós de cheque (número de uns das linhas

da matriz H) usa-se a variável iρ para representar a fração dos ramos ligados aos nós de cheque

de grau i, tal que

1

2,

dci

x ii

xρ ρ −

=

=∑

onde dv representa maior grau de nós de bit e dc o maior grau de nós de cheque.

(4.11)

(4.12)


Para a obtenção da matriz de paridade H, este trabalho considerará as técnicas propostas

em [37][38][39], usando códigos eIRA (extended Irregular Repeat Accumulate), que visam

principalmente à viabilidade e diminuição da complexidade de implementação do código.

Inicialmente, a matriz H deve ser dividida em duas matrizes 1H e 2H , tal que

[ ]1 2 .H H H=

A matriz 1H apresenta as dimensões ( - )xn k k e será gerada aleatoriamente de forma a

atender a distribuição necessária de graus. Já a matriz 2H , de dimensões ( - )x( - )n k n k , é dada

por

2

1 0 0 0 01 1 0 0 00 1 1 0 0

.

0 0 0 1 00 0 0 1 1

H

=

Uma vez que a estrutura de 2H é conhecida, o projeto de um código LDPC eIRA consiste

em duas tarefas:

• Otimização da distribuição dos graus de xλ e xρ ;

• Construção da matriz 1H .

A otimização de xλ e xρ é uma tarefa com um alto custo computacional e nem um pouco

trivial. Em geral, essas otimizações empregam técnicas complexas, entre as quais se destaca a

técnica de evolução de densidade apresentada em [40]. Esse tema, todavia, não será apresentado

por não compor um dos tópicos fundamentais deste trabalho. Sugere-se, em caso de interesse por

bibliografias mais amplas e uma visão global dessa questão, consultar [41].

(4.13)

(4.14)


Para a obtenção da matriz 1H , deve-se recordar que a mesma tem dimensões ( - )xn k k . O

primeiro passo para a sua construção, segundo [41], é criar uma matriz M, submatriz de 1H e m

vezes menor do que ela, de dimensões axb. O fator m determinará o maior grau de paralelização

que poderá ser implementado. A matriz M não apenas deverá ser criada respeitando a otimização

de xλ e xρ como também evitando ciclos de baixa ordem, especialmente de grau quatro,

conforme descrito previamente.

Uma vez obtida a matriz M, cada elemento nulo de M deve ser substituído por uma matriz

nula de ordem m e cada elemento ‘1’ de M deverá ser substituído por permutações da matriz

identidade de ordem m, construindo assim uma nova matriz chamada S, com as mesmas

dimensões de 1H . De posse da matriz S monta-se a matriz 1H , da seguinte forma

( )

1

1

( 1) 1

21

2

1 2

,

m

a m

m

a m

n k

ss

ssH

ss

s

+

− +

+

− +

−

=

onde is é a i-ésima linha da matriz S.

Finalmente, uma vez obtida a matriz 1H , a matriz de paridade H pode ser auferida

através da Equação 4.13.

É importante salientar que as técnicas descritas anteriormente diminuem

significativamente o aparecimento de ciclos curtos, embora estes não sejam totalmente

eliminados.

(4.15)


4.3.1 Codificação

Para obter-se a codificação de uma dada mensagem x , deve-se substituir as Equações 4.4

e 4.13 em 4.9. Desta forma, tem-se que

[ ]1 2 0.x

H Hp

=

Desta forma,

1 2 .H x H p=

Finalmente, a paridade p é dada por

1

2 1 .p H H x−=

Devido à forma apresentada na Equação 4.3, 12−H assume

12

1 0 0 0 01 1 0 0 01 1 1 0 0

.

1 1 1 1 01 1 1 1 1

H −

=

Sendo 12−H a matriz triangular inferior mostrada na Equação 4.19, sua implementação

pode ser feita com um acumulador simples. Desta forma, a estrutura do codificador pode ser

ilustrada pela Figura 31.

(4.16)

(4.17)

(4.18)

(4.19)


HT

1 D11 px’

c’ = [x’ p’]

x

HT

1HT

1 D1 D11 px’

c’ = [x’ p’]

x

Figura 31 – Diagrama simplificado do codificador LDPC.

Uma vez tendo-se implementado 12H − , o grande obstáculo da codificação passa ser a

manipulação de 1H x .

O processo direto para a codificação é então simplificado à tarefa de armazenar toda a

matriz de paridade 1H em hardware e prover a multiplicação pela mensagem a ser codificada,

produto esse que chamar-se-á iq . Posteriormente, aplicando-se uma operação de ou-exclusivo

(xor) de iq com 1−iq obtém-se a paridade ip , descrito analiticamente como

1.i i ip q q −= ⊕

Um problema bastante expressivo é que a matriz 1H , embora esparsa, é

significativamente grande. Nem sempre é possível armazená-la devido a limitações na quantidade

de memórias do dispositivo onde a implementação do código se dará. Nesses casos, uma técnica

bastante difundida é aplicada onde uma estrutura T, significativamente menor que 1H , é criada

de tal forma que T possa emular a estrutura de 1H através de simples permutações. Ao invés de

armazenar-se toda a matriz 1H , é necessário apenas registrar a estrutura T, a qual armazena os

índices dos nós de cheque conectados aos km

nós de bit indexados pelos múltiplos de m. Dessa

forma, a cada bloco de m bits da mensagem de k bits a ser codificada, a estrutura T será

permutada.

(4.20)


4.3.2 Decodificação

O principal objetivo de qualquer algoritmo de decodificação é determinar a probabilidade

máxima a posteriori (MAP) dos bits transmitidos. Para sistemas binários, o logaritmo da razão de

verossimilhança [22], ou LLR (Log-Likelihood Ratio), é dada por

Pr( 0 | )log ,Pr( 1| )

ii

i

c rLc r=

==

onde r é a seqüência de bits recebidos, de modo que o bit recebido é mais provável ser 0=ic

quando 0>iL e 1=ic para os demais casos. Através do gráfico de Tanner, é possível derivar

algoritmos iterativos que obtêm boas aproximações para LLR. Os algoritmos iterativos são

baseados na troca de mensagens entre os nós de bit e os nós de cheque. Isso pode ser

compreendido melhor através da Figura 32, onde vw e cw representam o número total de nós de

bit e nós de cheque respectivamente.

No lado esquerdo da Figura 32, nota-se que o nó de variável combina as informações

provenientes dos nós de cheque ( iu ) (para i = 2,3,... vw ) com a informação do canal. Na parte

direita da Figura 32 é exibido o processo equivalente, porém em um dos nós de cheque de grau

cw . É importante destacar que os nós de cheque não têm contato com a informação proveniente

do canal.

......Recebedo Canal

v1 u1

v2u2

vwvcwu............Recebe

do Canal

v1 u1

v2u2

vwvcwu

Figura 32 – Esquema de troca de mensagens dos nós de bit para os nós de cheque (esquerda) e

dos nós de cheque para os nós de bit (direita).

(4.21)


O Belief Propagation de Gallager é, na verdade, uma aproximação do MAP e nele para

um dado nó de bit j, a mensagem de j para um nó de cheque i é computada como

.i jj i

v u≠

=∑

Já a mensagem de um dado nó de cheque j para um nó de bit i é dado por

12 tanh tanh .2

ji

j i

vu −

≠

=

∏

A complexidade do Belief Propagation depende do número de ramos incidentes em cada

nó, onde poucos ramos significam uma baixa complexidade. Entretanto, poucos ramos significam

também que a matriz de paridade é esparsa e essa é a causa pela qual os códigos LDPC podem

ser decodificados com algoritmos de complexidade relativamente baixa como o Belief

Propagation [41]. Estudos mais específicos sobre a decodificação LDPC podem ser encontrados

em [42].

(4.22)

(4.23)

99

99

Capítulo 5 Implementação do Codificador LDPC 5.1 Codificador LDPC 5.1.1 Estrutura da Codificação

No modelo de codificação LDPC proposto na Seção 4.3, a estrutura apresentada era, até

então, dada em função de certos parâmetros. O código eIRA proposto foi apresentado justamente

por visar, principalmente, à diminuição da complexidade de implementação, ao passo que

nenhum dos parâmetros havia sido definido. O primeiro passo para a implementação do

codificador é a definição do próprio código, ou seja, determinar os parâmetros que o

caracterizam. A fixação das características do código LDPC implementado nesta dissertação está

em congruência com os parâmetros definidos no projeto denominado MI-SBTVD para

desenvolvimento de modulação inovadora para o Sistema Brasileiro de Televisão Digital

(SBTVD), cujas particularidades de implementação podem ser observadas em [41] e [21].

Baseado nas características de robustez frente ao ruído e às interferências presentes no

canal, necessárias a um sistema de televisão digital, o comprimento de código foi definido em

9792 bits. O comprimento da palavra-código cogitado inicialmente para o código LDPC era de

39168 bits. No entanto, na especificação final optou-se por reduzir o comprimento do código para

o tamanho apresentado. Os critérios utilizados nesta decisão envolvem fatores distintos, como

complexidade de implementação, latência e desempenho [21]. A análise de desempenho para

diferentes comprimentos de códigos LDPC é apresentada na Seção 6.1. A taxa de código

Capítulo 5 - Implementação do Codificador LDPC 100

escolhida para implementação do protótipo foi de 3/4, ou seja, dos 9792 bits da palavra-código,

7344 bits são de informação enquanto 2448 são bits de paridade. De posse do comprimento e taxa

do código, adotando o descrito na Seção 4.3, sabe-se que a matriz de paridade H terá dimensões

2448(n-k) x 9792(n), sendo a matriz H1 uma matriz de dimensões 2448(n-k) x 7344(k) e H2 uma

matriz de dimensões 2448(n-k) x 2448(n-k).

Dando continuidade à etapa de projeto do código, determinou-se o grau máximo de

paralelização m como sendo igual a 51. Isso significa dizer que no máximo 51 ramos podem ser

processados em paralelo. Essa determinação reproduz com fidelidade o determinado em [41], no

qual também encontram-se expostos os critérios utilizados para a otimização de iλ e de iρ . O

grau máximo de paralelização m foi determinado para a construção da matriz M respeitando a

distribuição de iλ e de iρ e também respeitando os ciclos de baixa ordem. Essa matriz foi

desenvolvida por dois dos autores (Lopes e Pegoraro) de [41] que forneceram a estrutura T,

definida na Seção 4.3.1, que representa a tabela compacta a partir da qual pode-se montar a

matriz H1, viabilizando assim o desenvolvimento do código. A estrutura T é de tamanho

equivalente à quantidade de bits ‘1’ contidos na matriz M, porém o que ela armazena de fato são

as posições em que estes bits se encontram na matriz H1. A estrutura T possui 720 elementos, de

onde pode-se concluir que a matriz H1 possui 720x51 elementos não nulos, ou seja, 36720.

Como anteriormente demonstrado, a codificação LDPC, representada pela Figura 31,

consiste na multiplicação da mensagem x pela matriz transposta de H1 seguido de um acumulador

correspondente à multiplicação pela matriz inversa de H2. Assim, uma vez definidos os

parâmetros do código, se considerou duas formas de desenvolvimeto para implementar a

multiplicação pela matriz transposta de H1, as quais serão expostas nos parágrafos seguintes.

A primeira forma consiste em armazenar a estrutura T em memória, processando grupos

de m=51, colunas de H1, através de permutações das informações das linhas de T. Uma linha da

estrutura T apresenta a informação sobre a localização dos bits ‘1’ em uma coluna da matriz H1.

Porém, através de permutações implementadas no algoritmo do codificador, essa mesma

informação possibilita estimar-se a posição dos bits ‘1’ nas 50 colunas subseqüentes, baseando-se

no grau de paralelismo m=51, utilizado para a otimização de iλ e iρ , que deram origem à matriz


H1. A estrutura T possui 114 linhas, das quais as primeiras 112 possuem três elementos e as

últimas 32 possuem doze, de onde se conclui que as primeiras 5712 (112x51) colunas de H1

possuem três bits ‘1’ e as demais 1632 (32x51) possuem doze. Somando-se o número de

colunas, totaliza-se as 7344 colunas de H1. Esta primeira forma de implementação foi

desenvolvida em liguagem VHDL e implementada em dispositivos da Altera para o

funcionamento do primeiro protótipo do transmissor apresentado em [41].

A segunda alternativa consiste em, ao invés de se utilizar a estrutura T, fazer-se uso de

uma estrutura maior, que já contenha de uma forma direta todas as posições dos bits ‘1’ ao longo

matriz H1. Esta proposta é vantajosa em um cenário no qual os blocos de memória estão

disponíveis no dispositivo de hardware onde o código será implementado e quando visa-se um

incremento em velocidade de processamento e diminuição da áera de silício ocupada, uma vez

que as permutações das linhas da estrutura T não serão mais necessárias.

Assim, dentre as duas propostas descritas para o desenvolvimento da multiplicação da

matriz transposta de H1, a segunda alternativa foi a efetivamente implementada neste trabalho e

será apresentada a seguir. Os dois motivos principais para esta escolha foram que, primeiro, o

autor deste trabalho já havia trabalhado na implementação da primeira alternativa em [41] e,

segundo, haviam recursos de memória disponíveis no dispositivo de hardware onde o codificador

foi implementado.

5.1.2 Implementação em System Generator

O codificador LDPC foi implementado na plataforma System Generator da Xilinx. Um

detalhe da implementação é que a palavra-código foi definida pela justaposição dos bits de

paridade ao final da mensagem a ser codificada. Esta ordem poderia ser invertida sem problema

algum, desde que o mesmo padrão fosse considerado na decodificação.

Para a implementação do codificador LDPC, fez-se necessária a utilização de blocos de

memória para operarem em forma de buffer de entrada e de saída (conhecidas como memórias


FIFO – First In First Out), bem como de alguns sinais de controle. O modelo da implementação

do codificador é apresentado na Figura 33.

Figura 33 – Modelo de referência da implementação do codificador LDPC.

A Figura 33 auxilia na compreensão do funcionamento do codificador, muito embora a

implementação do bloco denominado FIFO_IN exija um esclarecimento adicional. Como o

codificador LDPC insere redundância à mensagem para formar a palavra-código, existe a

necessidade de que o sistema opere em uma velocidade maior (maior taxa) depois do bloco

FIFO_IN de forma que o sistema tenha um fluxo constante de dados. Assim, para a

implementação do bloco FIFO_IN utiliza-se, ao invés de um bloco comum de memória FIFO,

como no caso do bloco FIFO_OUT, um bloco de memória especial chamado Shared Memory, o

qual permite o emprego de diferentes taxas de entrada saída de dados da memória. Em outras

palavras, a Shared Memory permite que a entrada e a saída do bloco de memória operem em

freqüências de operação diferentes. Os pinos de entrada do conjunto do codificador LDPC (por

conjunto subentende-se os blocos de memória, o codificador em si e as construção das conexões

mostradas na Figura 33) são assim constituídos.


• DataIn – entrada binária dos bits da mensagem a ser codificada;

• Write_Enable – entrada binária destinada a informar quando a entrada presente no pino

DataIn é válida;

• Reset – entrada binária destinada às configurações iniciais do sistema;

Os pinos de saída, por sua vez, são descritos como:

• Data_Out – saída binária dos bits da palavra-código;

• Valid – saída binária destinada a informar quando a saída presente no pino Data_Out é

válida.

Os controles internos do conjunto codificador são dispostos de forma a evitar que o

mesmo opere sem a alimentação de dados, como também para evitar que dados possam ser

jogados para o buffer de saída sem que este esteja disponível.

O algoritmo que descreve o funcionamento da codificação (retângulo central da Figura

33) foi implementado através de um bloco do System Generator denominado M-Code. O M-Code

permite descrever uma função em linguagem MATLAB, utilizando-se a biblioteca de ponto fixo

da Xilinx. Os parâmetros de entrada da função constituirão as portas de entrada no novo bloco, e

os argumentos de saída serão as portas de saída. Esse bloco é essencialmente importante porque

permite integrar funções descritas em MATLAB (desde que obedecendo às regras da biblioteca

de ponto fixo da Xilinx) ao System Generator e possibilita sua conversão para linguagem de

hardware HDL.

O bloco do codificador é apresentado em detalhes na Figura 34. O bloco denominado

Tabel é uma memória ROM que contém a estrutura que apresenta todas as posições dos bits ‘1’

ao longo matriz H1. O bloco chamado Parity_Block é, na verdade, uma memória RAM do tipo

porta dupla, ou seja, um mesmo dispositivo de memória com duas interfaces de acesso. A


primeira entrada foi usada somente para escrita, sendo a saída Write_Parity seu pino de

habilitação de escrita, New_Parity o dado a ser gravado e Parity_Addr_Write o endereço da

memória para gravação. Já a segunda interface de acesso à memória é utilizada apenas para a

leitura, onde Parity_Addr determina o endereço de leitura e o valor é realimentado para a entrada

do codificador através da entrada Parity. A memória do bloco Parity_Block contém espaço para

armazenar os 2448 bits de paridade. Já o algoritmo do codificador, implementado através de M-

Code, aparece na parte esquerda da Figura 34. Para o funcionamento do codificador, as entradas

Reset, Empty e Full devem estar setadas em zero. Após sua inicialização o codificador encontra-

se em estado de espera de mensagens, setando para nível lógico alto a saída Read_Fifo, que

solicita dados na entrada do codificador.

Figura 34 – Bloco do codificador LDPC em detalhes.

Um contador implementado no algoritmo controla o processamento de cada bit da

mensagem. Este tempo de processamento varia proporcionalmente a 3 (na verdade,

proporcionalmente ao grau de paralelização (m=51), vezes 3) ou proporcionalmente a 12 (na


verdade, 51 vezes 12), de acordo com a estrutura da matriz H1, como já discutido anteriormente.

Após cada bit da mensagem ser processado, ele já pode ser encaminhado para a saída do

codificador, uma vez que a primeira parte da palavra-código é constituída justamente dos bits da

mensagem. Assim, cada bit da mensagem é dirigido à saída Data_Out_Enc e a saída Valid é

setada para nível lógico alto. Ao mesmo tempo, é calculada a operação ou-exclusivo (xor) do bit

que está sendo processado com a paridade do instante anterior, a qual entra no codificador pela

entrada Parity. Esse valor será conduzido à saída New_Parity e armazenado na memória do bloco

Parity_Block no endereço fornecido pela estrutura do bloco Tabel através da saída

Parity_Addr_Write. O endereço de acesso da estrutura contida no bloco Tabel é acessado

seqüencialmente. Após processar todos os bits da mensagem e já tê-los encaminhado para

construção da palavra-código através da saída Data_Out_Enc, a saída Read_Fifo é setada para

nível lógico baixo, a fim de avisar que o codificador não poderá mais receber bits na entrada.

Essa situação de impossibilidade de recepção de novas mensagens se dará até que os 2448 bits de

paridade sejam processados para finalizar, assim, a construção da palavra-código. Desta forma, as

paridades começam a ser tiradas seqüencialmente do bloco Parity_Block e a entrar no codificador

através da entrada Parity, a fim de que o bit de paridade seja o resultado da operação ou-

exclusivo (xor) com paridade anterior, implementado assim o acumulador correspondente à

multiplicação pela matriz inversa de H2.

O código contido no bloco M-Code da Figura 34 encontra-se no apêndice A desta

dissertação.

5.2 Descrição do Hardware Empregado

Para a implementação de todo o protótipo do sistema de televisão Digital sobre IP, foram

utilizados basicamente quatro tipos de elementos de hardware:

• microcomputador (duas unidades);

• placa do Xtreme DSP Development Kit-IV, da Nallatech (duas unidades);


• placa de desenvolvimento ML-402, da Xilinx (três unidades);

• equipamentos de RF, da National Instruments (três módulos);

Os microcomputadores utilizados foram microcomputadores comuns, não necessitando de

nenhuma característica especial. As únicas exigências são que eles possuam placa de rede

instalada e uma configuração mínima para executar o player VLC [17] ou similar para efetuar a

codificação e decodificação de vídeo. Os demais hardwares envolvidos serão apresentados em

mais detalhes a seguir.

• Placa Nallatech Xtreme DSP Development Kit-IV

A placa Xtreme DSP Development Kit-IV foi desenvolvida pela Nallatech

(www.nallatech.com) e tem sua arquitetura montada a partir de uma FPGA principal Xilinx

Virtex-4 XC4VSX35, cujas características serão apresentadas posteriormente. Além da FPGA

principal, esta placa possui outras duas FPGAs secundárias e de menor porte. A primeira é uma

Virtex-2 XC2V80-4CS144, usada para fazer o gerenciamento dos sinais de relógio, e a segunda,

uma Spartan-II, usada para controlar as interfaces da placa. Além dos sinais de relógio

gerenciados pela Virtex-2 e gerados a partir do cristal contido na placa, é permitido ao usuário

utilizar um sinal externo de relógio.

Um benefício considerável desta placa são as formas de comunicação entre placa e

microcomputador. Ela dispõe de interface USB, porta JTAG-Paralela e barramento PCI. Através

do barramento PCI, por exemplo, é possível conectar-se a placa ao microcomputador e efetuar as

co-simulações descritas na Seção 2.2.2. A Figura 35 exibe a placa Xtreme DSP Development Kit-

IV com destaque para a comunicação feita pelo cabo JTAG Paralelo-IV e onde também é possível

observar, ao pé da figura, o barramento PCI.

A principal vantagem desta placa, porém, está na presença de conversores A/D e D/A de

boa qualidade. Ela possui dois conversores A/D de quatorze bits de resolução, taxa de

amostragem de 105MSPS (mega amostras por segundo), filtro de ordem três nas entradas

analógicas para limitação de banda do sinal (-3db em 59MHz) e sinais de relógio diferenciais.


Também possui dois conversores D/A com quatorze bits de resolução, taxa máxima de entrada de

dados de 160MSPS e dispositivo interno multiplicador de sinais de relógio (PLL). A Figura 36

mostra a interface dos conversores A/D e D/A bem como o pino de sinal de relógio externo.

Figura 35 – Placa Nallatech Xtreme DSP Development Kit-IV com cabo paralelo IV em destaque.

A/D 2Entrada

Analógica A/D 1Entrada

Analógica

D/A 2Saída

Analógica

D/A 1Saída

Analógica

Entradade clockExterna

Figura 36 – Entradas dos conversores da placa Nallatech Xtreme DSP Development Kit-IV.


Por outro lado, a maior desvantagem da placa Xtreme DSP Development Kit-IV é que ela

não possui uma memória não volátil, como uma memória flash, por exemplo, para sua FPGA

principal. Desta maneira, como apresentado na Seção 2.1.2, toda vez que a alimentação de

energia for suprimida da placa, o programa deverá ser recarregado para o dispositivo através de

conexão com o microcomputador.

O preço de mercado desta placa, praticado no ano de execução deste trabalho, é de

aproximadamente US$2.495,00 (preço para o mercado americano). Para informações referentes a

outros recursos e detalhes da placa, sugere-se [43].

A FPGA principal da placa Xtreme DSP Development Kit-IV é uma Virtex-4 XC4VSX35

10FF668. Esta é uma FPGA de aproximadamente 35 mil células lógicas. Dadas as formas de

medição de elementos lógicos descritos na Seção 2.1.2, este dispositivo contém

aproximadamente 15 mil slices, 30 mil flip-flops e 30 mil LUTS de 4 entradas (cada slice contém

duas LUTS). Outras características importantes desta FPGA especificamente é que ela possui 16

pinos de entrada e saída para sinais de relógio, 12 regiões de sinais de relógio, 8 DCMs

(gerenciadores digitais de sinais de relógio), 4 PMCDs (divisores de sinais de relógio), 192

BRAMs de 18 Kb e 192 DSP48, que são multiplicadores (duas entradas de 18 bits e precisão de

36 bits na saída) e acumuladores (48 bits de precisão). No capítulo seguinte, na exposição da

utilização dos recursos, estes dados certamente ficarão mais familiares. Para informações mais

detalhadas sobre FPGAs da família Virtex-4, sugere-se [44].

• Placa de desenvolvimento ML-402, da Xilinx

A placa ML-402 da Xilinx, apesar de não contar com os conversores A/D e D/A como a

placa da Nallatech, apresenta uma série de interfaces que a tornam uma plataforma de

desenvolvimento extremamente atrativa. Provavelmente a mais atrativa delas seja a interface de

rede Ethernet para conector padrão RJ-45 para operar em 10, 100 ou até 1000 Mbps. Através

desta interface, é possível a troca de dados com qualquer equipamento que possua placa de rede

ou até mesmo tornar a própria placa ML-402 um dispositivo disponível na rede.


A placa também contém outras interfaces com alto grau de atratividade como a porta

RS232, entrada para cartão externo de memória Compact Flash, porta USB e conector JTAG

para cabo paralelo-IV, o que também torna disponível o uso desta placa para realização de co-

simulação, descrito na Seção 2.2.2. A placa possuiu também display de LCD de duas linhas,

saída VGA e entrada PS2 para teclado e mouse, algumas chaves seletoras e alguns botões do tipo

push botton. Devido às várias opções de comunicação com outros equipamentos, esta placa pode

ser usada nas mais variadas aplicações. Além do mais, a placa ML-402 oferece um codificador de

áudio de 16 bits que pode operar em uma freqüência de amostragem de até 48KHz. A Figura 37

exibe a placa ML-402.

Figura 37 – Placa Xilinx ML-402.

Assim como na placa Xtreme DSP Development Kit-IV, na placa ML-402, a FPGA

principal também é uma Virtex-4 XC4VSX35. Entretanto, umas das grandes vantagens da placa

ML-402 está no fato de ela conter memória flash não volátil, o que permite que este dispositivo


seja utilizado para confecção de soluções finais. Uma vez os dados gravados na placa, a mesma

pode ser posta em operação e, mesmo em caso de falta de energia, os dados ficarão armazenados

na memória flash de forma que a FPGA pode ser carregada automaticamente sempre que for

alimentada.

Na data de elaboração deste trabalho, o valor aproximado da placa ML-402 é de

US$595,00 (preço para o mercado americano). Para mais detalhes da placa ML-402, sugere-se

[45].

• Equipamentos de RF da National Instruments

Três módulos de equipamentos da National Instruments foram utilizados. Os dois

primeiros foram os conversores elevadores (up converters), usados na transmissão, e o terceiro

foi o conversor rebaixador (down converter), usado na recepção. Esses equipamentos permitem

operações em uma banda de 9KHz a 2.7GHz. A Figura 38 apresenta os dois tipos de módulos,

conversor rebaixador à esquerda e elevador à direita, utilizados na implementação do protótipo.

Figura 38 – Equipamentos de RF da National Instruments.


5.3 Detalhamento da Implementação do Sistema

Uma vez sendo apresentada a forma de implementação, Seção 5.1, e tendo sido descrito

na Seção 5.2 o hardware utilizado, carece-se, por fim, de uma exposição da implementação em

hardware propriamente dita. Assim, este capítulo apresenta os componentes específicos de

hardware onde cada etapa do projeto foi implementada. Também, as principais particularidades

do sistema (especialmente as mais pertinentes a sistemas de televisão sobre IP) são apresentadas,

bem como as diferenças entre a implementação obtida e o sistema proposto no Capítulo 3. A

Figura 39 proporciona uma visão sistêmica detalhada do protótipo, exibindo cada hardware onde

cada tecnologia foi implantada.

Micro Computador

Placa 1 ML402

Placa Nallatech

Equipamentos da National Instruments

Fonte de Vídeo

Codificado

Fonte de Vídeo

CodificadoUDP / IPUDP / IP Interface

EthernetInterfaceEthernet

Mapeador64 QAM

Conversor D/A

Conversor Elevador



Moduladore

Alamouti

Inserção de prefixocíclico

Multiplexaçãoe inserção da

Portadora Piloto

PréAmplificador

de Sinal

ConversorRebaixador

ConversorA/D

Demapeador e LLR

DecodificadorLDPC

UDP / IPDecodificador

de VídeoH.264

Reprodutor de Vídeo

InterfaceEthernet

FiltroPassa Baixa

Demoduladore

Alamouti

Demoduladore

Alamouti

Ajuste de TaxaAjuste

de Taxa

Ajuste de TaxaAjuste

de Taxa

Placa 2 ML402

Placa de RedeVLC

II Xilinx Virtex 4Módulo de RF

Módulode RF

II Xilinx Virtex 4I Xilinx Virtex 4

VLC

AleatorizadorAleatorizadorAleatorizador

I Xilinx Virtex 4

Codificador LDPC

Codificador LDPC

DesaleatorizadorDesaleatorizador

III Xilinx Virtex 4

Implementação Apresentada na Dissertação

Figura 39 – Visão global da implementação com definições de hardware.


O microcomputador utilizado no transmissor executa o VLC como gerador de transport

stream, onde é feita a configuração para geração de dados no formato UDP/IP e setado o

endereço IP de destino. Este endereço IP deve ser o mesmo endereço IP da interface de rede (RJ-

45) da placa ML-402 do transmissor. É importante salientar que, na solução de resolução de

protocolos, implementada na placa ML-402, não existe troca de mensagens para alimentação de

tabelas ARP. Desta forma, o microcomputador não sabe qual o endereço IP associado à interface

de rede da placa ML-402, placa esta conectada a ele através de um cabo do tipo cross-over. Tudo

o que o computador consegue “enxergar” é o endereço MAC da interface. Por isso, antes do

início da transmissão, o operador deverá editar manualmente a tabela ARP do computador, de

forma a associar o endereço IP gravado na interface de rede da placa ML-402 ao seu endereço

MAC. Suponha que o endereço IP gravado na placa transmissora ML-402 seja 192.168.8.113 e

que o endereço MAC de sua interface de rede seja 00-A5-BB-BB-55-36. Essa edição da tabela é

feita através do comando <ARP –s 192.168.8.13 00-A5-BB-BB-55-36>, digitado a partir do prompt do

DOS. Este comando autoriza o computador a associar em sua tabela ARP o endereço IP

192.168.8.13 à interface proprietária do endereço MAC 00-A5-BB-BB-55-36. Uma vez efetuado

este procedimento, os dados gerados pelo VLC destinados ao endereço IP da placa ML-402 serão

encaminhados à interface de rede da placa. Também, os quadros do tipo MAC que serão

encaminhados à placa ML-402 possuirão em seu cabeçalho, no campo “tipo” (2 bytes), o valor

#0800#, informando que os dados contidos no campo da mensagem correspondem a dados do

tipo IP. O formato do quadro MAC pode ser visualizado na Figura 22.

Uma das exigências do sistema de televisão digital desenvolvido é que ele opere na taxa

de 19,33Mbps. Quando o quadro MAC é entregue à placa ML-402 transmissora, ele passa pelo

processo de ajuste de taxa, o qual está implementado no mesmo dispositivo Virtex-4 da placa, tal

qual o controle da interface Ethernet. Esse ajuste de taxa é necessário para garantir o throughput

de 19,33Mbps mesmo quando o vídeo transmitido é gerado com uma taxa inferior. Assim, de

uma maneira bastante simplória, pode-se dizer que, efetivamente, o ajuste de taxa do transmissor

acrescenta quadros nulos à informação, a fim de que a taxa de transmissão seja mantida constante

em 19,33Mbps. Um diagrama simplificado da implementação do ajuste de taxa é exibido na

Figura 40.


A idéia básica do controle de taxa consiste em transmitir pacotes de dados nulos, ou seja,

pacotes que não contêm informação útil, sempre que for solicitado um dado pelo sistema e este

dado ainda não esteja disponível. Isto ocorre quando a taxa do vídeo a ser transmitido é menor

que a vazão do sistema, sendo necessário preencher a diferença com pacotes nulos. Desta forma,

existem dois tipos de pacote que podem ser transmitidos. Uma vez iniciada a transmissão de um

pacote, de um tipo, a mesma deverá ser feita até o final do mesmo, para só então poder transmitir

um pacote de um outro tipo. Apesar de aparentemente evidente, esta regra é bastante importante

para poder distinguir, no receptor, entre os dois tipos de pacotes, para poder descartar os pacotes

nulos e, então, recuperar o fluxo de vídeo original.

Quadro MACdisponível

de LeituraSolicitação

Entrada Byte

Valido

Índice do

Quadro

Fonte Pacotes Nulos

Garante ciclode 1358bytes

Válido Pacotes Nulos

Habilita Leitura Fifo

Saída Byte

Saida Válido

Figura 40 – Diagrama simplificado da implementação do ajuste de taxa.

Desta forma, dois estados são definidos para o circuito de ajuste de taxa: ler pacote de

dados ou ler pacote nulo. Este estado é representado pelo registrador “Garante Ciclo de 1358

bytes” e, como o próprio nome indica, permanece em um mesmo estado pelo menos durante 1358

bytes consecutivos, que é o tamanho de um pacote de dados ou de um pacote nulo. O objetivo

deste registrador é informar se existem, ou não, pacotes de dados disponíveis para leitura. Essa


informação é atualizada sempre que é terminada a leitura de um pacote. Deste modo, sempre que

for iniciar a leitura de um novo pacote, ou seja, quando o “Índice do Quadro” for igual a 1357, o

sinal de controle “Quadro MAC disponível” é verificado e armazenado no registrador. Observe

que os termos quadro e pacote são utilizados aqui sem distinção.

Com estes conceitos em mente, fica fácil entender os sinais de saída do controle de taxa.

O estado do circuito (“Garante ciclo de 1358 bytes”) controla os seletores que conduzem as

saídas “Saída Byte” e “Saída Válido”. Quando o estado é “0”, ou seja, não existe pacote de dados

disponível para leitura, então, o pacote nulo é lido a partir de uma memória ROM. O endereço de

leitura é fornecido pelo contador “Índice do Quadro”. O sinal de válido neste caso é a própria

solicitação de leitura proveniente do sistema.

Por outro lado, quando o estado do circuito é “1”, significa que há pelo menos um pacote

de dados disponível para leitura, e então o sinal “Solicitação de Leitura”, proveniente do sistema,

é passado para a FIFO que armazena os pacotes de dados. Deste modo, os dados do pacote, lidos

da FIFO de entrada, são disponibilizados nas entradas “Entrada Byte” e “Valido” do circuito do

controle de taxa, e passados adiante para as saídas “Saída Byte” e “Saída Valido”.

No receptor, conforme pode ser observado na Figura 39, também existe um bloco de

ajuste de taxa. Esse bloco consiste em simplesmente ler o cabeçalho dos quadros MAC, após este

ser desaleatorizado, e descartar todos os pacotes que contêm o valor hexa #FFFF# no campo

“tipo” do cabeçalho MAC. Vale destacar que todos os pacotes nulos inseridos no sistema contêm

o valor #FFFF# no referido campo.

Concluída a etapa do ajuste de taxa, a informação passa pelo aleatorizador, o qual foi

implementado de acordo com a Figura 41. Tal qual mostrado na figura, o aleatorizador garante

que o comportamento na distribuição dos bits será aleatório, graças ao bloco lógico que executa a

operação ou-exclusivo entre os dados provenientes do estágio de ajuste de taxa e uma seqüência

pseudo-aleatória, pn. Apesar de suas entradas serem dadas em byte, o aleatorizador funciona ao

nível de bit, pois a operação ou-exclusivo apresentada é feita bit a bit. Um cuidado tomado na

implementação do aleatorizador foi o de não aleatorizar os primeiros quatorze bytes do cabeçalho


do quadro MAC, referentes ao endereçamento, uma vez que estas informações são utilizadas no

sincronismo de quadro.

No lado do receptor, tal qual no microcomputador transmissor, também o

microcomputador receptor necessita efetuar o processo de atualização da tabela ARP a fim de

que ele associe o endereço MAC da placa ML-402 interligada a ele via cabo cross-over ao

endereço IP da mesma. Outro ponto bastante interessante utilizado na implementação foi o de

usar o mesmo endereço IP para a placa ML-402 do transmissor e placa de rede do

microcomputador receptor. De igual forma, manteve-se o mesmo endereço IP do

microcomputador transmissor com a placa ML-402 que está ligada via cabo cross-over ao

microcomputador receptor. Este recurso é especialmente vantajoso por evitar que o cabeçalho

MAC necessite ser editado ao longo de todo processamento realizado nas FPGAs. Em outras

palavras, o roteamento IP foi implementado manualmente.

Figura 41 – Implementação do aleatorizador.

Os demais blocos encontram-se normalmente implementados conforme a Figura 39. As

partes de modulação e demodulação OFDM, sincronismo, multiplexação, inserção de portadora-

piloto, conversor rebaixador digital, conversor elevador digital, mapeamento, LLR, foram

implementados em uma placa Nallatech Xtreme DSP Development Kit-I para o transmissor e uma

para o receptor. A implementação do decodificador LDPC necessitou de uma placa ML-402


exclusiva. Assim, conforme evidenciado na Figura 39, o transmissor exigiu uma placa ML-402 e

uma placa Nallatech Xtreme DSP Development Kit-IV, enquanto o receptor demandou duas

placas ML-402 e uma placa Nallatech Xtreme DSP Development Kit-IV.

Os equipamentos na National Instruments foram utilizados para operar na freqüência da

banda passante do sistema, sendo utilizados como conversores elevadores no transmissor

(diversidade de transmissão) e como conversor rebaixador no receptor. A potência por eles

irradiada não é elevada, uma vez que seu objetivo é apenas oferecer uma situação de teste ao

protótipo.

Por fim, faz-se necessário informar a não-implementação do codificador e decodificador

Reed-Solomon do modelo apresentado no Capítulo 3. A idéia de implementação do codificador

Reed-Solomon analisada foi de um modelo similar ao proposto em [39]; um código encurtado

RS(204,188) derivado de um código RS(255,239) com polinômio 8 4 3 2 1X X X X+ + + + . Tanto

o codificador quanto o decodificador Reed-Solomon fazem parte dos NPIs disponíveis no

AccelWare (Seção 2.3.2).

Na configuração inicial da proposta, não havia nenhum entrelaçador entre os

codificadores LDPC e Reed-Solomon. Porém, através de simulações, verifica-se que, para este

caso, a taxa de erro de bit na saída do decodificador Reed-Solomon é praticamente a mesma da

saída do decodificador LDPC, para os tamanhos de bloco usados. Esse fenômeno se dava

especialmente, porque as estatísticas de erro na saída do decodificador LDPC mostraram que os

erros ocorriam de forma bastante dispersa dentro da palavra-código e isso resultava no

comprometimento do desempenho do decodificador Reed-Solomon, devido ao fato de que sua

melhor atuação se dá quando os erros ocorrem em rajadas [21]. Para solucionar este problema,

mantendo a codificação Reed-Solomon, é necessário fazer com que o número médio de bits em

erro por bloco Reed-Solomon se mantivesse dentro da capacidade do código (Seção 4.2).

Visando solucionar este problema, é necessária a colocação de um entrelaçador, de forma que ele

opere entre os codificadores Reed-Solomon e LDPC e, conseqüentemente, que um

desentrelaçador equivalente opere entre os respectivos decodificadores.


Diante do exposto, de que, de acordo com [21], para este modelo de implementação o

desempenho com e sem codificação Reed-Solomon é praticamente o mesmo quando não se

utiliza um sistema entrelaçador/desentrelaçador entre a codificação LDPC e Reed-Solomon,

optou-se pela não-implementação da codificação Reed-Solomon.

119

119

Capítulo 6 Resultados, Demonstrações e Comparações 6.1 Quanto ao Desempenho e Comprimento do Código LDPC

Na seção correspondente à descrição da implementação do código LDPC, observou-se

que a idéia inicial de projeto do código LDPC previa um comprimento de bloco da ordem de

40Kb e que, no entanto, optou-se por um código de palavra-código da ordem de 10Kb. Quanto

maior o comprimento de bloco de um código LDPC, para uma mesma taxa, menor será a taxa de

erro de bit para uma mesma relação sinal ruído, como se pode perceber na Figura 42.

Curva de desempenho para canal AWGN e taxa=0,5

Eb/N0 (dB)

BE

R

Figura 42 – Curva de desempenho de código LDPC em função do comprimento do código.

Capítulo 6 – Resultados, Demonstrações e Comparações 120

A base do incremento de desempenho em função do tamanho de bloco está no fato de a

capacidade de correção de erro em um código LDPC ser diretamente proporcional ao

comprimento do bloco. Na Figura 43, tem-se também a medida de desempenho do código em

função do comprimento de bloco.

Figura 43 – Curva característica de um código LDPC em função do comprimento do mesmo.

Desta maneira, a conclusão mais imediata a que se poderia chegar é a de que o código

deveria ter seu tamanho de bloco ampliado e não subtraído, como o ocorrido no projeto. No

entanto, em termos práticos, seria extremamente custoso, por exemplo, desenvolver em hardware

o circuito de codificação e decodificação LDPC com um bloco de 40Kb, tendo em vista a

quantidade de bits que necessitariam ser acessados simultaneamente. Por fim, após certo limiar,

percebe-se que o ganho proporcionado pelo aumento do tamanho do bloco passa a não ser mais

tão atrativo, ou seja, pode-se afirmar que serão raras as situações onde compensará aumentar

tanto o esforço em desenvolvimento de hardware para um ganho não tão significativo.

Vale destacar ainda que o comprimento de 9792 bits para a palavra-código foi escolhido

como o maior tamanho possível viável de se implementar em uma FPGA Virtex-4 XC4VSX35,

em função da quantidade de lógica (LUTs e slices) e, principalmente, pela quantidade de


memórias (BRAMs) disponíveis. De fato, o projeto do decodificador, como será mostrado

adiante, ocupou praticamente todos os recursos da FPGA. Além disso, este comprimento foi

escolhido de forma a facilitar a implementação do sistema, de tal modo que seja múltiplo de 8, de

6 e de 204. Além disso, o tamanho do quadro OFDM, que corresponde a 34 símbolos OFDM

(34×6×1248 bits), também deveria ser múltiplo do comprimento da palavra código, onde 1248 é

o número de portadoras efetivas de dados entre as 2048 possíveis.

6.2 Comparações de Modelos de Implementação 6.2.1 System Generator Versus AccelChip

Para efeito de comparação, desenvolveu-se o mesmo algoritmo do codificador LDPC

(exibido no apêndice A deste trabalho), implementado através da linguagem de ponto fixo da

Xilinx no bloco M-Code, em linguagem Matlab, para que este pudesse ser implementado em

hardware através da ferramenta AccelChip. Os resultados referentes à ocupação do dispositivo

Xilinx Virtex-4 XC4VSX35XC, com a implementação dada através da ferramenta AccelChip,

encontram-se exibidos na Figura 44.

Figura 44 – Relatório de ocupação da FPGA com o código do codificador LDPC desenvolvido em AccelChip.


Por sua vez, os resultados mais significativos, referentes à ocupação do dispositivo,

obtidos pela implementação feita em System Generator, são apresentados na Figura 45.

Figura 45 – Relatório parcial de ocupação da FPGA com o código do codificador LDPC

desenvolvido no bloco M-Code do System Generator.

Com base nos dados apresentados, percebe-se que a implementação feita em AccelChip

consome mais área do dispositivo ou, em outras palavras, que a implementação dada em System

Generator é mais otimizada. É importante destacar que a diferença entre as implementações está

na plataforma utilizada para geração do código em linguagem de hardware HDL, uma vez que

ambos foram submetidos à mesma ferramenta de síntese, XST. Embora o algoritmo do

codificador LDPC ocupe uma área relativamente pequena do dispositivo, a diferença de ocupação

de lógica entre as duas soluções foi em torno de cinqüenta por cento. Contudo, como apenas um

percentual muito pequeno da lógica do dispositivo é consumido, uma análise absoluta dos

números pode ser mais razoável do que uma análise em termos percentuais.

6.2.2 System Generator Versus VHDL

Para a comparação das formas de implementação dadas em System Generator e VHDL,

tomou-se todo o conjunto codificador LDPC, apresentado na Figura 34, para que o mesmo fosse

também implementado na linguagem VHDL. O desenvolvimento em VHDL deu-se da forma

mais fiel possível ao código concebido no bloco M-Code, de modo a tornar a comparação mais

eqüitativa. Os resultados são apresentados a seguir, onde a Figura 46 é relativa aos resultados da


implementação realizada em VHDL, e a Figura 47, aos resultados da implementação dada em

System Generator.

Figura 46 – Relatório parcial de ocupação da FPGA com o conjunto codificador LDPC desenvolvido em VHDL.

A análise comparativa do desempenho permite confirmar o já esperado, o

desenvolvimento em VHDL resultou em uma melhor otimização. No entanto, merece

considerável destaque o fato de a implementação em System Generator ter apresentado um

desempenho bastante satisfatório em termos de ocupação de slices. Apesar de haver ocorrido um

aumento na área de silício ocupada, este aumento acrescido pela ferramenta de automação foi de

apenas dezoito por cento, aproximadamente.

Figura 47 – Relatório parcial de ocupação da FPGA com o conjunto codificador LDPC, com otimização em termos

de velocidade e desenvolvido em System Generator.


No caso deste esquema (Figura 33), de apenas três blocos interligados, acrescidos de um

código relativamente curto, é possível desenvolver o código em VHDL com um grau de

dificuldade não muito elevado. Contudo, percebe-se que, para sistemas mais complexos, se

aplicaria o paradigma descrito no capítulo introdutório, ou seja, seria necessário dispor de um

especialista na aplicação em desenvolvimento e um especialista em hardware. A relativamente

pequena quantidade de lógica adicional exigida pelo System Generator é justificada pela

simplificação que sua utilização proporciona.

6.2.3 Otimização em Área versus Otimização em Velocidade

Uma das grandes vantagens de se operar com ferramentas de síntese é que o

desenvolvedor pode informar à ferramenta qual a sua principal prioridade, se ocupação de área de

silício do dispositivo ou velocidade de processamento. Dentro das suas limitações, a ferramenta

tentará atender às solicitações, sacrificando uma em detrimento da outra. Esta é a principal

relação de compromisso ao trabalhar-se com FPGAs. Para atender às solicitações, antes de mais

nada a ferramenta tentará garantir as restrições editadas no arquivo de restrições ucf.

Almejando uma forma de melhor analisar essa situação, implementou-se o conjunto

codificador priorizando a otimização em virtude de velocidade e, em uma segunda

implementação, priorizando a otimização da ocupação de área do dispositivo.

Figura 48 – Relatório parcial de ocupação da FPGA com o conjunto codificador LDPC, otimização em termos de

área e desenvolvido em System Generator.


A síntese priorizando a velocidade é a mesma exibida pela Figura 47. Já a Figura 48

apresenta o mesmo projeto, porém com a síntese priorizando a otimização da ocupação de área

do dispositivo.

Quando foi utilizada a otimização em função da área de ocupação do dispositivo,

observou-se uma redução na lógica consumida pelo circuito, como mostrado pelo número de

slices na Figura 48. Embora a redução de área tenha sido pequena, em circuitos maiores e mais

complexos esse índice de redução tende a ser superior.

A medida de quanto será otimizado em função de área ou velocidade, depende

essencialmente da ferramenta de síntese. Em todos os casos apresentados neste trabalho, a

ferramenta de síntese utilizada foi o XST, que acompanha o Design Flow da Xilinx. Ferramentas

de síntese, reconhecidamente mais eficientes, como, por exemplo, o Leonardo Spectrum da

Mentor Graphs, tendem a oferecer resultados mais satisfatórios.

6.3 Demonstrações de Ocupação dos Dispositivos

Terminada a implementação do protótipo do sistema, verificou-se que não houve

subdimensionamento de hardware especificado. Ao contrário, em praticamente todas as placas

utilizadas, houve uma considerável folga de segurança no que se refere à ocupação dos

dispositivos.

Até esta seção do trabalho, todos os relatórios de ocupação apresentados foram gerados

exclusivamente para demonstrações, em função da metodologia adotada. Partes isoladas do

sistema foram implementadas, a fim de se saber, de uma forma exata, sua ocupação e possíveis

problemas. A seguir, são apresentados os relatórios de ocupação de área de todos os componentes

programáveis efetivamente empregados no sistema. Alguns componentes aparecem com vários

módulos implementados. A ordem será a partir do transmissor para o receptor. A descrição

acompanha a mesma referência da Figura 39.

A Figura 49 apresenta a ocupação da primeira FPGA Virtex-4, da Placa ML-402. Nela

estão implementados o ajuste de taxa, aleatorizador e codificador LDPC. Observa-se que o


sistema foi implementado com considerável sobra de recursos, dada uma ampla quantidade de

elementos lógicos disponíveis no dispositivo.

Figura 49 – Relatório parcial de ocupação da primeira FPGA empregada no protótipo. Nesta FPGA, estão

implementados o MAC Ethernet, o ajuste de taxa, o aleatorizador e o codificador LDPC.

A segunda FPGA do sistema, também uma Virtex-4, é a FPGA principal da placa Xtreme

DSP Development Kit-IV. Nela está o mapeador QAM, o sistema de multiplexação, inserção de

portadora piloto, modulador OFDM (com a IFFT) e Alamouti, conversor elevador digital e

inserção de prefixo cíclico. A ocupação deste dispositivo ultrapassa os oitenta por cento, mas

garante uma folga considerável para atualizações e implementação de lógica para correção de

possíveis erros. A ocupação da segunda FPGA do sistema é mostrada pela Figura 50.

Figura 50 – Relatório parcial de ocupação da segunda FPGA empregada no protótipo. Nesta FPGA, estão

implementados o mapeador, o multiplexador, o modulador e Alamouti e a inserção de prefixo cíclico.


A terceira FPGA do sistema já se encontra no receptor e serve como front-end do sistema.

Ela está embarcada em uma placa Xtreme DSP Development Kit-IV. Nesta FPGA, está

implementado o filtro passa-baixa de recepção, demodulador OFDM (com a FFT) e Alamouti,

conversor rebaixador digital, demapeador e LLR. O relatório de ocupação desta FPGA

corresponde à Figura 51.

Figura 51 – Relatório parcial de ocupação da terceira FPGA empregada no protótipo. Nesta FPGA, estão

implementados o filtro passa-baixa, o demodulador e Alamouti, o demapeador e a LLR.

Uma placa ML-402 abriga a quarta FPGA do sistema, a qual é destinada exclusivamente à

implementação do decodificador LDPC. Seu relatório de ocupação é exibido pela Figura 52, onde

destaca-se o elevado número de blocos de memória utilizados. Noventa e nove por cento das

BRAMs são utilizadas. Essa arquitetura foi propositalmente escolhida pelos projetistas do

decodificador LDPC, temendo que a implementação da lógica apenas em slices excedesse a

quantidade de células lógicas disponíveis no dispositivo.

Por fim, é apresentado, na Figura 53, o relatório com os dados mais significativos de

ocupação da quinta e última FPGA principal do protótipo. Este dispositivo tem apenas uma

pequena quantidade de sua capacidade ocupada. É nesta FPGA que se encontram o

desaleatorizador, o ajuste de taxa e a comunicação com o microcomputador receptor.


Figura 52 – Relatório parcial de ocupação da quarta FPGA empregada no protótipo. Nesta FPGA, está implementado

o decodificador LDPC.

Figura 53 – Relatório parcial de ocupação da quinta FPGA empregada no protótipo. Nesta FPGA, estão

implementados o desaleatorizador, o ajuste de taxa e o MAC Ethernet.

129

129

Capítulo 7 Considerações Finais e Trabalhos Futuros

Este trabalho apresentou a implementação em hardware de um codificador LDPC para um

sistema de televisão digital através da utilização de ferramentas de prototipagem rápida para

FPGAs. No esquema implementado, o codificador seguiu os preceitos de um código eIRA

(extended Irregular Repeat Accumulate), com palavra-código de 9792 bits de comprimento e taxa

3/4. Da mesma forma, as ferramentas inovadoras de prototipagem rápida, empregadas no

desenvolvimento, foram introduzidas.

Um dos aspectos importantes abordados neste trabalho refere-se à união da etapa de

concepção do código com sua efetiva implementação em um dispositivo de hardware.

Recentemente, dois pontos-chave têm recebido essencial importância. Primeiro, as FPGAs têm

mostrado ser a melhor solução para a implementação em hardware, especialmente nas etapas de

desenvolvimento e de prototipagem. Segundo, as ferramentas de projeto têm sido projetadas para

proporcionar soluções de desenvolvimento de alto nível e que propiciem ganho de produtividade.

Desta forma, este trabalho expôs propostas de desenvolvimento e tendências de novas tecnologias

de projeto, apresentando resultados concretos através de uma implementação dada em FPGA.

De fato, o cenário atual exige que o desenvolvimento de soluções tecnológicas seja cada

vez mais ágil e rápido. Constatou-se na elaboração deste trabalho, que as ferramentas de

Capítulo 7 – Considerações Finais e Trabalhos Futuros 130

prototipagem rápida apresentadas possibilitam inúmeras vantagens no que se refere ao tempo de

desenvolvimento, testes, análise de relações de compromisso e facilidade de alteração do projeto.

Não obstante, em um contexto mais geral, foi oferecida uma visão sistêmica do sistema de

televisão digital, desenvolvido para operar sobre o protocolo de internet (IP). Esta apresentação, a

qual foi antecedida de uma introdução, visou contextualizar os trabalhos oferecidos nesta

dissertação, bem como exemplificar as potencialidades das ferramentas de prototipagem rápida

apresentadas. Algumas particularidades do sistema proposto também foram apresentadas como

forma de elucidar as características peculiares do sistema, tal qual foi o caso da explanação sobre

o ajuste de taxa necessário para o funcionamento do protótipo.

Como possíveis extensões a este trabalho, a implementação de diferentes estruturas de

códigos LDPC podem proporcionar uma amplo leque de análises, principalmente, referentes ao

desempenho e à ocupação destes em FPGAs. Estruturas de códigos regulares e irregulares podem

ser experimentadas. Da mesma forma, estudos mais elaborados e desenvolvimento de modelos de

implementação, ambos relativos à decodificação LDPC, podem ser desenvolvidos com mais

apreço.

Ademais, ferramentas de síntese mais poderosas podem ser aplicadas à etapa de

desenvolvimento, a fim de otimizar as implementações, especialmente no que se refere à

ocupação de área de silício do dispositivo. Uma vez obtidos resultados satisfatórios, pode-se

estudar a viabilidade de futuras implementações em dispositivos de hardware de menor porte.

131

131

Referências Bibliográficas

[1] Cesear, T.M.; “Optimizing Performance of DSP Systems through Block-Level Design”,

Embedded Conference of San Francisco, 2005.

[2] Ganousis, D.; “Top-Down DSP Design Flow to Silicon Implementation”, FPGA and

Programmable Logic Journal, March of 2004.

[3] Maxfield, C.; “The Design Warrior’s Guide to FPGAs – Devices, Tools and Flows”,

Elsevier, 2004.

[4] Powell, S.R.; Cesear T.M.; “Rapid Design and Exploration of Signal Processing using a

VHDL Model Generator Based Paradigm”, Second Annual RASSP (Rapid Prototyping

of Application Specific Signal Processors) Conference, 1996.

[5] AccelChip Inc.; “Automated Conversation of Floating-point to Fixed-point Matlab”.

Disponível em http://www.accelchip.com/papers.html, 2004. Acessado em janeiro de

2006.

[6] Presidência da República, Casa Civil, Subchefia para Assuntos Jurídicos; “Decreto

Presidencial número 5820”, 26 de Novembro de 2003, Brasília, Brasil. Disponível em

https://www.planalto.gov.br/ccivil/decreto/2003/D4901.htm. Acessado em outubro de

2006.

[7] Xilinx Inc.; “FPGA Design Flow Overview”; Disponível em

http://toolbox.xilinx.com/docsan/xilinx7/help/iseguide/html/ise_fpga_design_flow_over

view.htm . Acessado em outubro de 2006.

[8] Xilinx Inc.; “System Generator For DSP”; Disponível em

http://www.xilinx.com/support/sw_manuals/sysgen_ug.pdf. Acessado em outubro de

2006.

Referências Bibliográficas 132

[9] Xilinx Inc.; “Simulation Models”; Disponível em

http://support.xilinx.com/techdocs/15338.htm. Acessado em dezembro de 2005.

[10] AccelChip Inc.; “Matlab for Synthesis Style Guide”; California, USA, 2005.

[11] AccelChip Inc.; “AccelChip DSP Synthesis User Guide”, California, USA, 2005.

[12] Gonzales, R.C.; Woods, R.E.; “Digital Image Processing”; USA: Addison-Wesley

Publishing Company, 1993.

[13] Bhaskaran; Vasudev; Konstantinides; Konstantinos; “Image and Video Compression

Standards”; Kluwer Academic Publishers 2nd Edition, 1997.

[14] Y. Wang; J. Ostermann, Y. Zhang; “Video Processing and Communications”; Prentice

Hall, Signal Processing Series, 2002.

[15] C. Poynton; “Digital Video and HDTV Algorithms and Interfaces”; Morgan Kaufman

Publishers, 2003.

[16] F.C.C. de Castro; M.C.F. de Castro; “Codificação de Sinais”, PUCRS, Porto Alegre.

Disponível em http://www.ee.pucrs.br/~decastro/pdf/cs5.pdf . Acessado em outubro de

2006.

[17] VideoLAN; “Software Development Project”. Disponível em www.videolan.org. Acessado

em julho de 2006.

[18] Tanenbaum, A.S.; “Computer Networks”; USA, Prentice Hall, 4th Edition, 2003.

[19] Pinheiro, J.M.S.; “Frames, Pacotes e Datagramas”. Disponível em

http://www.projetoderedes.com.br/artigos/artigo_frames_datagramas_pacotes.php .

Acessado em julho de 2006.

[20] IETF (Internet Engineering Task Force); “Request For Comment 0768 - User Datagram

Protocol”. Disponível em http://www.ietf.org/rfc/rfc0768.txt. Acessado em julho de

2006.

[21] José Marcos Câmara Brito; José Santo Guiscafré Panaro; Dayan Adionel Guimarães;

Cristiano Magalhães Panazio; Luciano Leonel Mendes; Geraldo Gil Ramundo Gomes;

“Recomendações para Modelo de Referência”; Convênio 0026/05 em atendimento a

carta convite MC/MCT/FINEP/FUNTTEL- TV Digital - 18/2004, fevereiro de 2006.

[22] T. Kailath, “A general likelihood-ratio formula for signals in Gaussian noise” ; IEEE

Trans. Inf. Theory, vol. IT-15, pp. 350-361; May of 1969.


[23] M. K. Simon and R. Annavajjala; “On the Optimality of Bit Detection of Certain Digital

Modulations”; IEEE Trans. on Communications, vol. 53, nº 2, February of 2005.

[24] Ahmad R. S. Bahai and Burton R. Saltzberg; “Multi-Carrier Digital Communications:

Theory and Applications of OFDM”; Kluwer Academic Publishers, 2002.

[25] K. Fazel and S. Kaiser; "Multi-Carrier and Spread Spectrum Systems"; John Wiley & Sons,

2003.

[26] S. Alamouti; "A simple transmit diversity technique for wireless communications"; IEEE J.

Select. Areas Communications; volume 16, no 8, pp. 1451-1458, October of 1998.

[27] A.B. Carlson; “Communications Systems”; McGraw-Hill, 1965.

[28] Shu Lin, Daniel Costello Jr.; “Error Control Coding”; Pearson Prentice Hall, Second

Edition, 2004.

[29] I.S. Reed, G. Solomon; “Polynomial Codes Over Certain Finite Fields” ; Journal of the

society for Industrial and Applied Mathematics, vol. 8, nº2, 1960.

[30] Chi-Tsong Chen; “Linear System Theory and design”; Harcourt Brace College Publisher,

1984.

[31] 4i2i IP Cores Supplier; “Reed-Solomon Tutorial”. Disponível em

http://www.4i2i.com/reed_solomon_codes.htm. Acessado em novembro de 2006.

[32] R. G. Gallager; “Low-density parity-check codes”; IRE Transactions on Information

Theory, vol. IT-8, pp. 21–28, January of 1962.

[33] R.G. Gallager; “Low Density parity-check codes”; Monography, MIT Press, 1963.

[34] R. M. Tanner; “A recursive approach to low-complexity codes”; IEEE Trans. Information

Theory, pp. 533–547, September of 1981.

[35] D. MacKay; “Good error-correcting codes based on very sparse matrices”; IEEE Trans.

Information Theory, pp. 399–431, March of 1999.

[36] M. Luby; M. Mitzenmacher; A. Shokrollahi; D. Spielman; “Improved low-density parity-

check codes using irregular graphs”; IEEE Transactions on Information Theory, vol.47,

pp.585-598, February of 2001.

[37] M. Yang; W. Ryan; and Y. Li; “Design of efficiently encodable moderate-length high-rate

irregular LDPC codes”; IEEE Trans. Communications, vol. 52, nº 4, pp. 564-571, April

of 2004.


[38] Y. Zhang; W. Ryan; and Y. Li; “Structured eIRA codes with low floors”; Proceedings of the

International Symposium on Information Theory - ISIT2005, pp. 74–178, September of

2005.

[39] ETSI (European Telecommunications Standards Institute); “DVB-S.2 Standard

Specification”. Disponível em http://webapp.etsi.org/action/PU/20050322/en

302307v010101p.pdf. Acessado em junho de 2006.

[40] T. J. Richardson and R. Urbanke; “The capacity of low-density parity check codes under

message-passing decoding”; IEEE Transactions on Information Theory, Vol. 27, nº 2.

February of 2001.

[41] Tarciano F. Pegoraro; Fábio A. L. Gomes; Renato R. Lopes; Roberto Gallo; José S. Panaro;

Marcelo C. Paiva; Fabrício C. A. Oliveira and Fabio Lumertz; “Design, Simulation and

Hardware Implementation of a Digital Television System: LDPC channel coding”;

IEEE 9th International Symposium on Spread Spectrum Techniques and Applications

(ISSSTA), Manaus, Brazil, August 2006.

[42] Tarciano F. Pegoraro; Fábio A. L. Gomes; Fábio Lumertz; Renato R. Lopes; Fabrício C. A.

Oliveira; Roberto Gallo; Marcelo C. Paiva e José S. Panaro; “Codificação LDPC em

Sistemas de Televisão Digital”; Revista Telecomunicações, vol.9, Santa Rita do Sapucaí,

MG, Brasil, dezembro de 2006.

[43] Nallatech Inc.; “Xtreme DSP Development KIT-IV User Guide”; April of 2005.

[44] Xilinx Inc.; “Virtex-4 User Guide”; version 1.6, October of 2006. Disponível em

http://www.xilinx.com/bvdocs/userguides/ug070.pdf. Acessado em novembro de 2006.

[45] Xilinx Inc.; “ML40x Evaluation Platform User Guide”; version 1.0.1, June of 2006.

Disponível em http://www.xilinx.com/bvdocs/userguides/ug210.pdf . Acessado em

novembro de 2006.

135

135

Apêndice A Código Fonte do Bloco M-Code que Implementa o Codificador LDPC function [Read_Fifo, Write_Enable, Data_Out_Enc, Write_Parity, Parity_Addr_Write, Parity_Addr, New_Parity,AddrAddr] = ENCODER(Reset, Empty, Full, Data_In, Parity, Parity_Addr_Tabel) %% Registrar as saídas: persistent Write_Enable_sc, Write_Enable_sc = xl_state(0,{xlUnsigned,1,0}); persistent Data_Out_Enc_sc, Data_Out_Enc_sc = xl_state(0,{xlUnsigned,1,0}); Write_Enable = Write_Enable_sc; Data_Out_Enc = Data_Out_Enc_sc; %% Constantes: idle = 0; first = 1; second = 2; third = 3; fourth = 4; init = 0; %% Estados Internos: persistent count_vc, count_vc = xl_state(init, {xlUnsigned,16,0}); % Conta as posições ate 36720; persistent auxcount_vc, auxcount_vc = xl_state(init, {xlUnsigned,4,0}); % conta até 3 ou até 12; persistent tmp, tmp = xl_state(init, {xlUnsigned,1,0}); persistent parWrite, parWrite = xl_state(init, {xlUnsigned,12,0}); persistent state, state = xl_state(idle, {xlUnsigned, 3, 0}); if Reset==1 count_vc = init; auxcount_vc = init; tmp = init; parWrite = init; state = idle; Read_Fifo = 0; Write_Enable_sc = 0; Write_Parity = 0; AddrAddr = 0; Data_Out_Enc_sc = 0;

Apêndice A 136

Parity_Addr_Write = 0; Parity_Addr = 0; New_Parity = 0; else if((Empty == xfix({xlUnsigned,1,0},0))& (Full_sc == xfix({xlUnsigned,1,0},0))) switch state case idle state = first; Read_Fifo = 1; Write_Enable_sc = 0; Write_Parity = 0; AddrAddr = 0; Data_Out_Enc_sc = 0; Parity_Addr_Write = 0; Parity_Addr = 0; New_Parity = 0; case first parWrite = xfix( {xlUnsigned,12,0}, 22); count_vc = 2; auxcount_vc = 1; state = second; Read_Fifo = 0; Write_Enable_sc = 0; Write_Parity = 1; AddrAddr = xfix( {xlUnsigned,16,0}, 2); % AddrAddr; Data_Out_Enc_sc = 0; Parity_Addr_Write = xfix( {xlUnsigned,12,0}, 21); Parity_Addr = xfix( {xlUnsigned,12,0}, 22); New_Parity = xfix( {xlUnsigned,1,0}, Data_In); case second Write_Parity = 1; if (count_vc <= 17136)% 17136 = 51 * 112 * 3 top_v = xfix( {xlUnsigned,12,0}, 2); else top_v = xfix( {xlUnsigned,12,0}, 11); end if (auxcount_vc == top_v) Data_Out_Enc_sc = xfix( {xlUnsigned,1,0}, Data_In); Write_Enable_sc = xfix( {xlUnsigned,1,0}, 1); if (count_vc < 36720) % = 7344 * 5; 5=720/144 média; Read_Fifo = xfix( {xlUnsigned,1,0}, 1); else Read_Fifo = xfix( {xlUnsigned,1,0}, 0); end auxcount_vc = 0; % conta até 3 ou até 12; else auxcount_vc = auxcount_vc + 1; Data_Out_Enc_sc = xfix( {xlUnsigned,1,0}, 0); Write_Enable_sc = xfix( {xlUnsigned,1,0}, 0);

Apêndice A 137

Read_Fifo = xfix( {xlUnsigned,1,0}, 0); end New_Parity = xfix({xlUnsigned,1,0},xl_xor(Parity,Data_In)); Parity_Addr_Write = xfix( {xlUnsigned,12,0}, parWrite); parWrite = Parity_Addr_Tabel; if (count_vc == 36720)% 36720 = 51*720 Parity_Addr = xfix( {xlUnsigned,12,0}, 0); AddrAddr = xfix( {xlUnsigned,16,0}, 0); count_vc = 0; state = third; else Parity_Addr = xfix( {xlUnsigned,12,0}, Parity_Addr_Tabel); count_vc = count_vc + 1; if (count_vc < 36720) AddrAddr = xfix( {xlUnsigned,16,0}, count_vc); else AddrAddr = xfix( {xlUnsigned,16,0}, 0); end end case third tmp = xfix( {xlUnsigned,1,0}, Parity); count_vc = xfix( {xlUnsigned,16,0}, 1); state = fourth; Read_Fifo = 0; Write_Enable_sc = xfix( {xlUnsigned,1,0}, 1); Write_Parity = 1; AddrAddr = 0; Data_Out_Enc_sc = xfix( {xlUnsigned,1,0}, Parity); Parity_Addr_Write = xfix( {xlUnsigned,12,0}, 0); Parity_Addr = xfix( {xlUnsigned,12,0}, 1); New_Parity = xfix( {xlUnsigned,1,0}, 0); case fourth %Habilita saída da paridade fazendo o xor acumulador tmp = xfix( {xlUnsigned,1,0}, xl_xor(Parity, tmp)); Data_Out_Enc_sc = xfix( {xlUnsigned,1,0}, tmp); Write_Enable_sc = xfix( {xlUnsigned,1,0}, 1); Parity_Addr_Write = xfix( {xlUnsigned,12,0}, count_vc); if (count_vc == 2447); Read_Fifo = xfix( {xlUnsigned,1,0}, 1); Parity_Addr = 0; state = first; else count_vc = count_vc + 1; Parity_Addr = xfix( {xlUnsigned,12,0}, count_vc); Read_Fifo = xfix( {xlUnsigned,1,0}, 0 ); end Write_Parity = 1; AddrAddr = 0; New_Parity = xfix( {xlUnsigned,1,0}, 0); otherwise

Apêndice A 138

Read_Fifo = 0; Write_Enable_sc = 0; Write_Parity = 0; AddrAddr = 0; Data_Out_Enc_sc = 0; Parity_Addr_Write = 0; Parity_Addr = 0; New_Parity = 0; end else Read_Fifo = 0; Write_Enable_sc = 0; Write_Parity = 0; AddrAddr = 0; Data_Out_Enc_sc = 0; Parity_Addr_Write = 0; Parity_Addr = 0; New_Parity = 0; end end’

Implementação de um Codificador LDPC para um Sistema de …

Documents

Transcript of Implementação de um Codificador LDPC para um Sistema de …