PROGRAMA DE PÓS GRADUAÇÃO EM ENGENHARIA · PDF fileTabela 7: Bits de...

UNIVERSIDADE FEDERAL DA BAHIA

ESCOLA POLITÉCNICA

PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA ELÉTRICA

Nelson Alves Ferreira Neto

DESENVOLVIMENTO E IMPLEMENTAÇÃO DE UMA ARQUITETURA DE

CODIFICADOR DE CANAL LDPC (LOW-DENSITY PARITY-CHECK CODES)

PARA O PADRÃO IEEE 802.22 WRAN (SUPER WI-FI) EM ASIC

Dissertação de Mestrado

Salvador – BA – Brasil Dezembro de 2015

UNIVERSIDADE FEDERAL DA BAHIA

ESCOLA POLITÉCNICA

PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA ELÉTRICA


DESENVOLVIMENTO E IMPLEMENTAÇÃO DE UMA ARQUITETURA DE

CODIFICADOR DE CANAL LDPC (LOW-DENSITY PARITY-CHECK CODES)

PARA O PADRÃO IEEE 802.22 WRAN (SUPER WI-FI) EM ASIC

Dissertação de Mestrado apresentada ao Programa de Pós-Graduação em Engenharia Elétrica (PPGEE), da Escola Politécnica da Universidade Federal da Bahia (UFBA), como parte dos requisitos necessários à obtenção do título de Mestre em Engenharia Elétrica.

Orientador: Wagner Luiz Alves de Oliveira

Salvador – BA – Brasil

Dezembro de 2015

ii

Ferreira Neto, Nelson Alves

Desenvolvimento e Implementação de uma Arquitetura de Codificador de Canal

LDPC (Low-Density Parity-Check Codes) para o Padrão IEEE 802.22 WRAN (Super Wi-Fi) em

ASIC / Nelson Alves Ferreira Neto. – Salvador: UFBA/PPGEE, 2015.

XXII, 83 p.: il; 29,7cm.

Orientador: Wagner Luiz Alves de Oliveira

Dissertação (mestrado) – UFBA/PPGEE/Programa de Pós-Graduação em Engenharia

Elétrica, 2015.

Referências Bibliográficas: p. 80 – 83

1. Codificação de Canal. 2. LDPC. 3. ASIC. 4. 802.22. 5. WRAN. I. Oliveira, Wagner Luiz Alves

de. II. Universidade Federal da Bahia, PPGEE, Programa de Pós-Graduação em Engenharia

Elétrica. III. Título.

iii

Desenvolvimento e Implementação de uma Arquitetura de Codificador de Canal LDPC

(Low-Density Parity-Check Codes) para o Padrão IEEE 802.22 WRAN (Super Wi-Fi) em ASIC.


Dissertação de Mestrado apresentada ao Programa de Pós-Graduação em Engenharia

Elétrica (PPGEE), da Escola Politécnica da Universidade Federal da Bahia (UFBA), como parte

dos requisitos necessários à obtenção do título de Mestre em Engenharia Elétrica.

Banca Examinadora:

Prof. Dr. Wagner Luiz Alves de Oliveira (Orientador)

Prof.ª Dr.ª Ana Isabela Araújo Cunha (Universidade Federal da Bahia)

Prof. Dr. Eduardo Furtado de Simas Filho (Universidade Federal da Bahia)

Prof. Dr. Elmar Uwe Kurt Melcher (Universidade Federal de Campina Grande)

Salvador – BA – Brasil Dezembro de 2015

v

Dedico este trabalho ao meu pai, Antonio Gilmar Cordeiro Ferreira, que se tornou o meu maior incentivador, e se ainda estivesse aqui, com certeza, estaria muito feliz por mais esse objetivo alcançado.

vii

AGRADECIMENTOS Agradeço a todos que, de alguma forma, direta ou indiretamente, passaram pela minha vida

e contribuíram para a construção de quem sou hoje.

Primeiramente, agradeço a minha mãe, Adelaide Maria de Andrade, que sempre me apoiou

em tudo, e a meu pai, Antonio Gilmar Cordeiro Ferreira, que se tornou o meu maior

incentivador, e se ainda estivesse aqui, com certeza, estaria muito feliz por mais esse

objetivo alcançado.

A minha filha, Náthalie Oliveira Alves, por ser a minha fonte de inspiração e a minha mulher,

Crisbel Hortênsia Cordeiro de Oliveira, companheira de todas as horas que sempre me

aconselhou a seguir em frente. Obrigado pelo companheirismo, carinho, força e, acima de

tudo, muito incentivo.

A meu irmão por estar sempre por perto e ser parceiro.

Ao meu orientador, Prof. Dr. Wagner Luiz Alves de Oliveira, por ter me guiado nessa jornada

em direção ao caminho do conhecimento e da microeletrônica.

A todos aqueles que sempre acreditaram em mim e desejam o meu sucesso. Muito

Obrigado!

ix

"A mente que se abre a uma nova ideia jamais voltará ao seu tamanho original"

(Albert Einstein)

xi

RESUMO

Este trabalho apresenta o desenvolvimento de duas arquiteturas seriais para codificadores LDPC (Low-Density Parity-Check Codes) destinados ao padrão IEEE 802.22 WRAN (Wireless Regional Area Network – Rede Regional Sem Fios), uma para ser usada em sistemas modelados em cascata e outra para ser usada como coprocessador em abordagem usando MCU (Microprogrammed Control Unit – Unidade de Controle Microprogramada) central. Esta última – arquitetura de coprocessador – foi desenvolvida como uma evolução da primeira arquitetura, a qual é completamente serial, acrescentando algumas otimizações. As arquiteturas propostas são capazes de operar em 84 combinações de configurações distintas, entre diferentes tamanhos de palavras de códigos e taxas de código, de acordo com o exigido pelo padrão, visando consumir menos área e potência frente a outras abordagens existentes. O trabalho foi desenvolvido seguindo o fluxo completo de um projeto de circuito integrado digital, desde a modelagem do sistema em alto nível, passando pela obtenção da arquitetura, implementação, verificação funcional, até a geração do GDSII. Na parte final do trabalho faz-se a comparação das arquiteturas propostas com outras implementações de codificadores LDPCs destinadas a outros padrões similares. Palavras chave: Codificação de Canal, LDPC, ASIC, 802.22, WRAN

xiii

ABSTRACT

This work presents the development of two serial architectures for LDPC (Low-Density Parity-Check Codes) encoders for the IEEE 802.22 WRAN (Wireless Regional Area Network) standard, one to be used in systems modeled as a cascading architecture and the other one for using as a coprocessor in an approach with a central MCU (Microprogrammed Control Unit). The coprocessor architecture has been developed as an evolution of the first architecture, which is completely serial, by adding some optimizations. The proposed architectures are capable of operating on 84 different combinations of settings, including different codeword sizes and code rates, according to the standard, aiming small area and low power compared to other existing approaches. The work has been developed following the full flow for a digital integrated circuit design, from high level system modeling, through architecture design, implementation, functional verification, until the GDSII generation. At the final part of the work is done a comparison between the proposed architectures and other implementations of LDPC encoders designed for similar approaches. Keywords: Channel Coding, LDPC, ASIC, 802.22, WRAN

xv

LISTA DE FIGURAS

Figura 1: Célula IEEE 802.22 WRAN com estação ERB e terminais de usuário. ......................... 4

Figura 2: Tipos de rede e características. ................................................................................... 5

Figura 3: Diagrama de processamento para transmissão e recepção. ...................................... 6

Figura 4: Matriz H definida por conjuntos de matrizes de permutação ou zeros Pi,j. ................ 8

Figura 5: Matriz Hb para taxa de código 1/2............................................................................... 8




Figura 9: Modelo de sistema de comunicação digital. ............................................................. 11

Figura 10: Grafo de Tanner para uma matriz H. ....................................................................... 15

Figura 11: Grafo de Tanner para código (2, 4)-regular. ............................................................ 16

Figura 12: Grafo de Tanner para código irregular. ................................................................... 16

Figura 13: Matriz base Hb para código LDPC Quase Cíclico. ..................................................... 18

Figura 14: Fluxo geral de projeto de circuito integrado digital dividido por fases. ................. 22

Figura 15: Projeto em nível de sistema. ................................................................................... 23

Figura 16: Projeto lógico. .......................................................................................................... 25

Figura 17: Projeto físico ou backend. ....................................................................................... 29

Figura 18: Floorplanning. .......................................................................................................... 29

xvi

Figura 19: Placement. ............................................................................................................... 30

Figura 20: Síntese de árvore de clock – CTS. ............................................................................ 30

Figura 21: Roteamento. ............................................................................................................ 31

Figura 22: Planta do circuito integrado definida no Floorplanning. ........................................ 33

Figura 23: Die sem células padrão e com Placement realizado. .............................................. 34

Figura 24: Layout do Placement. .............................................................................................. 35

Figura 25: Conexão de VDD e VSS. ........................................................................................... 36

Figura 26: Roteamento global. ................................................................................................. 37

Figura 27: Ambiente de verificação UVM. ................................................................................ 42

Figura 28: Comunicação entre monitor e collector. ................................................................. 46

Figura 29: UVC de interface típico. ........................................................................................... 47

Figura 30: Máquina de estados com o fluxo do processo de codificação LDPC. ..................... 51

Figura 31: Região útil da matriz Hb. ......................................................................................... 52

Figura 32: Diagrama de blocos da arquitetura serial. .............................................................. 53

Figura 33: Barrel-Shifter............................................................................................................ 54

Figura 34: Multiplexador. ......................................................................................................... 55

Figura 35: Diagrama de blocos da arquitetura coprocessador. ............................................... 57

Figura 36: Valores não nulos úteis da matriz Hb para taxa de código 1/2. .............................. 58

Figura 37: Conexão entre portas do driver e do sequencer. .................................................... 60

xvii

Figura 38: Driver seq_item_port conectado à porta seq_item_export do sequencer.............. 60

Figura 39: Ambiente de verificação para arquitetura serial. ................................................... 61

Figura 40: Comunicação entre monitor, collector e scoreboard. ............................................. 62

Figura 41: Monitor conectado à porta item_collected_export do scoreboard. ....................... 62

Figura 42: Ambiente de verificação para arquitetura coprocessador. .................................... 64

Figura 43: Sumário de verificação para arquitetura serial. ...................................................... 65

Figura 44: Sumário de verificação para arquitetura coprocessador. ....................................... 66

Figura 45: Layout físico da arquitetura coprocessador. ........................................................... 69

Figura 46: Layout físico da arquitetura serial com SRAM interna. ........................................... 70

xviii

LISTA DE TABELAS

Tabela 1: Tamanho de palavras de código e matrizes de permutação. ................................... 10

Tabela 2: Estimativa de recursos de hardware. ....................................................................... 55

Tabela 3: Endereço inicial de cada taxa de código ................................................................... 59

Tabela 4: Comparativo de resultados de síntese do codificador LDPC. ................................... 68

Tabela 5: Resultados de síntese do codificador LDPC coprocessador. .................................... 70

Tabela 6: Resultados de síntese do codificador LDPC serial com SRAM interna. .................... 70

Tabela 7: Bits de memória e portas NAND equivalentes por arquitetura ............................... 72

Tabela 8: Comparação dos resultados de síntese da arquitetura serial com SRAM interna. .. 74

Tabela 9: Comparação dos resultados de síntese do codificador LDPC coprocessador .......... 74

xx

LISTA DE SIGLAS

ALUT – Adaptive Look-Up Table (Bloco de Memória/Tabela de Pesquisa Adaptativa)

ASIC – Application-Specific Integrated Circuit (Circuito Integrado de Aplicação Específica)

AVM – Advanced Verification Methodology (Metodologia Avançada de Verificação)

AWGN – Additive White Gaussian Noise (Ruído Branco Aditivo e Gaussiano)

BPSK – Binary Phase-Shift Keying (Modulação por Deslocamento de Fase Binário)

CTS – Clock Tree Synthesis (Síntese de Árvore de Clock)

DEF – Design Exchange Format (Formato de Intercâmbio de Projetos)

DUT – Design Under Test (Projeto sob Teste) / Device Under Test (Dispositivo sob Teste)

DUV – Design Under Verification (Projeto sob Verificação)

ERB – Estação Rádio Base

eRM – e Reuse Methodology (Metodologia e de Reuso)

FFT – Fast Fourier Transform (Transformada Rápida de Fourier)

FPGA – Field-Programmable Gate Array (Arranjo de Portas Programável no Local)

GDSII – Graphic Database System II (Sistema de Banco de Dados Gráfico II)

HDL – Hardware Description Language (Linguagem de Descrição de Hardware)

IFFT – Inverse Fast Fourier Transform (Transformada Rápida de Fourier Inversa)

IP-Core – Intellectual Property Core (Módulo de Propriedade Intelectual)

LDPC – Low-Density Parity-Check Codes

LE – Logic Element (Elemento Lógico)

LEC – Logic Equivalence Checking (Verificação de Equivalência Lógica)

MCU – Microprogrammed Control Unit (Unidade de Controle Microprogramada)

xxi

OFDM – Orthogonal Frequency Division Multiplexing (Multiplexação por Divisão de

Frequências Ortogonais)

OFDMA – Orthogonal Frequency Division Multiple Access (Múltiplo Acesso por Divisão de

Frequências Ortogonais)

OVM – Open Verification Methodology (Metodologia de Verificação Aberta)

QAM – Quadrature Amplitude Modulation (Modulação de Amplitude em Quadratura)

QPSK – Quadrature Phase-Shift Keying (Modulação por Deslocamento de Fase em

Quadratura)

BPSK – Binary Phase-Shift Keying (Modulação por Deslocamento de Fase Binário)

IQ – In-phase and Quadrature (Em Fase e Quadratura)

RTL – Register-Transfer Level (Nível de Transferência entre Registradores)

SDC – Synopsys Design Constraints

SoC – System-on-Chip (Sistema-num-Chip)

STA – Static Timing Analysis (Análise Estática de Tempo)

TDD – Time Division Duplex (Duplexação por Divisão de Tempo)

TLM – Transaction-Level Modeling (Modelagem em Nível de Transações)

URM – Universal Reuse Methodology (Metodologia Universal de Reuso)

UVC – UVM Verification Component (Componente de Verificação da UVM)

UVM – Universal Verification Methodology (Metodologia de Verificação Universal)

VHDL – VHSIC Hardware Description Language (Linguagem de Descrição de Hardware

VHSIC)

VHSIC – Very High Speed Integrated Circuit (Circuito Integrado de Velocidade Muito Alta)

VMM – Verification Methodology Manual (Manual de Metodologia de Verificação)

WRAN – Wireless Regional Area Network (Rede Regional Sem Fios)

xxii

SUMÁRIO

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

2 IEEE 802.22 WRAN .............................................................................................................. 4

2.1 Estrutura das Matrizes de Verificação de Paridade ..................................................... 7

2.2 Redimensionamento de Valores em Hb ....................................................................... 9

3 Codificador de Canal LDPC ............................................................................................... 11

3.1 Codificação de Canal .................................................................................................. 11

3.2 Verificação de Paridade ............................................................................................. 12

3.3 Códigos LDPC ............................................................................................................. 14

3.4 Processo de Codificação LDPC ................................................................................... 16

3.5 O Algoritmo ................................................................................................................ 17

4 Fluxo de Projeto de Circuitos Integrados Digitais ............................................................ 21

4.1 Visão Geral do Fluxo de Projeto ................................................................................ 21

4.2 Projeto em nível de Sistema ...................................................................................... 23

4.2.1 Especificação ...................................................................................................... 23

4.2.2 Microarquitetura ................................................................................................ 24

4.3 Projeto Lógico ............................................................................................................ 25

4.3.1 RTL (Register-Transfer Level) .............................................................................. 25

4.3.2 Síntese Lógica ..................................................................................................... 26

4.3.3 Verificação Formal .............................................................................................. 27

4.4 Projeto Físico .............................................................................................................. 28

4.4.1 Floorplanning ...................................................................................................... 31

4.4.2 Placement ........................................................................................................... 33

4.4.3 Routing................................................................................................................ 36

xxiii

4.4.4 Scan-Reorder, CTS e Verificação Física ............................................................... 38

5 Universal Verification Methodology (UVM) ..................................................................... 40

5.1 A Biblioteca de Classes da UVM ................................................................................. 41

5.2 Bancos de Teste e Ambiente de Verificação em UVM .............................................. 41

5.2.1 UVC de Interface ................................................................................................. 43

5.2.2 Itens de Dados (Data Items) ............................................................................... 43

5.2.3 Direcionadores de Estímulos das Entradas (Drivers) .......................................... 44

5.2.4 Geradores de Estímulos (Sequencers e Sequences) ........................................... 44

5.2.5 Monitores (Monitors) ......................................................................................... 45

5.2.6 Coletores (Collectors) ......................................................................................... 45

5.2.7 Agentes (Agents) ................................................................................................ 46

5.2.8 Ambiente (Environment) .................................................................................... 46

6 Desenvolvimento do trabalho .......................................................................................... 48

6.1 Arquitetura ................................................................................................................. 50

6.1.1 Arquitetura Com SRAM Interna.......................................................................... 53

6.1.2 Arquitetura Coprocessador ................................................................................ 56

6.2 Verificação Funcional ................................................................................................. 59

7 Apresentação e análise de dados ..................................................................................... 67

8 Conclusões ........................................................................................................................ 74

9 Referências Bibliográficas ................................................................................................. 76

10 Anexos ........................................................................................................................... 80

10.1 Anexo A - Artigos Publicados ................................................................................. 80

1

1 INTRODUÇÃO

Em geral, a troca e o armazenamento de informações digitais estão sujeitos a perdas

e erros de conteúdo provocados pelos meios físicos utilizados. Nos sistemas digitais, desde o

armazenamento em memória até a comunicação sem fio, a exatidão das informações deve

ser garantida. Interferências nos meios físicos podem provocar alteração nos bits da

representação da informação, o que precisa ser detectado e corrigido.

A detecção e a correção de erros podem ser feitas através da inserção de

redundância, seja no processo de armazenamento de informação ou na transmissão da

mesma. Nos primeiros sistemas de comunicação digital acreditava-se que informações

poderiam ser transmitidas através um meio ruidoso, contornando os efeitos danosos do

canal sobre estas, apenas através do aumento da potência de transmissão. Essa visão foi

mudada fundamentalmente pelo trabalho de Shannon (1948) [1], o qual mostrou que

informações digitais poderiam ser transmitidas com relativa confiabilidade por um canal

ruidoso, por meio de codificação dos dados e adição prévia de código(s) de correção de

erro(s) (FEC – Forward Error Correction) no dispositivo transmissor, para posterior

decodificação no dispositivo receptor [2].

O processo de codificação de informação consiste em mapear um dado de K bits em

uma palavra de código de N bits. A taxa de codificação r = K / N indica a porção de dados

úteis contida na palavra de código. Mesmo que os bits na palavra de código sejam

parcialmente alterados, respeitando-se um dado limite, o algoritmo de decodificação será

capaz de recuperar a informação original sem prejuízo [2]. O processo é válido tanto para a

transmissão quanto para a recuperação de informações armazenadas.

Os padrões mais recentes de transmissão sem fio demandam uma alta taxa de

transferência de dados (throughput), o que exige bons algoritmos de codificação, detecção e

correção de erros, para evitar a retransmissão de dados corrompidos.

Códigos de verificação de paridade de baixa densidade e de correção antecipada de

erro LDPC (Low-Density Parity-Check) foram propostos por Gallager [3] em 1962, sendo

2

utilizados somente décadas depois por MacKay [4] e Wiberg [5]. Tais códigos estão entre os

melhores algoritmos de correção de erros conhecidos, os quais proveem excelente

desempenho de decodificação e alta taxa de tratamento de dados [6]. Esta categoria de

algoritmos permite operar próximo ao limite de Shannon [1], [6] e [7], razão pela qual tem

sido adotada por diversos padrões de comunicação recentes, tais como DVB-S2, 802.16e,

802.11n e 802.22 WRAN [8], [9] e [10].

Códigos LDPC são definidos por matrizes de verificação de paridade esparsas , as

quais podem ser representadas por um grafo de Tanner e usadas para decodificar as

informações recebidas por um canal. Porém, o processo de codificação direta é obtido

através da multiplicação da mensagem pela matriz geradora , a qual é obtida a partir de

e geralmente é densa, podendo tornar impraticável a implementação para códigos extensos

[11]. Entretanto, em [11] e [12] é proposta uma abordagem que permite realizar a

codificação usando a própria matriz . Felizmente, o código LDPC definido no padrão IEEE

802.22 WRAN (Wireless Regional Area Network) foi estruturado de maneira a poder tirar

proveito da modelagem baseada em blocos proposta em [11] e do algoritmo proposto em

[13], os quais permitem a implementação prática em hardware.

A flexibilidade imposta pelo padrão 802.22 ao LDPC exige que este possa operar em

21 tamanhos de palavra de código (situados na faixa de 384 a 2304) e quatro taxas de

codificação diferentes (1/2, 2/3, 3/4 e 5/6) [10], gerando uma quantidade de 84

configurações possíveis. Essa flexibilidade demanda o desenvolvimento de uma arquitetura

de hardware que possa operar de maneira eficiente, na taxa de dados exigida pelo padrão,

consumindo a pouca área e potência.

Neste trabalho foram desenvolvidas e implementadas duas arquiteturas flexíveis,

baseadas no algoritmo apresentado em [13], para o padrão IEEE 802.22 WRAN. Ambas as

soluções em hardware são compatíveis com as restrições definidas pelo padrão e podem

executar outros códigos sem a necessidade de serem sintetizados novamente, apenas

substituindo-se as memórias das matrizes .

A pesquisa aqui relatada foi desenvolvida em cinco etapas. A primeira correspondeu

à modelagem do sistema em C e MATLAB. Na segunda parte foi feita a descrição das

operações do circuito digital, em nível de transferência entre registradores (RTL – Register-

3

Transfer Level), através de linguagem de descrição de hardware (HDL – Hardware

Description Language). Em seguida foi feita a verificação funcional do RTL produzido. Na

quarta etapa o projeto passou por todo o fluxo para projetos de circuitos integrados digitais,

indo da síntese lógica ao arquivo GDSII (Graphic Database System II – Sistema de Banco de

Dados Gráfico II), na tecnologia VLSI 55 nm. E, por último, foi feita a comparação de

desempenho de potência e área, entre as arquiteturas propostas e as soluções

desenvolvidas para outros padrões similares.

Esta dissertação é organizada como segue: o segundo capítulo expõe uma visão geral

do padrão IEEE 802.22 WRAN e como são definidas as matrizes de verificação de paridade ,

assim como o processo de adequação a cada um dos tamanhos de palavras de código; o

terceiro capítulo introduz o tema de codificação de canal, apresenta o codificador LDPC, o

algoritmo proposto em [13] e mostra as alterações feitas para adequá-lo às nossas

arquiteturas; o quarto capítulo traz um estudo sobre o fluxo de projeto para circuitos

integrados digitais; o quinto capítulo introduz o framework UVM (Universal Verification

Methodology – Metodologia de Verificação Universal); o capítulo seis mostra as arquiteturas

desenvolvidas bem como a construção do ambiente de verificação e todo o

desenvolvimento relacionado; o sétimo capítulo apresenta e discute os resultados obtidos,

além de comparar as soluções deste trabalho com outras implementações; no oitavo

capítulo são expostas as conclusões; e finalmente, no nono capítulo, têm-se as referências

bibliográficas.

4

2 IEEE 802.22 WRAN

O padrão de rádio cognitivo IEEE 802.22 WRAN define o LDPC como um dos seus

possíveis codificadores de canal. Esse padrão é voltado para comunicação em zona de baixa

densidade populacional, tendo como aplicação típica o fornecimento de cobertura de banda

larga para áreas rurais e de difícil alcance por cabos. Suas células proveem um raio de

alcance médio de 30 km, podendo chegar a 100 km em condições específicas [10]. A Figura 1

mostra um exemplo de uma célula para o padrão IEEE 802.22 WRAN.

Figura 1: Célula IEEE 802.22 WRAN com estação ERB e terminais de usuário.

Este padrão foi desenvolvido para operar em uma topologia ponto-multiponto

(P2MP), sendo o sistema formado por uma estação rádio base (ERB) e terminais de usuários.

Nesse conjunto, cada terminal de usuário se liga à ERB através de um link sem fio, sendo tal

estação a responsável por controlar o acesso ao meio por parte dos respectivos terminais.

Rural

Vila

64-QAM

20 km

16-QAM

23 km

QPSK

30 km

5

Este tipo de rede se enquadra na categoria das RAN (Regional Area Network – Rede

Regional) ou WRAN. A Figura 2 mostra a distribuição dos tipos de rede de acordo com suas

características.

Figura 2: Tipos de rede e características.

O padrão 802.22 foi concebido para operar, de maneira não interferente, em faixas

de frequências destinadas à transmissão de TV analógica: 54 – 862 MHz, com canais de 6, 7

ou 8 MHz [14]. O 802.22 é o primeiro padrão de rádio cognitivo aprovado pelo IEEE. Uma das

características das suas células é a capacidade de executar sensoriamento cognitivo do

espectro, na faixa que está operando e em canais adjacentes. Para executar sensoriamento,

a ERB coordena os terminais de usuários, sincronizando-os quando podem transmitir e

quando devem apenas vasculhar os canais (para descobrir canal em uso por alguma TV).

Em nível de processamento banda-base, a camada física do padrão é baseada em

OFDM/OFDMA (Orthogonal Frequency Division Multiplexing/Multiple Access – Multiplexação

por Divisão de Frequências Ortogonais/Múltiplo Acesso), com largura de banda de canais de

IEEE 802.15

IEEE 802.11a

IEEE 802.11b/g/n

IEEE 802.16

IEEE 802.22

PAN

LAN

MA

RAN

Tipos de Rede

20-50m

10m

Até 100m

1-2km

30km

1 Mbps 10 Mbps

11-600 Mbps

54-280 Mbps

~22 Mbps

2,4 GHs

2,4 GHs

2,4-5

GHs

<60 GHs

54-862

MHs Frequência

6

6, 7 ou 8 MHz. No processamento para a transmissão, os dados são codificados através de

um codificador de canal LDPC e modulados digitalmente em QPSK (Quadrature Phase-Shift

Keying – Modulação por Deslocamento de Fase em Quadratura), 16-QAM (Quadrature

Amplitude Modulation – Modulação de Amplitude em Quadratura), 64-QAM ou BPSK (Binary

Phase-Shift Keying – Modulação por Deslocamento de Fase Binário), sendo os símbolos IQ

(In-phase and Quadrature – Em Fase e Quadratura) no domínio da frequência, resultantes

destas modulações, aplicados a uma IFFT (Inverse Fast Fourier Transform – Transformada

Rápida de Fourier Inversa) de 2048 pontos (subportadoras). Antes de serem transmitidos, os

símbolos IQ no domínio do tempo, resultantes da IFFT, são encapsulados em símbolos OFDM

que também englobam um prefixo cíclico de 1/4, 1/8, 1/16 ou 1/32 do tamanho da FFT (Fast

Fourier Transform – Transformada Rápida de Fourier). Para a recepção dos sinais, é feito o

processamento inverso. A comunicação é TDD (Time Division Duplex – Duplexação por

Divisão de Tempo). Um esboço do processamento de transmissão e recepção é mostrado na

Figura 3 [10].

Figura 3: Diagrama de processamento para transmissão e recepção.

Devido às características associadas à baixa densidade populacional e ao longo

alcance, as condições do canal podem variar significativamente, o que demanda uma alta

Codific

ação d

e C

anal

-scra

mble

r -e

ncoder

-punctu

rer

-bit in

terle

aver

Mapeam

ento

de

Conste

lação

Dig

ital

Alo

cação d

e

Subport

adora

Inserç

ão d

e

Pilo

to

IFF

T

Inserç

ão d

e P

refixo

Cíc

lico

Inserção de Preâmbulo

D/A

Decodific

ação d

e

Canal

Dete

cção d

e

Conste

lação

Dig

ital

Desalo

cação

de

Subport

adora

FF

T

A/D

Sin

cro

niz

ador

e

Rem

oção d

e

Pre

fixo C

íclic

o

Estim

ação d

e

Canal e

Equaliz

ação

Dado R

ecupera

do

D

ad

o B

iná

rio

Sin

al O

FD

M

Tra

nsm

itid

o

Sin

al O

FD

M

Recebid

o

7

flexibilidade do codificador para obter o melhor desempenho possível (isto é, a maior taxa

de dados), garantindo a redundância necessária para a recomposição da informação. Para

tanto, é usado um codificador de canal LDPC, que está entre os melhores algoritmos de

codificação e correção de erros conhecidos. Esta categoria de algoritmo permite operar

próximo ao limite de Shannon [7].

2.1 ESTRUTURA DAS MATRIZES DE VERIFICAÇÃO DE PARIDADE

Os códigos LDPCs são definidos através de matrizes de baixa densidade. Tais matrizes

podem ser usadas no cálculo das matrizes geradoras que permitem executar o processo de

codificação de forma direta ou, em alguns casos, serem usadas, as próprias, como base para

o algoritmo de codificação, dependendo da estrutura do código. No padrão 802.22, para

cada uma das taxas de código r = k/n (1/2, 2/3, 3/4 e 5/6), é definida uma matriz de

verificação de paridade de baixa densidade , de tamanho por , onde está associado

ao tamanho da palavra de código a ser transmitida, ao tamanho do vetor de verificação

de paridade e ao número de bits sistemáticos (mensagem a ser transmitida) [10].

As matrizes de verificação de paridade são estruturadas a partir de arranjos de

blocos lineares , conforme a Figura 4, sendo tais blocos matrizes de permutação ou

matriz nula de tamanho x . As matrizes são definidas através de matrizes base , de

tamanho x . As Figuras 5 a 8 mostram as matrizes definidas pelo padrão IEEEE

802.22 WRAN. Tais matrizes podem ser expandidas através da substituição de cada

elemento seu por uma matriz nula ou de permutação, onde e . O

processo de conversão da matriz em uma matriz é feito substituindo-se cada elemento

em por uma matriz quadrada de tamanho x . Quando o elemento na matriz base é

o valor , deverá ser uma matriz nula; nos demais casos, o valor do elemento

determinará que seja uma matriz identidade deslocada circularmente para direita por

tal valor [10].

8

[

]

Figura 4: Matriz H definida por conjuntos de matrizes de permutação ou zeros Pi,j.

Figura 5: Matriz Hb para taxa de código 1/2.



–1 94 73 –1 –1 –1 –1 –1 55 83 –1 –1 7 0 –1 –1 –1 –1 –1 –1 –1 –1 –1 –1

–1 27 –1 –1 –1 22 79 9 –1 –1 –1 12 –1 0 0 –1 –1 –1 –1 –1 –1 –1 –1 –1

–1 –1 –1 24 22 81 –1 33 –1 –1 –1 0 –1 –1 0 0 –1 –1 –1 –1 –1 –1 –1 –1

61 –1 47 –1 –1 –1 –1 –1 65 25 –1 –1 –1 –1 –1 0 0 –1 –1 –1 –1 –1 –1 –1

–1 –1 39 –1 –1 –1 84 –1 –1 41 72 –1 –1 –1 –1 –1 0 0 –1 –1 –1 –1 –1 –1

–1 –1 –1 –1 46 40 –1 82 –1 –1 –1 79 0 –1 –1 –1 –1 0 0 –1 –1 –1 –1 –1

–1 –1 95 53 –1 –1 –1 –1 –1 14 18 –1 –1 –1 –1 –1 –1 –1 0 0 –1 –1 –1 –1

–1 11 73 –1 –1 –1 2 –1 –1 47 –1 –1 –1 –1 –1 –1 –1 –1 –1 0 0 –1 –1 –1

12 –1 –1 –1 83 24 –1 43 –1 –1 –1 51 –1 –1 –1 –1 –1 –1 –1 –1 0 0 –1 –1

–1 –1 –1 –1 –1 94 –1 59 –1 –1 70 72 –1 –1 –1 –1 –1 –1 –1 –1 –1 0 0 –1

–1 –1 7 65 –1 –1 –1 –1 39 49 –1 –1 –1 –1 –1 –1 –1 –1 –1 –1 –1 –1 0 0

43 –1 –1 –1 –1 66 –1 41 –1 –1 –1 26 7 –1 –1 –1 –1 –1 –1 –1 –1 –1 –1 0

H b1H b2

2 –1 19 –1 47 –1 48 –1 36 –1 82 –1 47 –1 15 –1 95 0 –1 –1 –1 –1 –1 –1

–1 69 –1 88 –1 33 –1 3 –1 16 –1 37 –1 40 –1 48 –1 0 0 –1 –1 –1 –1 –1

10 –1 86 –1 62 –1 28 –1 85 –1 16 –1 34 –1 73 –1 –1 –1 0 0 –1 –1 –1 –1

–1 28 –1 32 –1 81 –1 27 –1 88 –1 5 –1 56 –1 37 –1 –1 –1 0 0 –1 –1 –1

23 –1 29 –1 15 –1 30 –1 66 –1 24 –1 50 –1 62 –1 –1 –1 –1 –1 0 0 –1 –1

–1 30 –1 65 –1 54 –1 14 –1 0 –1 30 –1 74 –1 0 –1 –1 –1 –1 –1 0 0 –1

32 –1 0 –1 15 –1 56 –1 85 –1 5 –1 6 –1 52 –1 0 –1 –1 –1 –1 –1 0 0

–1 0 –1 47 –1 13 –1 61 –1 84 –1 55 –1 78 –1 41 95 –1 –1 –1 –1 –1 –1 0

H b2 H b1

6 38 3 93 –1 –1 –1 30 70 –1 86 –1 37 38 4 11 –1 46 48 0 –1 –1 –1 –1

62 94 19 84 –1 92 78 –1 15 –1 –1 92 –1 45 24 32 30 –1 –1 0 0 –1 –1 –1

71 –1 55 –1 12 66 45 79 –1 78 –1 –1 10 –1 22 55 70 82 –1 –1 0 0 –1 –1

38 61 –1 66 9 73 47 64 –1 39 61 43 –1 –1 –1 –1 95 32 0 –1 –1 0 0 –1

–1 –1 –1 –1 32 52 55 80 95 22 6 51 24 90 44 20 –1 –1 –1 –1 –1 –1 0 0

–1 63 31 88 20 –1 –1 –1 6 40 56 16 71 53 –1 –1 27 26 48 –1 –1 –1 –1 0

H b2 H b1

9


2.2 REDIMENSIONAMENTO DE VALORES EM HB

O padrão permite operar com 21 diferentes tamanhos de palavras de código.

Entretanto, todos os valores de deslocamento, definidos nas matrizes base do padrão IEEE

802.22 (Figuras 5 a 8), são determinados tendo como parâmetro o tamanho máximo de

matriz ( ) para uma palavra de código de tamanho , ,

. Assim, faz-se necessário equacionar a diferença entre os valores de

deslocamento fixados nas matrizes base e o tamanho das submatrizes de permutação .

Portanto, os tamanhos dos deslocamentos para menor que 96 – novos valores dos

elementos de , devem ser calculados aplicando a equação (1), sendo ⌊ ⌋ a operação floor

(arredondamento na direção de -∞). A Tabela 1 define os tamanhos de palavras de código ,

em bits, relativos ao tamanho das matrizes de permutação , sendo o tamanho, em

bytes, da informação de acordo com taxa de código escolhida.

{

⌊

⌋

(1)

1 25 55 –1 47 4 –1 91 84 8 86 52 82 33 5 0 36 20 4 77 80 0 –1 –1

–1 6 –1 36 40 47 12 79 47 –1 41 21 12 71 14 72 0 44 49 0 0 0 0 –1

51 81 83 4 67 –1 21 –1 31 24 91 61 81 9 86 78 60 88 67 15 –1 –1 0 0

50 –1 50 15 –1 36 13 10 11 20 53 90 29 92 57 30 84 92 11 66 80 –1 –1 0

H b2 H b1

10

Tabela 1: Tamanho de palavras de código e matrizes de permutação.

r =1/2 r =1/2 r =3/4 r =5/6 r =1/2 r =1/2 r =3/4 r =5/6

384 16 24 24 36 40 1440 60 90 120 135 150

480 20 30 30 45 50 1536 64 96 128 144 160

576 24 36 36 54 60 1632 68 102 136 153 170

672 28 42 42 63 70 1728 72 108 144 162 180

768 32 48 48 72 80 1824 76 114 152 171 190

864 36 54 72 81 90 1920 80 120 160 180 200

960 40 60 80 90 100 2016 84 126 168 189 210

1056 44 66 88 99 110 2112 88 132 176 198 220

1152 48 72 96 108 120 2208 92 138 184 207 230

1248 52 78 104 117 130 2304 96 144 192 216 240

1344 56 84 112 126 140

znk

n zk

11

3 CODIFICADOR DE CANAL LDPC

Os códigos de verificação de paridade de baixa densidade LDPC constituem uma

classe de códigos de correção de erro, proposta por Gallager em 1962 [3]. Neste capítulo

serão vistos os aspectos principais do processo de codificação LDPC, assim como do

algoritmo utilizado como base na execução deste trabalho.

3.1 CODIFICAÇÃO DE CANAL

O primeiro sistema de comunicação digital foi construído por volta de 1940 [2]. Até

então, acreditava-se que a única maneira para se transmitir informação através de um canal

de comunicação ruidoso era aumentando a potência do sinal, de modo a garantir uma

relação sinal-ruído suficientemente elevada [2]. No entanto, Shannon, em seu trabalho

publicado em 1948 [1], mostrou que é possível transmitir dados digitais com elevada

confiabilidade através de um canal ruidoso por meio da inserção de informações

redundantes – codificação prévia de informações com códigos de correção de erro, antes da

transmissão, para posterior decodificação dessas informações codificadas. Esse processo de

codificação de canal visa garantir que as informações sejam transmitidas através de meio

ruidoso e, posteriormente, possam ser reconstituídas – códigos detectores e corretores de

erro permitem a detecção e correção dos erros introduzidos, pelo canal de comunicação, na

informação, entre a transmissão e a recepção [15]. A Figura 9 mostra um modelo de sistema

de comunicação digital.

Figura 9: Modelo de sistema de comunicação digital.

Codificação de Canal

Modulador

Demodulador Decodificação

de Canal

Informação Original

Informação Recebida

12

Um canal pode apresentar uma série de imperfeições, tais como ruídos, distorções,

interferências e desvanecimentos, dentre outras, que dificultam a correta interpretação e

reprodução das informações transmitidas. Para ser possível detectar e corrigir erros, são

adicionados bits redundantes à informação. Do lado do transmissor, as informações digitais,

contendo bits, são codificadas em palavras de código com bits. Os dados extras são

usados para verificar a consistência das informações que chegam ao receptor, para

determinar se estas foram corrompidas ou não e, em caso de corrompimento, permitir

restaurar a informação original. A relação entre o tamanho da mensagem, , e o tamanho

da palavra de código , , é denominada taxa de código [2] ou taxa de informação

[15], representando o total de informação utilizável dentro da palavra de código transmitida.

3.2 VERIFICAÇÃO DE PARIDADE

A ideia central por trás do código de correção de erro é conseguir aumentar a

quantidade de informação que pode ser transmitida através de um canal ruidoso. Para tal, é

feito o cálculo e a introdução de dados extras (as chamadas paridades), para serem

transmitidos junto à informação desejada (a mensagem). O conjunto mensagem mais

paridade forma a denominada palavra de código (codeword).

Considerando a informação binária e a palavra de código

, composta pela informação e o bit de paridade, é possível validar se a

palavra de código recebida está correta usando o vetor de verificação de paridade

, desde que se satisfaça a equação no campo de Galois GF(2),

conforme equação (2).

[

]

(2)

13

Entretanto, com a inserção de um bit de paridade, é possível detectar-se apenas um

número par de erros ocorrido na palavra transmitida, não sendo possível indicar ou corrigir

os bits modificados. Para detectar mais de um erro, é necessário aumentar a redundância

inserida na palavra de código, sendo que tal redundância deve obedecer a várias equações

de paridade, as quais são definidas por uma matriz de verificação de paridade.

Dadas uma palavra de código e a matriz de verificação

de paridade sendo a equação (3), todas as equações definidas por devem

ser satisfeitas pela palavra de código, conforme equação (4).

[

] (3)

[

]

[

]

[ ] {

(4)

Cada linha da matriz de verificação de paridade corresponde a uma equação de

verificação de paridade, enquanto que cada coluna relaciona-se a um bit da palavra de

código. Quando um elemento da matriz é ‘1’, o correspondente bit da palavra de código

é incluído na equação de paridade. Sendo assim, para um código com equações de

paridade e uma palavra de código de tamanho , tem-se uma matriz de verificação de

paridade, que descreve tal código, de tamanho x . Duas ou mais matrizes de paridade

podem descrever o mesmo código, desde que satisfaçam , onde é um vetor

coluna de tamanho , conforme pode ser visto em [2] e [16].

14

3.3 CÓDIGOS LDPC

Os códigos LDPC são códigos de blocos definidos por matrizes esparsas – matrizes de

verificação de paridade com um número reduzido de elementos não nulos. O fato das

matrizes serem esparsas permite que o processo de decodificação tenha complexidade

com crescimento linear [2]. Os códigos de blocos binários podem ser definidos como um

código que, a partir de uma palavra de informação , contendo bits, produza uma palavra

de código com bits. Para um dado existe mensagens possíveis, assim como

palavras de código de tamanho . Nesse processo de codificação, a palavra de código com

bits é sempre maior que a palavra de bits sistemática (mensagem) de tamanho [17].

Os códigos LDPC podem ser classificados como regulares ou irregulares. Quando são

regulares, as matrizes esparsas que os representam têm um número fixo de elementos não

nulos por coluna, , e linha, , , ou em outras palavras, cada bit da

palavra de código participa em um número fixo de equações de verificação de paridade ,

e cada equação faz uso de um número fixo de bits de código [2]. A equação (5) mostra

um exemplo de matriz para um código . Por outro lado quando os

códigos são irregulares, não há valores fixos que descrevam a quantas equações um

bit da palavra de código possa participar ou vice-versa – matrizes que representam tais

códigos não tem número fixo de elementos não nulos em linha e colunas (eles obedecem a

alguma distribuição [16]). A equação (6) mostra um exemplo de matriz para um código

irregular.

[

] (5)

[

] (6)

15

As matrizes de verificação de paridade que definem um código LDPC também podem

ser representadas por grafos de Tanner ou grafos bipartidos. Os grafos de Tanner são

compostos por dois conjuntos de nós: os nós de bits (ou variáveis), e os nós de paridade (ou

de verificação). Considerando uma matriz de tamanho x , há em um grafo bipartido

com nós de variáveis (correspondentes aos bits da palavra de código ) e (ou ) nós

de verificação (correspondentes às equações de paridade [16]). Dado uma matriz , o nó de

verificação irá se ligar ao nó de variável se o elemento não for nulo ( indica

que o nó de variável participa da equação ) – sendo assim, o número de arestas em um

grafo de Tanner é igual ao número de elementos ‘1’ em uma matriz de verificação de

paridade . A Figura 10 mostra um exemplo de grafo de Tanner para uma dada matriz .

Figura 10: Grafo de Tanner para uma matriz H.

Ainda sobre representação usando grafos, é possível notar que, para um dado código

, cada nó de bit terá “grau” e cada nó de verificação terá “grau” . A

Figura 11 mostra um exemplo de grafo de Tanner com grau 2 para nós de bit e grau 4 para

nós de verificação. Esse grafo representa o código definido pela matriz

na equação (5). Por outro lado, na Figura 12 temos um grafo que representa o código

irregular definido pela equação (6). Nesse grafo temos, por exemplo, o primeiro nó de bit

com grau 2, o segundo com grau 1 e o sexto com grau 3; também temos nós de verificação

com graus 5 e 3. O comportamento dos códigos LDPC pode ser melhorado quando estes

possuem nós com graus variados, obedecendo a alguma forma de distribuição [15].

Matriz de verificação de Paridade H

Nós de verificação ou paridade i

Nós de bit ou variável j

Grafo de Tanner

16

Figura 11: Grafo de Tanner para código (2, 4)-regular.

Figura 12: Grafo de Tanner para código irregular.

3.4 PROCESSO DE CODIFICAÇÃO LDPC

Uma matriz de verificação de paridade pode ser usada para definir um código

LDPC, ou seja, um conjunto de palavras de código válidas. Entretanto, no processo de

codificação é necessário gerar as palavras de código contendo mensagem e redundância. O

processo de codificação consiste em gerar um vetor contendo a palavra de código , a partir

de um vetor mensagem , onde . Nesse contexto, é uma palavra binária

contendo bits, é a palavra codificada resultante, com bits, e H é uma matriz de

verificação de paridade para um determinado código LDPC, sendo o seu tamanho x .

Na equação (4) foi mostrado um exemplo onde, partindo de uma palavra de código ,

é possível verificar se ela satisfaz a igualdade . Para proceder com a codificação é

17

necessário fazer o caminho inverso. É preciso, a partir dos bits da mensagem

que se quer transmitir, poder gerar os bits de paridade que

se somam aos bits de informação para compor a palavra de código , conforme

descrito pela equação (7).

{

{

(7)

As equações mostradas em (7) podem ser organizadas em uma matriz geradora ,

conforme equação (8). Sendo assim, é possível realizar a codificação LDPC usando a matriz

de tamanho x , onde e . No entanto, esse método pode se tornar

impraticável devido ao fato de normalmente ser uma matriz densa, fazendo com que o

codificador tenha complexidade , sendo o número de bits da palavra de código [2]

[18].

[ ]

3.5 O ALGORITMO

Para contornar o problema da codificação, ao invés de converter matrizes de

verificação de paridade em uma matriz geradora , as matrizes , de um código LDPC,

podem ser planejadas para permitir executar a codificação a partir delas próprias [2] – esse

(8)

18

tipo de código é chamado de LDPC Quase Cíclico. As matrizes de código definidas pelo

padrão IEEE 802.22 WRAN são desse tipo [10].

Tal como em [11] e [13], as matrizes para os códigos LDPC Quase Cíclicos do padrão

[10] são construídas por matrizes de permutação (matrizes identidade circularmente

deslocadas) ou matrizes nulas. A Figura 13 mostra um exemplo de matriz base para

código LDPC Quase Cíclico. Nela, os valores representam submatrizes (permutação ou

nula) de tamanho x .

[

]

Figura 13: Matriz base Hb para código LDPC Quase Cíclico.

Como pode ser observado nas Figuras 5 a 8, a estrutura das matrizes de verificação

de paridade, definida por matriz base , é dividida em duas seções, e , onde a

primeira coluna de , em tom de cinza mais escuro, contém apenas três matrizes de

permutação não nulas ( ,

e , com ), e a parte em cinza

claro é uma matriz diagonal dupla, cujo valor de cada elemento é ‘1’ para e ,

sendo e linhas e colunas, respectivamente. Essa peculiaridade das matrizes do padrão

IEEE 802.22 WRAN permite a aplicação do algoritmo de codificação de forma eficiente.

Considere a palavra de código como a concatenação dos vetores

mensagem e paridade , onde tem tamanho k e tem tamanho m (o vetor é gerado

pelo processo de codificação). Se for considerado o vetor subdividido em sequências

menores de tamanho z, , e for satisfeita a

igualdade , , equação (9), pode-se inferir as equações (10), (11), (12) e

(13).

19

[

]

[

]

(9)

∑

(10)

∑ (11)

∑ (12)

∑

(13)

Somando todas as equações de (10) a (13) em GF(2), obtém-se (14), que é usada para

encontrar . Se utilizarmos a definição da equação (15), é possível reescrever (14), (10),

(11), (12) e (13), como (16), (17), (18), (19) e (20), respectivamente, para se obter o vetor de

paridades.

∑ ∑

(14)

∑ (15)

∑ (16)

(17)

(18)

(19)

20

(20)

Note que a operação pode ser implementada como um deslocamento circular

para a esquerda sobre o vetor , , onde o elemento da matriz

define o valor do deslocamento. Considerando sempre que (matriz

zero), é possível generalizar as equações (18) e (19) em (21).

(21)

A chave para implementação de uma arquitetura de hardware que realize esse

algoritmo é manipular essas equações, de modo a rearranjá-las da maneira que mais

convém à arquitetura desejada.

21

4 FLUXO DE PROJETO DE CIRCUITOS INTEGRADOS DIGITAIS

Este capítulo descreve as etapas envolvidas no projeto de um circuito integrado

digital. Tal fluxo de projeto se divide em etapas de implementação (transformação em

diferentes formas de representação do circuito) e etapas de verificação (necessárias para

atestar o atendimento às especificações iniciais e a qualidade das transformações durante o

fluxo de implementação).

De modo geral, as etapas normalmente executadas no fluxo de projeto de um

circuito integrado digital são:

Especificação;

Descrição do hardware em RTL (Register-Transfer Level – Nível de Transferência entre

Registradores);

Síntese Lógica;

Verificação Funcional;

Foorplanning;

Placement;

Scan-Reorder;

CTS (Clock Tree Synthesis – Síntese de Árvore de Clock);

Roteamento;

Verificação Física;

Extração de Parasitas;

STA (Static Timing Analysis - Análise Estática de Tempo); e

Geração do arquivo de layout GDSII.

4.1 VISÃO GERAL DO FLUXO DE PROJETO

O fluxo de projeto de circuito integrado digital pode ser dividido em projeto físico,

projeto lógico e projeto em nível de sistema, sendo que em cada uma destas fases são

realizados os processos de implementação e verificação. Além disso, também há a divisão

22

clássica em dois grandes blocos de atividade: o frontend, que envolve toda a parte de

projeto lógico e de sistema, juntamente com a respectiva verificação; e o backend, que

corresponde à fase de implementação física [20] [21]. A Figura 14 mostra o fluxograma com

as subdivisões e fases de projeto para circuitos integrados digitais.

Figura 14: Fluxo geral de projeto de circuito integrado digital dividido por fases.

Projeto RTL

Síntese Lógica

Floorplanning

Placement

Scan Reorder CTS

Roteamento

GDSII Verificação Física (DRC e LVS)

Verificação Funcional



Verificação F

o

r

m

a

l RC

Extraction STA

Netlist DEF

Microarquitetura

Especificação

Simulação de Sistema

Simulação de Sistema

Projeto Físico

Projeto de Sistema

Projeto Lógico

Fron

tend

B

acken

d

23

4.2 PROJETO EM NÍVEL DE SISTEMA

Na fase de projeto em nível de sistema são determinados quais componentes de

hardware/software devem compor o CI, de forma que ele execute corretamente a função à

qual é destinado, consumindo a menor potência, área, tempo de execução e tempo de

projeto possível [20]. A fase de projeto em nível de sistema pode ser dividida basicamente

em especificação e microarquitetura, conforme Figura 15.

Figura 15: Projeto em nível de sistema.

4.2.1 Especificação

Em cada uma das etapas envolvidas no fluxo de projeto há um conjunto de artefatos

(documentos e/ou arquivos), os quais são usados como entrada ou podem ser gerados como

saída da etapa.

O ponto de partida para execução do fluxo é a especificação do sistema [19]. A

especificação do sistema pode ser composta por vários tipos de documentos, tais como

textos descritivos, gráficos, componentes de software (modelos em SystemVerilog, MATLAB,

C, C++, SystemC, etc.) e conjunto de normas que definam um novo padrão [20]. Na

especificação estão contidos os requisitos funcionais e não funcionais a serem satisfeitos,

tais como velocidade, memória, potência máxima consumida e tamanho máximo do die

(pastilha de silício onde o CI é fabricado), dentre outros. A especificação define o que deve

ser realizado pelo circuito integrado (processamento de banda base para um padrão de

Microarquitetura

Especificação

Simulação do Sistema

Simulação do Sistema

24

comunicação sem fio; codificação ou decodificação de áudio, vídeo ou algum tipo de

informação). Além disso, pode definir quais algoritmos podem ou devem ser usados.

Também na etapa de especificação do sistema podem ser realizadas simulações em

alto nível, para testar e validar os algoritmos envolvidos no processamento da informação.

4.2.2 Microarquitetura

A microarquitetura é responsável por definir como o RTL será desenvolvido. Ela parte

da extração de requisitos do projeto da especificação do sistema, entregando documentos

com textos e gráficos descritivos, os quais definem a arquitetura interna e interfaceamento

dos módulos de hardware.

Junto a textos e gráficos, também pode haver componentes de software que auxiliem

na definição da arquitetura [20]. Para cada bloco é definida uma microarquitetura, na qual

pode haver uma subdivisão em novos blocos que, por conseguinte, terão sua

microarquitetura detalhada. Nessa microarquitetura incluem-se dados como tamanhos de

barramentos, quantidade de bits em interfaces de controle, latência, paralelismos, pipelines,

tamanho exato de memórias, dentre outras características que orientarão a implementação

de tais blocos.

Enquanto na etapa de especificação os componentes de software são em alto nível,

na microarquitetura os componentes de software desenvolvidos funcionam como uma

espécie de simulação da arquitetura planejada. Em caso de filtros digitais, por exemplo, eles

são construídos considerando o tamanho das palavras, em ponto fixo ou ponto flutuante,

saturação ou estouro de resultado de operação, dentre outro fatores. Em muitos casos

esses componentes de software são usados como modelo de referência para a verificação

funcional do hardware.

25

4.3 PROJETO LÓGICO

O projeto lógico é composto por elaboração de RTL, verificação funcional e síntese

lógica. A etapa de verificação funcional, juntamente com a metodologia UVM, será descrita

em detalhes no capítulo 5.

Normalmente inclui-se no projeto lógico a primeira execução de verificação formal

ou de equivalência lógica LEC (Logic Equivalence Checking – Verificação de Equivalência

Lógica). Esse processo verifica se a netlist sintetizada é logicamente equivalente ao RTL

usado como entrada para a síntese [19]. O processo de verificação formal de equivalência

lógica pode e deve ser executado nas demais etapas que alteram a netlist.

Figura 16: Projeto lógico.

4.3.1 RTL (Register-Transfer Level)

O projeto do RTL consiste basicamente em transcrever a microarquitetura, escrita em

linguagem natural e diagrama de blocos, para uma HDL, de modo que a síntese lógica possa

ser executada.

A descrição em nível de transferência entre registradores (flip-flops) – RTL –

representa um nível de abstração abaixo da descrição comportamental do circuito e acima

da descrição presente em uma netlist em nível de portas lógicas. Entre os registradores, os

sinais ou dados são transferidos através de fios e lógicas combinacionais. Geralmente, o RTL

é escrito em alguma linguagem de descrição de hardware HDL (Hardware Description

Language – Linguagem de Descrição de Hardware), tal como Verilog, SystemVerilog, Chisel

Projeto RTL

Síntese Lógica Verificação Funcional


Verificação Formal

26

ou VHDL (VHSIC Hardware Description Language – Linguagem de Descrição de Hardware

VHSIC), onde VHSIC quer dizer Very High Speed Integrated Circuit (Circuito Integrado de

Velocidade Muito Alta). As linguagens de descrição de hardwares mais usadas na construção

do RTL são Verilog e VHDL [22].

Um RTL bem desenvolvido facilita as etapas subsequentes do fluxo de projeto de

circuitos integrados digitais e permite acelerar o processo de construção do CI [22].

Dependendo do nível de documentação desejada e da complexidade do bloco em questão,

em alguns casos a microarquitetura e projeto de RTL podem ser realizados como uma única

atividade. Em todo caso, essa prática não é recomendada.

4.3.2 Síntese Lógica

As raízes da síntese lógica estão ligadas aos trabalhos do matemático George Boole

(1815-1865), no que hoje é chamado de álgebra booleana, e à descoberta de Shannon em

1938, mostrando que a álgebra booleana de dois valores pode descrever o funcionamento

de circuitos de comutação [21]. Nas últimas décadas houve muito progresso nesse campo, o

que tem proporcionado significativo impulso na produtividade de projeto de circuitos

integrados digitais. A capacidade de descrever e especificar projetos em níveis de abstração

mais altos tem permitido, aos times de projetistas, a utilização de um grande número de

transistores nos circuitos digitais atuais [21].

A síntese lógica é o processo pelo qual um circuito digital, descrito em um nível de

abstração alto (geralmente RTL), é convertido em uma netlist que descreve todos os

elementos combinacionais (portas lógicas simples e agregadas), sequenciais (flip-flops) e de

interconexão (fios) que representam logicamente o circuito desejado. Esse processo

costuma ser feito por ferramentas computacionais de síntese, as quais são capazes tanto de

gerar fluxos binários para configuração de dispositivos lógicos tais como FPGAs (Field-

Programmable Gate Array – Arranjo de Portas Programáveis no Local), quanto de gerar

netlists para criação de ASICs (Application-Specific Integrated Circuit – Circuito Integrado de

Aplicação Específica).

27

As ferramentas de síntese lógica assemelham-se a compiladores voltados para

componentes de hardware, capazes de mapear um código HDL para uma dada biblioteca de

células padrão, objetivando minimizar a área e potência consumida, assim como atender às

restrições de temporização. A síntese lógica produz circuitos que não são necessariamente

mais eficientes do que um projetado à mão, por um ser humano qualificado. Entretanto, ela

consegue lidar com uma quantidade de transistores que seria impraticável para uma pessoa

e, além do mais, os sintetizadores atuais são capazes de gerar netlists eficazes para a grande

maioria dos ASICs [19], em janelas de tempo muito mais curtas, o que favorece o

atendimento às restrições de custo de projeto e de disponibilização do produto no mercado

em janelas de tempo viáveis – o chamado time-to-market.

A etapa de síntese lógica recebe como entrada o RTL descrito em alguma HDL, os

arquivos com a descrição das temporizações das células padrão (formato Liberty – *.lib) e as

restrições de desempenho (área, consumo e tempo). Esse processo pode ser otimizado para

alcançar o menor consumo de energia, a menor área ou a maior velocidade. O resultado

desse processo tem como saída uma netlist em nível de portas lógicas e flip-flops disponíveis

na biblioteca adotada de células padrão.

As regras que definem como o circuito deve se comportar em relação à frequência de

operação e outras restrições do projeto físico são descritas no formato SDC (Synopsys Design

Constraints). Tais restrições permitem controlar atrasos de entradas e saídas, cargas nas

saídas, indicar se uma parte do circuito deve ter mais de ciclo de relógio para realizar suas

operações combinacionais, indicar tempos de transição de algum sinal, indicar caminhos

falsos de análise de tempo, dentre outras características.

4.3.3 Verificação Formal

Algumas vezes, devido a ambiguidades no RTL, o processo de síntese gera uma netlist

incorreta, a qual não condiz logicamente com a descrição funcional presente no RTL.

Idealmente isso não deve acontecer mas, caso aconteça, essa situação precisa ser detectada

e corrigida. Para tanto, pode-se refazer o processo de verificação funcional inicialmente

aplicado ao RTL, com a netlist gerada pela síntese, que descreve o circuito em nível de portas

28

lógicas e flip-flops [19]. Apesar desse processo alcançar resultados satisfatórios, geralmente

ele é desencorajado porque, dependendo da quantidade de testes realizados, o enorme

tempo requerido pode torná-lo impraticável.

A verificação formal de equivalência lógica consiste numa outra abordagem de

verificação e validação da netlist gerada pela síntese lógica, a qual busca atestar (ou não) a

equivalência lógica entre tal netlist e a descrição RTL usada como entrada no processo de

síntese lógica. Tal abordagem é capaz de provar matematicamente que ambas as descrições,

RTL e netlist em nível de portas lógicas, têm exatamente as mesmas funções booleanas [19].

Em outras palavras, a verificação formal de equivalência lógica é responsável por

comparar dois modelos e apontar se eles são equivalentes. Este procedimento serve tanto

para apontar se houve erros na síntese do RTL em netlist, quanto para apontar se, em

alguma das etapas intermediárias de projeto de CI, a netlist de saída não mais condiz com a

netlist de entrada [20].

4.4 PROJETO FÍSICO

O projeto físico ou backend consiste na fase do fluxo de projeto seguinte ao frontend

(projeto lógico). Esta fase engloba as etapas de Floorplanning, Placement, reordenamento de

cadeias de escaneamento (Scan-Reorder), síntese de árvore de clock (CTS) e roteamento

(Routing). Além dessas etapas, para garantir o correto funcionamento do CI, são executadas

um conjunto de verificações físicas, envolvendo as regras de projeto (DRC) e a disposição dos

elementos no circuito (LVS). Ainda seguindo com verificações físicas, é feito o cálculo das

resistências e capacitâncias parasitas existentes no circuito (RC Extraction), para alimentar a

base de dados utilizada nos cálculos de atrasos e tempo de propagação de sinais, necessária

à análise estática de tempo (STA) [21].

É no backend que a descrição dos componentes pertencentes a um projeto é

transformada em uma representação geométrica (arquivo no formato GDSII), contendo o

layout do CI que deverá ser fabricado. A Figura 17 mostra as etapas envolvidas no projeto

físico, enquanto as Figuras 18 a 21 mostram, respectivamente, os resultados obtidos após as

etapas de Floorplanning, Placement, CTS e roteamento (Routing) de um projeto físico.

29

Figura 17: Projeto físico ou backend.

Figura 18: Floorplanning.

Floorplanning

Placement

Scan Reorder CTS

Roteamento

GDSII Verificação Física (DRC e LVS)


Verificação F

o

r

m

a

l RC

Extraction STA

Netlist DEF

30

Figura 19: Placement.

Figura 20: Síntese de árvore de clock – CTS.

31

Figura 21: Roteamento.

4.4.1 Floorplanning

O projeto físico começa na etapa de Floorplanning com o planejamento da planta

baixa do circuito integrado. O Floorplanning estima a área dos blocos que compõem o

circuito integrado e define o posicionamento dos mesmos. Além disso, nessa etapa também

são feitos o planejamento de alimentação de energia (Power Planning), a atribuição de pinos

e a fixação de memórias e macros [19]. O Floorplanning pode determinar se o projeto irá

caber dentro da área planejada para o CI, além de permitir estimar a extensão de

congestionamento de fios (isto é, a viabilidade futura do roteamento).

Geralmente é recomendado que se faça um Floorplanning preliminar para estimar, o

quanto antes, se o tamanho da lógica está de acordo com o especificado, servindo de

feedback para os projetistas. Desta forma, a execução de um Floorplanning preliminar

possibilita indicar que a microarquitetura de um projeto deva ser alterada, de modo a

diminuir a lógica e permitir que o projeto seja acomodado na área disponível para ele [19].

A etapa de Floorplanning recebe como entradas:

32

A netlist em nível de portas lógicas codificada em HDL;

As restrições da netlist no formato SDC – Synopsys Design Constraints;

As bibliotecas físicas no formato LEF (Library Exchange Format – Formato de Intercâmbio

de Bibliotecas);

As bibliotecas lógicas no formato Liberty (.lib), com informações de temporização e

consumo das células e memórias; e

Os scripts com restrições e diretivas para execução dessa etapa.

Por outro lado, como saída, o Floorplanning gera:

Arquivo no formato DEF (Design Exchange Format – Formato de Intercâmbio de Projetos),

usado para representar as conexões e o layout físico.

O arquivo DEF contém, inicialmente, as informações geradas no Floorplanning,

armazenando as descrições de aspectos físicos do projeto, tais como tamanho da pastilha de

silício (die), localização dos módulos e representação física dos pinos. Aapós as demais

etapas, tal arquivo é incrementado, passando a conter, por exemplo, a localização física das

células).

Por sua vez, as bibliotecas LEF encapsulam informações físicas das células e do

processo adotado. Algumas das informações contidas num arquivo LEF referem-se à

tecnologia e ao roteamento de metais, além dos formatos físicos das células. Além destas,

também há as bibliotecas Liberty, responsáveis por armazenar informações de atrasos e

consumo para as células padrão da tecnologia.

Para garantir que a planta definida para o circuito permita o roteamento e atenda

aos requisitos de utilização de área do die, assim como o tempo mínimo de propagação dos

sinais, o planejamento do Floorplanning tenta minimizar as distâncias entre as entradas e

saídas dos blocos que se comunicam. Além disso, devem ser feitas verificações prévias de

congestionamento de roteamento, de utilização de blocos e do plano de alimentação [19].

A Figura 22 mostra a planta de um circuito integrado, onde há três blocos A, B e C,

ligados entre si, a macroblocos de memória e a alguns pinos de entrada e saída. Pode-se ver

33

que, nesse exemplo, o Floorplanning define a posição dos blocos de modo a diminuir o

comprimento dos fios entre suas entras e saídas.

Figura 22: Planta do circuito integrado definida no Floorplanning.

4.4.2 Placement

O Placement é um passo essencial no backend. É nessa etapa que as células padrão e

as macros são colocadas dentro do layout do circuito inicialmente definido no Floorplanning

– ou seja, é feita a definição das localizações exatas dos componentes do circuito integrado.

A qualidade do Placement poderá afetar a desempenho ou inviabilizar o roteamento

e, por conseguinte, o CI. Sendo assim, o Placement considera os seguintes objetivos,

enquanto define a posições das células e macros [21]:

Comprimento total dos fios;

Temporização (atrasos);

Congestionamento; e

Consumo.

Bloco

B

RAM

DRAM

DP ROM

Bloco

A

Bloco

C

Bloco

B

RAM

DRAM DP ROM

Bloco

A

Bloco

C

34

A Figura 23 mostra uma planta de CI antes e após a atribuição de localização de

células padrão.

Figura 23: Die sem células padrão e com Placement realizado.

O Placement recebe como entradas:

A netlist do circuito sintetizado;

As definições do Floorplanning (arquivo DEF);

As bibliotecas tecnológicas (LEF e Liberty);

As restrições de tempo no formato SDC; e

Os scripts com restrições e diretivas para execução dessa etapa.

As saídas geradas pelo Placement são:

Netlist otimizada do projeto; e

Layout (arquivo DEF) com as células atribuídas aos devidos locais, de forma otimizada.

Nesse processo, a área do die é composta por fileiras de altura fixa, onde cada fileira

é composta por um número definido de posições (sites) que podem ser ocupadas por células

padrão, macros ou pinos de entrada e saída. As células padrão geralmente costumam ter

altura padrão, mas larguras variadas (sempre múltiplo do tamanho dos sites). Já os demais

componentes podem ter tamanho variado de fileiras e sites [20]. Nas tecnologias mais

antigas, com poucos níveis de metal, as fileiras precisam estar separadas para permitir o

roteamento. Em todo caso, tais informações são definidas na biblioteca física LEF.

A Figura 24 mostra um exemplo de layout de Placement.

35

Figura 24: Layout do Placement.

Alguns blocos podem ter tido sua localização atribuída, pelo Floorplanning, a um

determinado local, mediante restrições de localização que podem ser classificadas desde as

mais severas até as mais relaxadas. Em casos de restrições de localização severas, no

processo de Placement, as células para tais blocos deverão ser atribuídas nestes locais. Já

nos casos de restrições relaxadas, as células serão atribuídas livremente no processo de

Placement [21].

De qualquer forma, ao fim do processo de Placement, as células estarão fixadas nas

devidas posições, com o arquivo DEF sendo atualizado para refletir esta nova configuração.

Tal arquivo será usado no roteamento do circuito integrado [19].

Células Padrão Macro Blocos

Pinos de

Entrada

e Saída

Fileiras

36

O problema com a estratégia de fazer o Placement antes do roteamento é que

trabalha-se com valores estimados. Informações precisas de tempo de propagação dos sinais

dentro do CI só serão calculadas, com real precisão, depois que o layout estiver completo –

tal precisão somente é obtida com a extração dos valores de resistências e capacitâncias

parasitas, as quais são inseridas durante o roteamento.

Neste contexto, se houver problema de temporização (isto é, se o circuito não

atender as restrições de velocidade), o processo de Placement deverá ser executado

novamente, já considerando as novas restrições de tempo calculadas. O Placement dirigido

por restrições de temporização dá prioridade às células situadas nos caminhos mais críticos

(maior atraso de propagação), para minimizar o atraso de propagação entre elas [19].

4.4.3 Routing

Uma vez que as células e macros foram inseridas no die, elas precisam ser

conectadas. Para tanto, é feito o roteamento (Routing) dos fios internos do circuito

integrado, conectando efetivamente os componentes do circuito entre si, de acordo com as

chamadas regras de projeto (Design Rules) definidas pelo fabricante (foundry).

Primeiro é necessário conectar os sinais de VDD e VSS na parte superior e inferior das

células padrão, conforme destacado na Figura 25.

Figura 25: Conexão de VDD e VSS.

37

Na sequência, é feito o roteamento dos sinais que conectam as macros, células

padrão e pinos de entrada e saída [23]. Como o processo de roteamento geralmente envolve

conexões entre milhares, e até milhões de células, para lidar com tal complexidade, usa-se a

estratégia de dividir para conquistar [20] [23].

Assim, a etapa de roteamento é subdividida em roteamento global e roteamento

detalhado. Durante o processo de roteamento global, os fios são mapeados para grandes

células globais de roteamento conhecidas como gcells, sem serem conectados (apenas é

feita uma estimativa de quantos fios atravessam cada gcell). Já no roteamento detalhado, o

processo é concluído com os fios efetivamente conectados aos pinos.

O roteamento global abstrai o problema de roteamento através da noção de canais

adjacentes ou células de roteamento global (gcell), contendo trilhas de roteamento,

conforme pode ser visto na Figura 26. Nesse cenário, se a densidade de fios em um canal for

muito alta, os fios podem ser movidos de um canal para outro [19].

Figura 26: Roteamento global.

Capacidade de roteamento horizontal de 9 trilhas

Capacidade de roteamento vertical de 9 trilhas.

gcell

38

O processo de roteamento global é mais rápido que o de roteamento detalhado. Ele

consegue prover uma ideia razoável das dificuldades que estarão envolvidas no processo de

roteamento detalhado. Isso é feito através de mapas de congestionamento e informações de

número de rotas atribuídas para cada gcell, comparado à suas respectivas capacidades [21].

Se não houver uma quantidade significativa de regiões congestionadas, o roteamento

detalhado será capaz de resolver o problema aplicando desvios de rota através de regiões

vizinhas, mas se a quantidades de gcells congestionadas for muito elevada, existe uma

chance razoável de o roteamento detalhado falhar [21].

Por sua vez, o roteamento detalhado é responsável por concluir o processo,

efetivamente fazendo a conexão dos sinais. Ele é responsável por resolver violações de

regras de projeto (Design Rules) e evitar acoplamento capacitivo (crosstalk) [19].

Além desses tipos de roteamento, também há possibilidade de se fazer um

roteamento experimental (Trial Route), para saber se o projeto é roteável. O Trial Route

executa os roteamentos global e detalhado de maneira rápida e sem muita precisão,

objetivando estimar valores de parasitas e congestionamentos. A estimação de parasitas cria

os fios e gera uma representação dos parasitas RC, de forma a permitir otimizações prévias e

uma análise de temporização mais realista. Por outro lado, a estimação de

congestionamentos permite verificar, de maneira prévia, se o projeto poderá ser roteado.

4.4.4 Scan-Reorder, CTS e Verificação Física

Na etapa de Síntese Lógica pode-se inserir cadeias de varredura de flip-flops – as

chamadas scan-chains. Tais cadeias correspondem a redes de fios traçadas entre os flip-flops

da netlist, de forma a permitir o teste lógico do circuito após o processo de fabricação.

Durante o Placement, a ordenação de uma cadeia de varredura de flip-flops pode ocorrer de

forma não otimizada, de tal modo que é necessária uma etapa de reordenamento de tais

cadeias de escaneamento – etapa denominada Scan-Reorder.

Além disso, quase em sua totalidade, os circuitos eletrônicos digitais usam um

sincronismo proporcionado por um sinal de clock. Assim, deve-se garantir a devida

39

sincronização desse sinal nos flip-flops com mínima diferença de fase. Para tal objetivo, faz-

se necessário a síntese de uma árvore de clock (etapa denominada CTS – Clock Tree

Syntesis), a qual geralmente é acompanhada de processos de otimização pré e pós-CTS. Uma

vez que a CTS está pronta, é feito o roteamento (Routing) do circuito.

Por fim, para garantir o funcionamento adequado do Circuito Integrado, é necessário

um conjunto de verificações e validações tais como:

Verificação Física: Etapa formada pelos processos de DRC e LVS. O DRC (Design Rule

Checking) verifica se as regras de projeto especificadas pela foundry estão sendo

seguidas, enquanto o LVS (Layout Versus Schematic) verifica se o resultado final – a

disposição dos elementos no circuito físico final (o layout), está de acordo com a netlist

que representa o projeto lógico;

RC Extraction: É o processo de cálculo das resistências e capacitâncias parasitas dos fios

que ligam as células elementares do circuito. Os dados de RC obtidos permitem calcular

atrasos de propagação de sinal com grande precisão; e

STA (Static Timing Analysis): Etapa que calcula cada atraso para fios e portas, permitindo

verificar se as restrições de tempo – setup e hold – estão sendo cumpridas.

Após todas as verificações e validações, é feita a geração do arquivo padrão GDSII.

40

5 UNIVERSAL VERIFICATION METHODOLOGY (UVM)

UVM (Universal Verification Methodology – Metodologia de Verificação Universal) é

uma metodologia padrão usada na verificação de projetos de circuitos integrados. Essa

metodologia define uma biblioteca de classes e busca sistematizar as melhores práticas para

verificação exaustiva e eficiente. Um dos princípios-chave da UVM é incentivar o uso e o

desenvolvimento de componentes de verificação reutilizáveis – os UVCs (UVM Verification

Components – Componentes de Verificação da UVM) [24].

Em geral, UVM pode ser usada para verificação tanto de blocos individuais quanto

para SoCs (System-on-Chip – Sistema-em-Chip) baseados em IP-Cores (Intellectual Property

Cores – Módulos de Propriedade Intelectual). Tais IP-Cores são núcleos de propriedade

intelectual, constituídos de blocos de lógica e/ou dados, os quais são usados como parte de

projetos de FPGAs ou ASICs.

Em termos de composição, a metodologia UVM utiliza conceitos do VMM

(Verification Methodology Manual – Manual de Metodologia de Verificação) e é baseada na

biblioteca OVM (Open Verification Methodology – Metodologia de Verificação Aberta), a

qual combinou AVM (Advanced Verification Methodology – Metodologia Avançada de

Verificação) com URM (Universal Reuse Methodology – Metodologia Universal de Reuso) e

conceitos do eRM (e Reuse Methodology - Metodologia e de Reuso) [25].

Dentre outras vantagens, a UVM é um padrão aberto da Accellera Systems Initiative

suportado pela maioria das ferramentas de simulação existentes no mercado, permitindo a

construção de um ambiente de verificação particionado em conjunto de itens de dados

(data items) e componentes, onde tais componentes apresentam um conjunto de funções

pré-construídas para auxiliar na tarefa de verificação. Ela provê uma infraestrutura

completa, incluindo classes de componentes, o que permite a geração de estímulos de

forma eficiente. A geração desses estímulos pode ser: estática, aleatória ou aleatória

direcionada conforme o estado atual do ambiente de teste – o chamado DUT/DUV

(Design/Device Under Test/ Verification – Projeto/Dispositivo sob Teste/Verificação).

41

5.1 A BIBLIOTECA DE CLASSES DA UVM

A biblioteca de classes da UVM possibilita o desenvolvimento de ambientes e

componentes de verificação em SystemVerilog bem construídos, escaláveis e reutilizáveis

[25]. Ela provê classes-base e macros que facilitam o desenvolvimento e o uso de ambientes

de verificação, dando suporte à depuração através de mensagens controladas pelo usuário,

além da disponibilização de uma infraestrutura de comunicação padrão entre os

componentes de verificação através de TLM (Transaction-Level Modeling – Modelagem em

Nível de Transações) – TLM é uma abordagem usada para modelagem de comunicação, em

alto nível, em sistemas digitais. Além disso, é possível construir ambientes de

verificação flexíveis, através da UVM Factory. Componentes podem ser encapsulados e

instanciados hierarquicamente, além de serem controlados através de um conjunto de fases

que inicializa, executa e completa cada teste [26] – tais fases podem ser estendidas de

acordo com as necessidades do projeto.

5.2 BANCOS DE TESTE E AMBIENTE DE VERIFICAÇÃO EM UVM

Um banco de testes (testbench) em UVM é composto de ambientes de verificação

(também conhecidos como componentes de verificação UVCs, os quais são disponibilizados

pela biblioteca de classes do padrão), controles adicionais e lógicas de verificação e de

cobertura.

Um componente de verificação (UVC) pode ser entendido como um ambiente de

verificação configurável, destinado a verificar um sistema completo ou parte dele. Cada UVC

obedece a uma arquitetura consistente composta por um conjunto de elementos, tais como

monitor, drivers e sequencer, dentre outros. Tais elementos, através de uma UVC de

interface, têm a função de estimular, verificar e coletar informações de cobertura do DUT –

um projeto ou protocolo específico sob verificação [26]. Em geral, há dois tipos básicos de

UVCs de interface: ponto a ponto, que tem apenas um transmissor mestre e um receptor

escravo, e de barramento, que pode ter múltiplos mestres e escravos, assim como,

opcionalmente, um árbitro e um monitor de barramento [24].

42

A Figura 27 mostra um exemplo de ambiente de verificação com três componentes

de verificação de interface (Barramento UVC, Periférico A UVC e Periférico B UVC). Esses

componentes podem ser armazenados em um repositório de UVCs e reutilizados em outros

ambientes de verificação. Os componentes de verificação de interface são instanciados e

configurados para o modo de operação desejado. O ambiente de verificação também

contém um sequenciador virtual (Virtual Sequencer) – mecanismo de múltiplos canais de

sequências – que sincroniza os dados enviados para interfaces diferentes, permitindo

controlar o ambiente para executar um determinado teste em particular [26].

Figura 27: Ambiente de verificação UVM.

43

5.2.1 UVC de Interface

Um componente de verificação de interface é um ambiente de verificação que

contém os seguintes elementos/componentes:

Itens de dados (Data Items);

Direcionadores de estímulos das entradas (Drivers);

Geradores de estímulos (Sequencers e Sequences);

Monitores de DUT (Monitors);

Coletores (Collectors);

Agentes (Agents); e

Ambiente (Environment).

Tais componentes são descritos brevemente nas seções seguintes. Observa-se que

pode ocorrer de um Agent não ser ativo e funcionar apenas como escravo, monitorando o

DUT – nesse caso não haverá Drivers e nem Sequencers.

5.2.2 Itens de Dados (Data Items)

Um item de dado (Data Item) é um objeto que contém os estímulos da transação, ou

seja, as entradas para o DUT. Um pacote de internet, uma instrução ou uma transação de

barramento podem ser modelados como um item de dado.

Os campos ou atributos de um Data Item são derivados diretamente da especificação

dos itens de dados que se quer modelar na transação. Por exemplo, para a verificação de um

codificador de canal LDPC, os campos podem ser bits sistemáticos (bits de informação), bits

de paridade, taxa de código e tamanho da palavra de código.

Os campos dos itens de dados podem ser gerados aleatoriamente de maneira

controlada com o uso de restrições (constraints) do SystemVerilog. Através de restrições

direcionadas para a geração aleatória, uma grande quantidade de testes relevantes podem

ser obtidos, maximizando a cobertura [26].

44

5.2.3 Direcionadores de Estímulos das Entradas (Drivers)

Um driver é um tipo de BFM (Bus Functional Model – Modelo Funcional de

Barramento), limitado às entradas do DUT. Considerado uma entidade ativa, é utilizado para

emular a lógica que estimula o DUT.

Geralmente, o driver recebe os itens de dados e os insere nas entradas do DUT. Para

coordenar o envio dos dados na temporização adequada, o driver fica observando as saídas

do DUT e as regras de protocolo que devem ser seguidas.

5.2.4 Geradores de Estímulos (Sequencers e Sequences)

Um sequenciador (sequencer)é um gerador de estímulos avançado que controla a

geração dos itens de dados (Data Items) enviados para o driver.

Por padrão, um sequencer se comporta como um gerador de estímulo simples, o qual

entrega um item de dados aleatório para o driver sempre que for requisitado. Com esse

comportamento básico, é possível fazer com que as restrições de geração aleatória,

inseridas na construção das classes de itens de dados (Data Items), controlem a distribuição

dos valores gerados [26].

Um sequencer controla a geração de estímulos aleatórios através da execução de

sequences. Uma sequence define uma sequência de transações significativa dentro da

verificação. Uma sequence pode ser usada para gerar um ou mais itens de dados aleatórios,

além de conter parâmetros e restrições adicionais de temporização [24].

Conjuntos sequencer/sequence têm a capacidade de controlar a geração do Data

Item de acordo com o estado atual do DUT, promover a sincronização em nível de sistema e

controlar várias interfaces simultaneamente. De forma complementar, várias sequences

podem ser combinadas para formar uma sequência de itens de dados mais complexa [24].

45

5.2.5 Monitores (Monitors)

Um monitor, ao contrário de um driver, é uma entidade passiva que observa os sinais

de entrada e saída do DUT, mas não interfere neles – apenas coleta informações de

cobertura e executa alguma forma de verificação de protocolo de sinais.

Os monitores são responsáveis por coletar transações (data items) e torná-las

disponíveis para outros componentes. Eles detectam a disponibilidade das informações nos

barramentos ou interfaces de E/S, capturam tais informações e estruturam os dados,

emitindo eventos para notificar outros componentes da disponibilidade de uma transação.

Além disso, os monitores também podem executar a verificação de algum protocolo

de comunicação do DUT. O monitor de um barramento trata de todos os sinais presentes no

barramento considerado (isto é, analisa todas as transações), ao passo que o monitor de um

agent trata apenas dos sinais e transações referentes a esse agent [26].

Monitores e drivers devem ser construídos separadamente, sem dependências entre

si. Para permitir que agents possam funcionar de modo passivo, monitores e drivers não

devem trocar informações diretamente entre si.

Em [24] é recomendado que as atividades do monitor sejam divididas em atividades

em nível de sinais e atividades em nível de transações. Nesse caso, as atividades de baixo

nível devem ser executadas por uma classe collector, explicada na sequência.

5.2.6 Coletores (Collectors)

O collector também é uma entidade passiva, assim como o monitor. Ele é responsável

por seguir um protocolo específico, de modo a capturar sinais numa interface, formando

transações. Uma porta de análise é usada para enviar as transações capturadas para o

monitor, onde a verificação de cobertura pode ser executada [24]. A Figura 28 mostra como

se dá a comunicação entre o monitor e o collector.

46

Figura 28: Comunicação entre monitor e collector.

5.2.7 Agentes (Agents)

Um agente é usado para agrupar, configurar e conectar sequencers, drivers e

monitores. Cada um desses componentes pode ser reutilizado de forma independente dos

demais – contudo, para reduzir o trabalho de descrição de testes e a necessidade de

conhecimento de particularidades de configuração de cada um desses componentes, a

metodologia UVM recomenda o agrupamento dos mesmos num componente mais abstrato

(o agent), o qual pode emular e verificar um DUT.

Um UVC pode conter um ou mais agentes. Os agentes que iniciam uma transação

com o DUT são chamados de mestres (ou agentes de transmissão), ao passo que os agentes

que apenas reagem a uma transação são chamados de escravos (ou agentes recebedores).

Deve ser possível configurar os agentes para trabalharem como componentes ativos ou

passivos [26].

5.2.8 Ambiente (Environment)

O environment (env) é o elemento hierárquico mais elevado (top) dos componentes

de verificação UVM. Ele pode conter um ou mais agentes.

O env permite configurar propriedades que permitem alterar sua topologia e

comportamento, de modo a permitir seu reuso. Por exemplo, o agente ativo que verifica o

47

codificador LDPC, de maneira independente, pode ser configurado para o modo passivo,

permitindo que este componente se integre à verificação macro do sistema de comunicação

do qual ele faz parte [24].

A Figura 29 mostra um UVC de interface padrão. Como pode ser visto, o componente

de verificação pode conter um monitor de barramento, o qual é responsável por executar as

atividades que não estão ligadas a um único agente. Nesse contexto, os monitores dos

agentes podem aproveitar os dados coletados pelo monitor de barramento [26].

Figura 29: UVC de interface típico.

48

6 DESENVOLVIMENTO DO TRABALHO

O projeto e a pesquisa propostos neste trabalho foram desenvolvidos em cinco

etapas.

A primeira etapa correspondeu à pesquisa e à modelagem do sistema em MATLAB e

C. Na segunda parte foi desenvolvida a arquitetura do projeto e a sua implementação RTL,

em linguagem de descrição de hardware Verilog. Na terceira fase foi construído o ambiente

de verificação funcional, a partir da metodologia UVM, usando a linguagem SystemVerilog,

tendo sido executada a verificação. Na quarta etapa o projeto passou pelo fluxo backend de

circuitos integrados digitais, da síntese lógica ao GDSII, em tecnologia VLSI de 55 nm. Na

quinta parte foi feita a comparação de desempenho de potência e área, em relação a

soluções desenvolvidas para outros padrões.

O detalhamento de cada etapa é dado na sequência.

● Primeira Etapa: Desenvolvimento do Sistema

○ Estudo de algoritmos existentes, avaliando-os quanto ao custo computacional e à

facilidade de adequação a uma arquitetura de hardware;

○ Estudo e pesquisa de soluções desenvolvidas para outros padrões que utilizam LDPC,

tais como DVB-S2 e IEEE 802.11n WLAN;

○ Levantamento de requisitos de desempenho (throughput) para o rádio cognitivo

especificado pelo padrão IEEE 802.22 WRAN;

○ Implementação do algoritmo em uma linguagem de alto nível (MATLAB e C/C++),

para validação de conceitos e uso como modelo de referência para a verificação

funcional; e

○ Modelagem e validação das arquiteturas em linguagem de alto nível.

49

● Segunda Etapa: RTL do Frontend

○ Codificação do sistema em RTL, através da HDL Verilog. Esse processo resulta numa

forma de descrição da operação do circuito digital, na qual o comportamento do

sistema é definido em termos do fluxo de sinais entre registradores e das operações

realizadas, mediante etapas de controle definidas através de pulsos de clock.

● Terceira Etapa: Verificação Funcional

○ Desenvolvimento do ambiente de verificação funcional em UVM. Tal ambiente

incluiu os seguintes componentes:

Agents: usados para integrar os monitors, drivers, sequencers e suas

configurações;

Drivers: usados para emular o protocolo de acesso ao DUT (RTL a ser

verificado);

Monitors e Collectors: entidades passivas usadas para fazer a amostragem

dos sinais enviados ao DUT;

Sequencers: responsável por gerar data itens para os drivers;

Data itens: responsável por transportar os dados de cada transação para o

DUT; e

Scoreboard: módulo responsável por fazer a validação funcional dos dados

coletados do DUT, assim como a interface entre o modelo de referência (em

C/C++) com o ambiente UVM (em SystemVerilog).

○ Verificação das funcionalidades do RTL, através do uso do ambiente UVM

desenvolvido, para simular as situações de uso do hardware e verificar se este

funciona conforme o esperado; e

○ Verificação do protocolo de comunicação.

50

● Quarta Etapa: Fluxo ASIC

○ Síntese Lógica

○ Verificação Formal

○ Floorplanning

○ Placement

○ Scan-Reorder

○ CTS (Clock Tree Synthesis)

○ Routing

○ Verificação Física

○ RC Extraction

○ STA, DRC e LVS

○ Geração de GDSII

6.1 ARQUITETURA

Duas arquiteturas foram modeladas e implementadas para executar a codificação

requerida, através das etapas definidas nas equações (15), (16), (20) e (21), de forma

otimizada.

No início da execução, os valores intermediários são

calculados de acordo com a equação (15) e armazenados temporariamente.

Enquanto cada é calculado, ele é acumulado para compor o primeiro bloco de

paridade – equação (16), sendo salvo na memória. Fisicamente, os valores são salvos

nas posições reservadas para os blocos de paridade . A cada calculado, o respectivo é

descartado da memória.

Na sequência, o último bloco de paridade é calculado. Para executar esse

procedimento, é necessário ter o primeiro bloco de paridade e o último valor

intermediário prontos, para aplicá-los à equação (20).

Por fim, a equação (21) pode ser aplicada para calcular as demais paridades.

51

A chave para a modelagem de arquiteturas para codificadores LDPC, que usam a

matriz base de código de verificação de paridade , é manipular as equações que

satisfaçam a igualdade – equação (9) – de modo que as expressões resultantes se

adequem ao hardware que se quer implementar.

A partir do rearranjo de algumas expressões, foi possível inferir a equação (21). Tal

expressão permitiu calcular a paridade do final para o início, indo de até . Também

foi possível balancear o cálculo de blocos de paridade de modo que, a cada nova paridade

calculada, o respectivo valor temporário pudesse ser descartado. Além dessas

otimizações, a escolha em calcular os blocos de paridade de maneira decrescente,

possibilitou que o último valor a ser calculado em (15) , fosse o primeiro usado em

(20), permitindo que esse valor temporário não precisasse ser armazenado e lido da

memória.

O fluxo geral de execução das arquiteturas produzidas é definido pela máquina de

estados finita mostrada na Figura 30. No estado WAIT o sistema está aguardando um

comando externo – quando uma nova configuração chega, o sistema vai para o estado

START. No START, o hardware é inicializado com as configurações recebidas.

Figura 30: Máquina de estados com o fluxo do processo de codificação LDPC.

52

O estado SOMA LINHAS executa o processo de varrer uma linha em e o vetor

informação , bloco a bloco, fazendo com que cada bloco seja deslocado circularmente

para a esquerda, pelo valor em , e acumulado no registrador de trabalho. A matriz é

uma submatriz da matriz , conforme pode ser visto na Figura 31. Tal submatriz fica

armazenada em uma ROM.

Figura 31: Região útil da matriz Hb.

Ao final do processamento de SOMA LINHAS, obtém-se o valor intermediário , o

qual é guardado na memória reservada para e acumulado na posição de . Esse

procedimento ocorre no estado GUARDA E ACUMULA. O processo iterativo entre os estados

SOMA LINHAS e GUARDA E ACUMULA é feito até que todas as linhas tenham sido

percorridas – equações (15) e (16). No final, tem-se os valores intermediários armazenados e

o bloco de paridade zero calculado.

Uma vez que está pronto, o estado CALCULA ÚLTIMA PARIDADE controla o

cálculo de , equação (20), onde é deslocado circularmente para a esquerda pelo

valor (linha em ) – Figura 31 – e somado com o valor intermediário

, já guardado na posição de memória .

O estado CALCULA PARIDADES controla o cálculo das demais paridades. Estas são

calculadas de maneira similar à executada no estado CALCULA ÚLTIMA PARIDADE, só que o

bloco de paridade calculado anteriormente, , também é somado - equação (21). Os dois

outros estados controlam o descarregamento dos dados de informação e paridade.

Neste trabalho foram desenvolvidas duas arquiteturas seriais, uma para funcionar

como um coprocessador (considerando acesso compartilhado à memória do sistema) e

outra com memória SRAM interna (tendo entrada serial de bits da informação a ser

Pij

kb

mb

nb

Hb2

hb

H'b1

53

codificada). Ambas as arquitetura, são capazes executar a codificação de canal LDPC para 84

configurações, entre tamanhos taxa de códigos diferentes.

6.1.1 Arquitetura Com SRAM Interna

O que chamamos de arquitetura serial é a estrutura de hardware modelada para

funcionar com memória de trabalho (SRAM) própria e com operações internas executadas

de maneira totalmente serial.

Nesta arquitetura – Figura 32 – os dados são recebidos e tratados serialmente. Assim,

na execução de cada iteração definida em (15), o deslocamento circular para a esquerda

sobre o vetor , , é feito utilizando um multiplexador e um

demultiplexador de 96 entradas, que em termos de hardware é menos custoso que um

barrel-shifter – Figura 33.

Figura 32: Diagrama de blocos da arquitetura serial.

54

Figura 33: Barrel-Shifter.

Um barrel-shifter circular pode ser construído através de um conjunto de

multiplexadores de duas entradas, onde cada multiplexador pode conter duas portas AND,

uma OR e uma NOT.

Na Figura 33 temos um exemplo de barrel-shifter circular de quatro entradas, ,

e dois bits de seleção, . Para esta configuração há um total de oito

multiplexadores ou dezesseis ANDs, oito ORs e oito NOTs.

Pode-se generalizar o cálculo de recursos de um barrel-shifter circular como sendo

multiplexadores de duas entradas ou, ainda, ANDs, ORs e NOTs. A

título de comparação, considerando o multiplexador da Figura 34, podemos notar que, para

quatro entradas há o consumo de oito ANDs, três ORs e dois NOTs. Nota-se que os recursos

de hardware envolvidos na construção de um barrel-shifter é maior que os envolvidos na

construção um multiplexador de mesma quantidade de entradas, conforme pode ser visto

na Tabela 2. Pode-se generalizar o cálculo dos recursos envolvidos na construção de um

multiplexador como sendo ANDs, ORs e NOTs.

in_0

in_1

in_2

in_3

out_0

out_1

out_2

out_3

sel_0

sel_1

55

Figura 34: Multiplexador.

Tabela 2: Estimativa de recursos de hardware.

AND OR NOT Total

Barrel-Shifter 128 1792 896 896 3584

Multiplexador 128 896 127 7 1030

Barrel-Shifter 64 768 384 384 1536

Multiplexador 64 384 63 6 453

Na arquitetura da Figura 32, ao invés de armazenar e deslocar todos os bits de um

bloco de uma só vez, os dados são somados, um a um, e colocados no lugar onde iriam

estar após o deslocamento. O valor que define o tamanho do deslocamento é obtido a partir

da ROM contendo as matrizes base , Figura 31. Esses valores definem a posição inicial do

multiplexador, assim, a cada novo bit tratado, o valor do deslocamento é incrementado.

Devido ao fato de não precisar armazenar os dados da entrada serial para aplicar o

deslocamento de uma única vez, é economizado um registrador de 96 posições.

Nessa arquitetura, os valores das matrizes , Figuras 5 a 8, são armazenados

sequencialmente na memória e, diferentemente da arquitetura coprocessador, todos os

valores da região útil das matrizes, Figura 31, são armazenados, de maneira crescente, de

56

modo a permitir o acesso linha a linha. Para cada conjunto de valores (bloco de bits

sistemáticos) é obtido um valor correspondente em que indica se ele será ou não

somado para compor o valor e qual deslocamento circular deverá ser aplicado. Valores de

0 a 96 indicam o tamanho do deslocamento, enquanto 97 representa o valor nulo, isto é,

multiplicado por zero. Para armazenamento destas constantes, referentes às quatro

matrizes, foi usada uma ROM de 512 palavras de 7 bits.

O cálculo do primeiro bloco de valores intermediários é feito simultaneamente ao

recebimento da mensagem – vetor de bits sistemáticos – pela entrada

serial. Para o cálculo dos demais , os valores precisam ser armazenados internamente.

Os bits sistemáticos são armazenados em uma memória SRAM. Para gravar os dados na

memória é necessário armazená-los temporariamente em sram_input_reg, de 4 em 4 bits.

Após o cálculo de cada linha , os bits correspondentes são armazenados nas

posições de memória reservadas para os vetores de paridade. Os valores são usados

posteriormente nos cálculos dos blocos de paridade – conforme cada paridade vai sendo

definida, os valores são substituídos na SRAM.

O tamanho de 4 bits de palavra para a memória de trabalho foi escolhido por ser o

máximo divisor comum de todos os tamanhos de bloco z definidos para o padrão – Tabela 1.

Essa escolha, associada à organização das matrizes na ROM, facilita a tarefa de alcançar a

flexibilidade de tamanhos e taxas de código demandada pelo padrão IEEE 802.22 WRAN.

Para esta arquitetura foi usada uma SRAM de 576 palavras de 4 bits.

6.1.2 Arquitetura Coprocessador

A arquitetura coprocessador também é uma arquitetura serial. Ela foi modelada a

partir do hardware mostrado na subseção anterior, incorporando várias otimizações. Essa

arquitetura considera o cenário em que o codificador é usado como um coprocessador,

tendo acesso compartilhado à memória onde estão as informações a serem codificadas e

onde deverão ser gravados os bits de paridade calculados. Com isso é possível eliminar a

57

SRAM de trabalho interna, já que as informações são negociadas diretamente com a

memória do sistema. Esse módulo foi projetado para operar como um periférico escravo.

A arquitetura coprocessador é mostrada na Figura 35. Nela, os valores de

armazenados são organizados de maneira diferente. A primeira mudança significativa é que

são armazenadas apenas as informações de deslocamento válidas. Como as matrizes de

paridade, Figuras 5 a 8, são esparsas – isto é, com uma grande quantidade de elementos

nulos (representados pelo valor -1) – grande parte de seus valores não precisa ser

armazenada, diminuindo o tamanho da memória.

Figura 35: Diagrama de blocos da arquitetura coprocessador.

58

Na modelagem descrita na subseção anterior, todos os valores da submatriz e da

primeira coluna da matriz são armazenados na ROM, de modo a permitir que o

contador usado para iterar os blocos de informação , no cálculo da equação (15), seja

usado para selecionar o valor correspondente na matriz . Desse modo, se o valor em

for um valor nulo, então o valor correspondente não será computado. Naquela

abordagem puramente serial, a leitura sequencial dos valores permite que os dados

sistemáticos sejam usados conforme sua chegada pela entrada serial. Entretanto, na

arquitetura coprocessador, os dados sistemáticos são acessados sob demanda na memória

do sistema, o que permitiu otimizações na estrutura de armazenamento das matrizes na

ROM.

Nessa organização, apenas os elementos não nulos (úteis) em (Figura 36) são

armazenados, juntamente com os respectivos endereços. Sendo assim, para o cálculo de

em (15), é possível acessar apenas os blocos referentes aos valores de deslocamento não

nulos. Com isso vários ciclos são economizados. A Figura 36 mostra um exemplo de matriz

, para uma taxa de código de 1/2, com os respectivos valores que são armazenados

circulados em azul. Para esse exemplo, apenas 54 valores dos 156 são armazenados. Para

armazenar as quatro matrizes base, foi usada uma ROM de 320 palavras de 12 bits, onde 7

bits são usados para indicar o valor do deslocamento e 5 bits para indicar o endereço da

coluna em .

Figura 36: Valores não nulos úteis da matriz Hb para taxa de código 1/2.

–1 94 73 –1 –1 –1 –1 –1 55 83 –1 –1 7 0 –1 –1 –1 –1 –1 –1 –1 –1 –1 –1

–1 27 –1 –1 –1 22 79 9 –1 –1 –1 12 –1 0 0 –1 –1 –1 –1 –1 –1 –1 –1 –1

–1 –1 –1 24 22 81 –1 33 –1 –1 –1 0 –1 –1 0 0 –1 –1 –1 –1 –1 –1 –1 –1

61 –1 47 –1 –1 –1 –1 –1 65 25 –1 –1 –1 –1 –1 0 0 –1 –1 –1 –1 –1 –1 –1

–1 –1 39 –1 –1 –1 84 –1 –1 41 72 –1 –1 –1 –1 –1 0 0 –1 –1 –1 –1 –1 –1

–1 –1 –1 –1 46 40 –1 82 –1 –1 –1 79 0 –1 –1 –1 –1 0 0 –1 –1 –1 –1 –1

–1 –1 95 53 –1 –1 –1 –1 –1 14 18 –1 –1 –1 –1 –1 –1 –1 0 0 –1 –1 –1 –1

–1 11 73 –1 –1 –1 2 –1 –1 47 –1 –1 –1 –1 –1 –1 –1 –1 –1 0 0 –1 –1 –1

12 –1 –1 –1 83 24 –1 43 –1 –1 –1 51 –1 –1 –1 –1 –1 –1 –1 –1 0 0 –1 –1

–1 –1 –1 –1 –1 94 –1 59 –1 –1 70 72 –1 –1 –1 –1 –1 –1 –1 –1 –1 0 0 –1

–1 –1 7 65 –1 –1 –1 –1 39 49 –1 –1 –1 –1 –1 –1 –1 –1 –1 –1 –1 –1 0 0

43 –1 –1 –1 –1 66 –1 41 –1 –1 –1 26 7 –1 –1 –1 –1 –1 –1 –1 –1 –1 –1 0

H b1H b2

59

Além de não necessitar de uma SRAM de trabalho, não guardar valores nulos de

na ROM e evitar percorrer valores de que não são contabilizados em , essa segunda

arquitetura, Figura 35, também opera com 4 bits por vez, compatibilizando sua operação de

soma em GF(2), XOR entre bits, com o tamanho da palavra de trabalho interna.

Para compatibilizar o tamanho de palavra interna de trabalho com o tamanho de

palavra da memória do sistema, foi criada uma interface de SRAM. Ela é responsável por ler

e escrever na memória do sistema e entregar para o codificador as palavras adequadas à sua

operação interna. Para este projeto foi adotada uma interface de 32 para 4 bits, mas esta

interface pode ser facilmente alterada para compatibilizar com outros tamanhos de palavra

de barramento.

A escolha da taxa de código é feita através da seleção do endereço da ROM. Os

endereços onde ficam o primeiro valor de cada matriz , para uma determinada taxa de

código, são mostrados na Tabela 3.

Tabela 3: Endereço inicial de cada taxa de código

Taxa de Código Endereço Inicial

1/2 0x00

2/3 0x41

3/4 0x8B

5/6 0xDB

6.2 VERIFICAÇÃO FUNCIONAL

As verificações das duas arquiteturas de codificador LDPC foram implementadas com

a metodologia e a biblioteca de classes do UVM. O ambiente de verificação foi feito em

linguagem SystemVerilog, sendo que houve reaproveitamento (reuso), na verificação das

duas arquiteturas, de grande parte das classes desenvolvidas na construção do ambiente.

Foram usadas estruturas de geração aleatória de estímulos, direcionadas a partir de

restrições do SystemVerilog. O modelo de referência foi construído em linguagem C, sendo

60

este validado por modelos preexistentes em MATLAB. Posteriormente, o código C foi ligado

ao scoreboard para servir de referência para o DUT.

No ambiente de verificação, para a arquitetura serial com SRAM interna, há um

agente ativo (mestre) contendo um elemento ldpc_sequencer, o qual é responsável por

fornecer itens de dados ldpc_seq_item ao ldpc_fs_driver. O driver se liga ao sequenciador

(sequencer) através de TLM, tendo sua porta seq_item_port conectada à porta

seq_item_export do sequencer, como é mostrado na Figura 37. Nesse esquema, o sequencer

é responsável por produzir os itens de dados e provê-los à sua porta de saída, export. Por

outro lado, o driver é responsável por consumir os itens de dados através de sua porta de

entrada seq_item_port e avisar que o item foi usado. A conexão entre as portas do driver e

sequencer é feita dentro do agente. A conexão é feita como mostra a Figura 38.

Figura 37: Conexão entre portas do driver e do sequencer.

virtual function void connect_phase(uvm_phase phase);

super.connect_phase(phase);

collector.item_collected_port.connect(monitor.item_collected_export);

if (is_active == UVM_ACTIVE)

begin

driver.seq_item_port.connect(sequencer.seq_item_export);

end

endfunction : connect_phase

Figura 38: Driver seq_item_port conectado à porta seq_item_export do sequencer.

61

A arquitetura do ambiente de verificação, para a arquitetura serial, é mostrada na

Figura 39. Além do driver e do sequencer, o ldpc_agent também abriga o ldpc_fs_collector e

o ldpc_fs_monitor. Uma porta de análise é usada para enviar as transações amostradas no

ldpc_fs_collector para o ldpc_fs_monitor. O monitor, por sua vez, repassa o item coletado,

ldpc_collected_item, ao scoreboard instanciado fora do agente.

Figura 39: Ambiente de verificação para arquitetura serial.

A Figura 40 mostra como se dá a comunicação entre o monitor, o collector e o

scoreboard. O monitor é conectado ao scoreboard dentro do ldpc_env, na fase de conexão,

62

como mostra a Figura 41. Por sua vez, o collector se conecta ao monitor dentro do agente,

como pode ser visto na Figura 37. Tanto o collector quanto o driver se conectam ao DUT

através da interface de portas do SystemVerilog.

Figura 40: Comunicação entre monitor, collector e scoreboard.

virtual function void connect_phase(uvm_phase phase);

agent.monitor.item_collected_port.connect(scoreboard.item_collected_export);

endfunction : connect_phase

Figura 41: Monitor conectado à porta item_collected_export do scoreboard.

No ambiente de verificação, o scoreboard é responsável por receber os itens de

dados coletados da interface com o DUT, além de verificar a correção dos mesmos. Para tal,

o scoreboard consulta o modelo de referência construído em C – ele executa a verificação

em nível funcional, não se ocupando com detalhes do protocolo. Para usar o modelo de

referência em C, o scoreboard usa DPI-C. O DPI (Direct Programming Interface – Interface de

63

Programação Direta) do SystemVerilog é basicamente uma interface entre SystemVerilog e

uma outra linguagem de programação – nesse caso, a C. Ele permite fazer chamadas a

funções em C a partir do SystemVerilog e vice versa [27].

Além do componente de verificação UVC de interface descrito, há a classe que

estende uvm_test (test_ldpc_full_serial), a qual é responsável por configurar o teste

executado. Neste caso, ela seleciona o ambiente e a sequência de itens que será carregada.

Ela também pode sobrescrever elementos componentes do ambiente.

O testbench é instanciado no módulo hierárquico mais elevado (top). Este módulo é

responsável por importar os pacotes de classes do UVM e o ambiente criado, instanciar o

DUT e a interface, conectar ambos, passar a interface para o ambiente e iniciar o teste. Além

disso, o módulo top contém a geração de clock.

Para o ambiente de verificação da arquitetura coprocessador, várias classes foram

reutilizadas. A Figura 42 mostra em vermelho as classes que foram alteradas. Além do DUT e

da interface SystemVerilog, apenas o monitor, o collector, o driver e as configurações de

testes foram alteradas. Para refazer as configurações necessárias, ambos os testes

(test_ldpc_full_serial e test_ldpc_coprocessor) estendem uma classe test_base, apenas

sobrescrevendo a função build_phase. O teste test_ldpc_coprocessor sobrescreve as classes

monitor, collector e driver, através do uvm_config_db. As Figuras 43 e 44 mostram o sumário

de cada teste.

64

Figura 42: Ambiente de verificação para arquitetura coprocessador.

65

UVM_INFO @ 0: reporter [RNTST] Running test test_ldpc_full_serial... 0: uvm_test_top.ldpc_env0.ldpc_scoreboard: start_of_simulation

UVM_INFO @ 0: reporter [UVMTOP] UVM testbench topology: -----------------------------------------------------------------------

Name Type Size Value

----------------------------------------------------------------------- uvm_test_top test_ldpc_full_serial - @132

ldpc_env0 ldpc_env - @5359 agent0 ldpc_agent - @5358

driver ldpc_fs_driver - @5557 rsp_port uvm_analysis_port - @5967

recording_detail uvm_verbosity 32 UVM_FULL

sqr_pull_port uvm_seq_item_pull_port - @5862 recording_detail uvm_verbosity 32 UVM_FULL

req object - <null> recording_detail uvm_verbosity 32 UVM_FULL

monitor ldpc_fs_monitor - @5431

sb_post uvm_analysis_port - @5692 recording_detail uvm_verbosity 32 UVM_FULL

trans ldpc_collected_item - @5554 length integral 8 'h0

codeword sa(integral) 0 - systematics sa(integral) 0 -

rate rate_e 2 RATE_1_2

recording_detail uvm_verbosity 32 UVM_FULL sequencer ldpc_sequencer - @5755

rsp_export uvm_analysis_export - @6156 recording_detail uvm_verbosity 32 UVM_FULL

seq_item_export uvm_seq_item_pull_imp - @7335 recording_detail uvm_verbosity 32 UVM_FULL

recording_detail uvm_verbosity 32 UVM_FULL

arbitration_queue array 0 - lock_queue array 0 -

num_last_reqs integral 32 'd1 num_last_rsps integral 32 'd1

is_active uvm_active_passive_enum 1 UVM_ACTIVE recording_detail uvm_verbosity 32 UVM_FULL

ldpc_scoreboard ldpc_scoreboard - @5428

item_collected_export uvm_analysis_imp - @7504 recording_detail uvm_verbosity 32 UVM_FULL

is_enable ldpc_enable_disable_enum 32 ENABLE recording_detail uvm_verbosity 32 UVM_FULL

recording_detail uvm_verbosity 32 UVM_FULL -----------------------------------------------------------------------

Figura 43: Sumário de verificação para arquitetura serial.

66

UVM_INFO @ 0: reporter [RNTST] Running test test_ldpc_coprocessor... 0: uvm_test_top.ldpc_env0.ldpc_scoreboard: start_of_simulation UVM_INFO @ 0: reporter [UVMTOP] UVM testbench topology: ----------------------------------------------------------------------- Name Type Size Value ----------------------------------------------------------------------- uvm_test_top test_ldpc_coprocessor - @132 ldpc_env0 ldpc_env - @5359 agent0 ldpc_agent - @5358 driver ldpc_cp_driver - @5557 rsp_port uvm_analysis_port - @5967 recording_detail uvm_verbosity 32 UVM_FULL sqr_pull_port uvm_seq_item_pull_port - @5862 recording_detail uvm_verbosity 32 UVM_FULL req object - <null> recording_detail uvm_verbosity 32 UVM_FULL monitor ldpc_cp_monitor - @5431 sb_post uvm_analysis_port - @5692 recording_detail uvm_verbosity 32 UVM_FULL trans ldpc_collected_item - @5554 length integral 8 'h0 codeword sa(integral) 0 - systematics sa(integral) 0 - rate rate_e 2 RATE_1_2 recording_detail uvm_verbosity 32 UVM_FULL sequencer ldpc_sequencer - @5755 rsp_export uvm_analysis_export - @6156 recording_detail uvm_verbosity 32 UVM_FULL seq_item_export uvm_seq_item_pull_imp - @7335 recording_detail uvm_verbosity 32 UVM_FULL recording_detail uvm_verbosity 32 UVM_FULL arbitration_queue array 0 - lock_queue array 0 - num_last_reqs integral 32 'd1 num_last_rsps integral 32 'd1 is_active uvm_active_passive_enum 1 UVM_ACTIVE recording_detail uvm_verbosity 32 UVM_FULL ldpc_scoreboard ldpc_scoreboard - @5428 item_collected_export uvm_analysis_imp - @7504 recording_detail uvm_verbosity 32 UVM_FULL is_enable ldpc_enable_disable_enum 32 ENABLE recording_detail uvm_verbosity 32 UVM_FULL recording_detail uvm_verbosity 32 UVM_FULL -----------------------------------------------------------------------

Figura 44: Sumário de verificação para arquitetura coprocessador.

67

7 APRESENTAÇÃO E ANÁLISE DE DADOS

A princípio, para permitir a comparação com os trabalhos propostos em [13], [28] e

[29], foram considerados apenas os parâmetros utilizados pelos autores na descrição de suas

respectivas arquiteturas.

As propostas de codificadores, nos artigos referidos acima, não foram efetivamente

implementadas em hardware. Assim, a complexidade e o custo de hardware expressos em

tais trabalhos apenas referem-se a estimativas, baseadas nas respectivas arquiteturas

definidas pelos autores.

Também há outros fatores importantes a serem considerados nessa primeira análise.

Os codificadores propostos nesses artigos foram feitos para o padrão de comunicação

802.11n, com as arquiteturas esboçadas levando em consideração apenas uma taxa de

código, o que implica na utilização de uma única matriz de codificação. Por outro lado, as

arquiteturas desenvolvidas e implementadas neste trabalho são capazes de operar em 84

diferentes configurações de tamanho e taxas de código.

Na Tabela 4 é apresentada uma comparação de resultados, no que concerne à

quantidade de estruturas de hardware utilizadas, entre as arquiteturas esboçadas em [13],

[28] e [29], e as propostas neste trabalho. Para efeito de comparação e compatibilização das

arquiteturas desenvolvidas com o padrão IEEE 802.22 WRAN, o consumo de recursos foi

recalculado, tomando por base um bloco Z igual a 96 bits. Em [13] foi usada uma abordagem

totalmente paralela, o que garante uma baixa latência, mas gera o maior custo em termos

de hardware; o trabalho desenvolvido em [28] propõe uma abordagem mista, na qual cada

bloco de tamanho Z bits é executado por vez, operando-se somente sobre valores não nulos.

Essa estratégia aumenta a latência, mas diminui drasticamente a quantidade de recursos

consumida pela arquitetura; por outro lado, na abordagem apresentada em [29], o

processamento dos blocos de Z bits também é feita em paralelo, só que, ao contrário de

[13], a execução é feita coluna a coluna. Essa estratégia permite alcançar a mesma latência

de [13], porém consumindo aproximadamente a metade dos flip-flops e portas XOR, além de

eliminar a necessidade da memória usada para guardar os valores .

68

Tabela 4: Comparação entre a quantidade de estruturas utilizadas nas arquiteturas propostas.

Flip-Flops XOR Barrel-shifter Outros Memória

[13] 2016 1920 20 * + RAM

[28] 192 288 1 * + RAM + FIFO

[29] 1248 1248 12 * + FIFO

Serial Com SRAM 104 1 0 2 MUX + RAM + RAM

Coprocessador 192 100 0 3 MUX

Ambas as arquiteturas propostas neste trabalho conseguem alcançar os requisitos de

flexibilidade de 84 configurações diferentes, entre tamanho de palavras de códigos e taxa de

codificação, impostos pelo padrão IEEE 802.22 WRAN, usando uma quantidade menor de

recursos que as arquiteturas apresentadas em [13], [28] e [29].

Para a arquitetura serial com SRAM interna foram utilizados apenas (Figura 35):

uma porta XOR;

dois registradores de 4 bits;

um registrador de 96 bits;

três multiplexadores;

um demultiplexador;

um contador de deslocamento;

um módulo de memória ROM para guardar as matrizes ; e

um módulo de memória SRAM de trabalho.

Para a arquitetura coprocessador foram utilizados (Figura 35):

quatro portas XOR para a operação principal;

noventa e seis portas XOR para o acumulador que calcula ;

um registrador de 96 bits para a operação principal;

um registrador de 96 bits para guardar ;

três multiplexadores;

um demultiplexador; e

um módulo de memória ROM para armazenar os valores de .

69

Para ser coerente, na comparação com as arquiteturas propostas em [13], [28] e [29]

– as quais não consideram os circuitos lógicos usados para controle, nem questões

relacionadas à codificação de tamanhos e taxas diferentes – a análise feita até aqui levou em

consideração apenas os principais componentes das arquiteturas. Entretanto, no presente

trabalho, para construção dos codificadores, além das estruturas relacionadas

anteriormente, foram usados controladores compostos por FSMs, contadores e estruturas

para o cálculo de configurações, a partir da taxa e tamanho da palavra de código.

Os IP-Cores dos codificadores foram sintetizados em tecnologia de 55 nm, chegando

até o GDSII, para uma frequência de 300 MHz – Figuras 45 e 46. As Tabelas 5 e 6 mostram os

resultados de área e consumo obtidos na implementação ASIC destes componentes.

Figura 45: Layout físico da arquitetura coprocessador.

70

Figura 46: Layout físico da arquitetura serial com SRAM interna.

Tabela 5: Resultados de síntese do codificador LDPC coprocessador.

Tipo de Célula Área (µm2) Leakage (nW) Consumo (nW)

Memórias 4.800 197 275.696

Registradores 2.187 65 786.923

Inversores 222 12 13.793

Buffers 22 2 4.801

Células 7.468 290 623.013

Total 14.701 567 1.704.228

Tabela 6: Resultados de síntese do codificador LDPC serial com SRAM interna.

Tipo de Célula Área (µm2) Leakage (nW) Consumo (nW)

Memórias 21.317 871 2.328.491

Registradores 1.514 46 526.183

Inversores 100 5 4.608

Buffers 3 0 822

Células 3.102 137 234.262

Total 26.038 1.061 3.094.368

71

A opção por arquiteturas usando abordagem serial traz grandes vantagens em

termos de custo de hardware, mas em contrapartida, torna a codificação mais lenta,

diminuindo a quantidade de bits codificados por ciclo de clock. Entretanto, para o padrão

IEEE 802.22 WRAN, a escolha deste tipo de arquitetura se mostrou acertada, já que, de

acordo com [8], a taxa de dados máxima é de 22,69 Mbps para uma taxa de código 5/6, e de

13,61 Mbps para uma taxa de código 1/2. Com frequência de 300 MHz, a taxa de dados de

informação codificada na arquitetura serial com SRAM interna é de 78,947 Mbps para a taxa

de código 5/6, e de 17,647 Mbps para a taxa de código 1/2. Por sua vez, para a arquitetura

coprocessador, a taxa de dados de informação codificada é de 236,065 Mbps para a taxa de

código 5/6, e de 324,324 Mbps para a taxa de código 1/2. Portanto, ambas as arquiteturas

propostas neste trabalho satisfazem, por larga margem, os requisitos do padrão.

Em comparação, o trabalho proposto em [30], que usa a decomposição LU como

base para codificação LDPC, voltada para o padrão CMMB (China Mobile Multimedia

Broadcasting – Sistema de Transmissão Terrestre Multimídia Chinês) [31], alcançou 32,44

Mbps na taxa de código 1/2 e 67,16 Mbps na taxa de código 3/4. O trabalho proposto em

[30] funciona apenas com estas duas taxas de código (1/2 e 3/4) e com tamanho de palavra

de código fixa, rodando a 200 MHz. Para alcançar seus objetivos, os autores implementaram

um pipeline de cinco estágios. Tal arquitetura foi prototipada em um FPGA Altera Stratix II

EP2S90. O protótipo usou 581 ALUTs (Adaptive Look-Up Table – Bloco de Memória/Tabela

de Pesquisa Adaptativa), 726 LEs (Logic Elements – Elementos Lógicos) equivalentes e

2.015.232 bits de memória. Embora a nossa arquitetura tenha sido sintetizada em ASIC, o

que torna difícil a comparação com FPGA, foi usada a relação entre FPGA System Gates e

portas NAND equivalentes. Baseando-se em [32], que estima a capacidade típica de portas

(FPGA System Gates) que podem ser implementadas por LEs, e no número de LEs

equivalentes (arquitetura baseada em LUT de 4 entradas) presentes em um dispositivo

Stratix [33], foi adotada a equivalência de 1 LE para 25 FPGA System Gates ou portas NAND

equivalentes em ASIC. Desse modo, foi estimado que a arquitetura proposta em [30]

consumiu o equivalente a 18.150 portas NAND e 2.015.232 bits de memória.

As arquiteturas apresentadas neste trabalho também foram comparadas com a

implementação paralela proposta em [34], referente a uma arquitetura de codificador LDPC

72

para o padrão IEEE 802.11n/ac de alto rendimento. Tal arquitetura usa acumuladores

com barrel-shifters em paralelo para executar os deslocamentos circulares e as somas,

durante iterações, enquanto que as arquiteturas apresentadas aqui não usam barrel-

shifters e usam apenas um acumulador. Para calcular os valores dos bits de paridade, após o

cálculo dos valores intermediários, a modelagem apresentada em [34] executa a soma de

todos os acumuladores em paralelo, simultaneamente, em apena um ciclo de clock. Por

outro lado, as nossas arquiteturas implementam a soma de maneira iterativa, serialmente,

sendo mais lentas que a apresentada em [34]. Contudo, a escolha por uma abordagem serial

se mostrou acertada e adequada ao padrão IEEE 802.22 WRAN, pois o rendimento é

suficiente e o consumo de área e potência são menores do que os apresentados em [34].

A Tabela 7 mostra uma comparação entre as arquiteturas propostas neste trabalho e

as descritas em [30] e em [34].

Tabela 7: Bits de memória e portas NAND equivalentes por arquitetura

Serial com SRAM Coprocessador [30] [34]

Bits de Memória 5.888 3.840 2.015.232 -

Portas Equivalentes 3.880 7.821 18.150 273.000

Embora os IPs tenham sido feitos considerando a frequência do sistema a que eles

estão inseridos, 300 MHz, a frequência mínima necessária para eles executarem a

codificação de canal para o IEEE 802.22 WRAN é menor. No caso da arquitetura serial com

SRAM interna, a frequência mínima é 231.370 MHz, e para a arquitetura coprocessador, a

frequência é 20.988 MHz. Essa diferença de frequência impacta no consumo energia do

circuito integrado, como podem ser visto nas Tabelas 8 e 9. Em todo caso, aplicando-se

técnica de clock gating, será possível fazer com que o circuito consuma menos energia

relativa a chaveamento dinâmico enquanto está ocioso, fazendo com que o consumo,

mesmo a 300 MHz, se aproxima do consumo na frequência menor.

73

Tabela 8: Comparação dos resultados de síntese da arquitetura serial com SRAM interna.

Frequência Área (µm2) Leakage (nW) Consumo (nW)

300 MHz 26.038 1.061 3.094.368

231.370 MHz 25.877 1.048 2.467.226

Tabela 9: Comparação dos resultados de síntese do codificador LDPC coprocessador.

Frequência Área (µm2) Leakage (nW) Consumo (nW)

300 MHz 14.701 567 1.704.228

20.988 MHz 14.107 521 140.214

74

8 CONCLUSÕES

Ao longo desta pesquisa, foram desenvolvidas duas arquiteturas seriais para

codificadores LDPC destinados ao padrão IEEE 802.22 WRAN. Uma das arquiteturas,

denominada coprocessador, foi desenvolvida como uma evolução da primeira arquitetura,

denominada serial com SRAM interna, a qual é completamente serial. Tal evolução foi

possível a partir de algumas otimizações.

O trabalho foi desenvolvido seguindo o fluxo completo para projetos de circuitos

integrados digitais, desde a modelagem do sistema em alto nível, passando pela etapas de

elaboração da arquitetura, implementação, verificação funcional, até a geração do GDSII.

Na parte final do trabalho, foi feita a comparação das arquiteturas propostas com

outras implementações de codificadores LDPCs, destinadas a outros padrões. Pode-se

concluir que a escolha de uma abordagem serial, para o padrão IEEE 802.22 WRAN, se

mostrou adequada, sendo que foi possível cumprir os requisitos de velocidade (throughput),

com menor consumo de área e potência frente às outras abordagens comparadas.

A inovação deste trabalho está centrada na proposta de arquiteturas serializadas

para o padrão IEEE 802.22 WRAN, o que foi possível através do adequado reordenamento

das equações presentes no algoritmo apresentado. Além disso, ambas arquiteturas atendem

à flexibilidade imposta pelo padrão, permitindo a execução de 84 modos de operação

distintos.

As arquiteturas apresentadas neste trabalho também mostraram eficácia quanto à

velocidade de processamento exigida pelo padrão. Mesmo adotando uma abordagem serial,

para todas as configurações possíveis, elas foram capazes de cumprir com os requisitos de

flexibilidade impostos pelo padrão, sem comprometer os custos em termos de hardware. Foi

possível construir codificadores LDPCs compatíveis com os 84 modos de operação distintos,

com consumo mínimo de área e potência.

Também foi verificado que a arquitetura coprocessador se mostrou mais eficiente

que a arquitetura totalmente serial com SRAM interna. Com a modelagem coprocessador foi

75

possível eliminar o uso de uma memória SRAM interna, assim como rearranjar os

componentes para executar a codificação de maneira mais rápida (até 13 vezes mais rápida),

consumindo menos área e energia.

Tais arquiteturas fazem parte de um projeto maior, de um processador de banda

base OFDMA (Orthogonal Frequency-Division Multiple Access – Múltiplo Acesso por Divisão

de Frequências Ortogonais), destinado ao padrão IEEE 802.22 WRAN, com núcleo

microprocessador. Nesse contexto, ainda há espaço para pesquisas futuras sobre a

modelagem de arquiteturas para decodificadores LDPCs com decisão suave (soft decision)

ou, ainda, o desenvolvimento de arquiteturas eficientes que apliquem técnicas de

decodificação LDPC e demodulação digital iterativas, que visem melhorar a qualidade da

detecção de símbolos IQ recebidos através de um canal AWGN (Additive White Gaussian

Noise – Ruído Branco Aditivo e Gaussiano).

76

9 REFERÊNCIAS BIBLIOGRÁFICAS

1. SHANNON, C. E. A Mathematical Theory of Communication. The Bell System Technical

Journal, n. 27, p. 623–656, Octobe 1948.

2. JOHNSON, S. J. Iterative Error Correction. 1ª Edição. ed. Edimburgo: Cambridge

University Press, 2009.

3. GALLAGER, R. G. Low-density parity-check codes. IRE Trans. Inf. Theory, v. IT-8, n. 1, p.

21-28, Jan. 1962.

4. MACKAY, D. J. C.; NEAL, R. M. Near Shannon limit performance of low density parity

check codes. Electron Lett, v. 32, p. 1645-1646, 1996.

5. WIBERG, N. Codes and Decoding on General Graphs. Ph.D. dissertation, Linkoping:

Linkoping Univ, 1996.

6. KARKOOTI, M.; RADOSAVLJEVIC, P.; CAVALLARO, J. R. Configurable, High Throughput,

Irregular LDPC Decoder Architecture: Tradeoff Analysis and Implementation. IEEE 17th

International Conference on Application-specific Systems, Architectures, and

Processors (ASAP), Sept. 2006. 360-367.

7. ENGLING YEO; BORIVOJE NIKOLIC; READ CHANNEL ARCHIT., STMICROELECTRON., SAN

DIEGO, CA. A 1.1-Gb/s 4092-bit Low-Density Parity-Check Decoder. Asian Solid-State

Circuits Conference, Nov. 2005. 237 – 240.

8. IEEE P802.16e/D12. Draft IEEE Standard for Local Metropolitan Area Networks. Part 16:

Air Interface for Fixed and Mobile Broadband Wireless Access Systems, Outubro 2005.

9. IEEE P802.11n/D10. ‘Draft IEEE Standard for Local Metropolitan networks– Specific

requirements. Part 11: Wireless LAN Medium Access Control (MAC), and Physical Layer

(PHY) specifications: Enhancements for Higher Throughput, Março 2006.

77

10. IEEE 802.22™.. Standard for Wireless Regional Area Networks Part 22: Cognitive

Wireless RAN Medium Access Control (MAC) and Physical Layer (PHY) specifications:

Policies and procedures for operation in the TV Bands, Julho 2011.

11. ZHONG, H.; ZHANG, T. Block-LDPC: a practical LDPC coding system design approach. IEEE

Trans. Circuits and Systems I: Fundamental Theory and Applications, v. 52, p. 766-775,

Abril 2005.

12. RICHARDSON, T.; URBANKE, R. Efficient encoding of low-density parity-check codes. IEEE

Trans. Inf. Theory, v. 47, n. 2, p. 638–656, Fevereiro 2001.

13. CAI, Z. et al. Efficient encoding of IEEE 802.11n LDPC codes. Electron. Lett, v. 42, n. 25, p.

1471–1472, 2006.

14. WYGLINSKI, A. M.; NEKOVEE, M.; HOU, T. Cognitive Radio Communications and

Networks. San Diego, CA: Elsevier Inc, 2010.

15. HUFFMAN, W. C.; PLESS, V. Fundamentals of Error-Correcting Codes. New York:

Cambridge University Press, v. I, 2003.

16. RICHARDSON, T.; URBANKE, R. Modern Coding Theory. 1ª. ed. Nova York: Cambridge

University Press, v. I, 2008.

17. LIN, S.; COSTELLO, D. J. Error Control Coding. 2ª. ed. Englewood Cliffs: Prentice Hall, v. I,

2004.

18. FEWER, C. P.; FLANAGAN, M. F.; FAGAN, A. D. A versatile variable rate LDPC codec

architecture. IEEE Trans. Circuits Syst. I, Reg. Papers, v. 54, n. 10, p. 2240 -2251, 2007.

19. WESTE, N. H. E.; HARRIS, D. M. CMOS VLSI Design: A Circuits and Systems Perspective.

4ª. ed. Boston - EUA: Addison Wesley, v. I, 2011.

20. SCHEFFER, L.; LAVAGNO, L.; MARTIN, G. EDA for IC System Design, Verification, and

Testing. 1ª. ed. Boca Raton-FL, EUA: CRC Press, v. I, 2006.

78

21. LAVAGNO, L.; SCHEFFER, L.; MARTIN, G. EDA for IC Implementation, Circuit Design, and

Process Technology. 1ª. ed. Boca Raton-FL, EUA: CRC Press, v. I, 2006.

22. CHURIWALA, S.; GARG, S. Principles of VLSI RTL Design: A Practical Guide. 1ª. ed. New

York-NY, EUA: Springer, v. I, 2011.

23. LEE, P. Introduction to Place and Route Design in VLSIs. 1ª. ed. Raleigh-NC, EUA:

Lulu.com, v. I, 2007.

24. MEADE, K.; ROSENBERG, S. A Practical Guide to Adopting the Universal Verification

Methodology (Uvm). 2ª. ed. San Jose, CA, USA: Cadence Design Systems, Inc., v. I, 2013.

25. ACCELLERA. UVM Class Reference Manual. Napa, CA, EUA: Accellera Systems Initiative

Inc., v. 1.2, 2014. Disponivel em: <www.accellera.org>.

26. ACCELLERA; CADENCE; MENTOR; SYNOPSYS. UVM User Guide. Napa, CA, EUA: Accellera

Systems Initiative In., v. 1.2, 2011. Disponivel em: <www.accellera.org>.

27. DOULOS. SystemVerilog DPI Tutorial. Doulos, 2015. Disponivel em:

<https://www.doulos.com/knowhow/sysverilog/tutorial/dpi/>. Acesso em: 17 set. 2015.

28. PÉREZ, J. M.; FERNÁNDEZ, V. Low-cost encoding of IEEE 802.11n LDPC. Electron. Lett., v.

44, n. 4, p. 307–308, Julho 2008.

29. JUNG, Y.; JUNG, Y.; KIM, J. Memory-efficient and high-speed LDPC encoder. Electron.

Lett., v. 36, n. 14, p. 1035–1036, Julho 2010.

30. PENG, W.; YONG-EN, C. Low-complexity Real-time LDPC Encoder Design for CMMB.

International Conference on Intelligent Information Hiding and Multimedia Signal

Processing, 2008. 1209-1212.

31. CMMB. China Mobile Multimedia Broadcasting. Part 1: Framing Structure, Channel

Coding and Modulation for Broadcasting Channel, GY/T220. 1, 2006.

32. ALTERA CORPORATION. Gate Counting Methodology for APEX 20K Devices. Application

79

Note 110, v. 1.01, September 1999.

33. ALTERA CORPORATION. Introduction. Stratix II Device Family Data Sheet, Maio 2007.

34. JUNG, Y. et al. 7.7 Gbps encoder design for IEEE 802.11n/ac QC-LDPC codes.

International SoC Design Conference, Jeju Island, Coreia do Sul, Novembro 2012. 215 -

218.

80

10 ANEXOS

10.1 ANEXO A - ARTIGOS PUBLICADOS

Ao longo do desenvolvimento deste trabalho foram publicados cinco artigos

relacionados ao tema de projeto de circuitos integrados. Dentre eles, quatro estão ligados às

pesquisas envolvendo o padrão IEEE 802.22 WRAN, sendo dois deste relativos a

codificadores de canal LDPC.

Segue a lista dos artigos publicados:

Desenvolvimento e Implementação de uma Arquitetura de Codificação LDPC para o Padrão

IEEE 802.22 WRAN em ASIC 55nm;

o 20th IBERCHIP Workshop, Santiago, Chile, 2014.

VLSI Architecture Design and Implementation of a LDPC Encoder for the IEEE 802.22 WRAN

Standard;

o 25th PATMOS (International Workshop on Power And Timing Modeling, Optimization and

Simulation) Salvador, BA, 2015.

Implementação VLSI de uma Autocorrelação para Sincronização em receptores OFDM no

Padrão IEEE 802.22 WRAN;

o 20th IBERCHIP Workshop, Santiago, Chile, 2014.

Hardware Implementation of an OFDMA-WRAN Auto-correlation;

o 5th WCAS (Workshop on Circuits and System Design), Salvador, BA, 2015.

Proposta de arquitetura de segmentação rápida de imagens por cores em FPGA;

o 20º CBA (Congresso Brasileiro de Automática), Belo Horizonte, MG, 2014.

PROGRAMA DE PÓS GRADUAÇÃO EM ENGENHARIA · PDF fileTabela 7: Bits de...

Documents

Transcript of PROGRAMA DE PÓS GRADUAÇÃO EM ENGENHARIA · PDF fileTabela 7: Bits de...