Implementação de codificador LDPC para padrão IEEE 802.22 WRAN em ASIC

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
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 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
F383 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, 2015.
105 f. : il. color.
Orientador: Prof. Dr. Wagner Luiz Alves de Oliveira.
Dissertação (Mestrado) – Universidade Federal da Bahia.
Escola Politécnica, 2015.
1. Codificação de canal. 2. Padrão IEEE 802.22. 3. Circuitos
integrados digitais. I. Oliveira, Wagner Luiz Alves de. II.
Universidade Federal da Bahia. III. Título.
CDD: 621.381

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

xix
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

xxi
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)

xxii
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)

xxiii
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

xxiv
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
Referências Bibliográficas.........................................................................................................76
Anexos ......................................................................................................................................81
Anexo A – Artigos Publicados.................................................................................81

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- Transfer

3
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, 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. Este tipo
Rural
Vila
64-QAM
20 km
16-QAM
23 km
QPSK
30 km

5
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
6, 7 ou 8 MHz. No processamento para a transmissão, os dados são codificados através de um
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
<60 GHs
54-862
Frequência

6
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 flexibilidade
do codificador para obter o melhor desempenho possível (isto é, a maior taxa de dados),
CodificaçãodeCanal
-scrambler
-encoder
-puncturer
-bitinterleaver
Mapeamentode
ConstelaçãoDigital
Alocaçãode
Subportadora
Inserçãode
Piloto
IFFT
InserçãodePrefixo
Cíclico
Inserção de
Preâmbulo
D/A
Decodificaçãode
Canal
Detecçãode
ConstelaçãoDigital
Desalocaçãode
Subportadora
FFT
A/D
Sincronizadore
Remoçãode
PrefixoCíclico
Estimaçãode
Canale
Equalização
DadoRecuperadoDadoBinário
SinalOFDM
TransmitidoSinalOFDM
Recebido

7
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 −1 , , 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 , ( = 96) para uma palavra de código de tamanho = ∗ , = 24 ∗ 96, =
2304. 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)
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
zn
k
n z
k

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 = [ 1 1 1 1 1],
desde que se satisfaça a equação . = 0 no campo de Galois GF(2), conforme equação (2).
. = [ 1 1 1 1 1] × = + + + + = 0 (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 . = [0 0 0] devem
ser satisfeitas pela palavra de código, conforme equação (4).
=
1 0 1 0 0 0 0 1
0 1 0 1 0 1 0 0
1 0 0 0 1 0 1 0
(3)
. =
1 0 1 0 0 0 0 1
0 1 0 1 0 1 0 0
1 0 0 0 1 0 1 0
× =
0
0
0
→
+ + = 0,
+ + = 0,
+ + = 0
(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 . = [0], onde [0] é 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 2 mensagens possíveis, assim como 2 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 (2, 4) − . 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.
=
1 0 1 0 0 0 1 1
0 1 0 0 1 1 0 1
1 0 1 1 0 1 0 0
0 1 0 1 1 0 1 0
(5)
=
1 0 1 0 0 1 0 1
0 1 0 1 1 1 0 1
1 0 0 1 0 1 0 0
(6)
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

15
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 ( , = 1 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 (2, 4) − 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 . = 0. 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 . = 0. Para proceder com a codificação é
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

17
somam aos bits de informação para compor a palavra de código = [ , ], conforme descrito
pela equação (7).
. →
+ + = 0,
+ + = 0,
+ + = 0
→
= + ,
= + ,
= +
(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 . = 0. 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].
. = → [ ] ×
1 0 0 0 0 0 1 1
0 1 0 0 0 1 0 0
0 0 1 0 0 0 0 1
0 0 0 1 0 1 0 0
0 0 0 0 1 0 1 0
= [ ]
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
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].
(8)

18
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 − 1 < < 0), e a parte em cinza claro é uma
matriz diagonal dupla, cujo valor de cada elemento é ‘1’ para = e = + 1, 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 . = 0,
. = 0, equação (9), pode-se inferir as equações (10), (11), (12) e (13).

19
, ,
, ,
⋯
⋯
, 0 −1 ⋯ −1
, 0 0 ⋯ −1
⋮ ⋮
, ,
⋯
⋯
⋮ ⋮
, −1
⋮ ⋮ ⋮
⋯ 0 −1
⋮ ⋮
, ,
⋯
⋯
⋮ ⋮
, −1
⋮ ⋮ ⋮
⋯ −1 0
×
⋮
⋮
= 0
(9)
∑ , . + , . + = 0, = 0 (10)
∑ , . + + = 0, ≠ 0, , − 1 (11)
∑ , . + + + = 0, = (12)
∑ , . + , . + = 0, = − 1 (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)
= λ + , ≠ 0, , − 1 (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 , . = 0 sempre que , = −1 (matriz
zero), é possível generalizar as equações (18) e (19) em (21).
= + λ + , . , = 1: − 2 (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
GDSIIVerificação Física
(DRC e LVS)
Verificação
Funcional
Verificação
Funcional
Verificação
Funcional
V
e
r
i
f
i
c
a
ç
ã
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
FrontendBackend

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 comunicação sem
Microarquitetura
Especificação
Simulação do
Sistema
Simulação do
Sistema

24
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 ou VHDL
Projeto RTL
Síntese Lógica
Verificação
Funcional
Verificação
Funcional
Verificação
Formal

26
(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
GDSIIVerificação Física
(DRC e LVS)
Verificação
Funcional
V
e
r
i
f
i
c
a
ç
ã
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:
 A netlist em nível de portas lógicas codificada em HDL;

32
 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
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.

33
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.
A Figura 23 mostra uma planta de CI antes e após a atribuição de localização de células
padrão.
Bloco
B
RAM
DRAM
DP ROM
Bloco
A
Bloco
C
Bloco
B
RAM
DRAMDP ROM
Bloco
A
Bloco
C

34
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].
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
Células Padrão Macro Blocos
Pinos de
Entrada
e Saída
Fileiras

36
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
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; e
○ 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 . = 0 – 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 codificada).
Pij
kb
mb
nb
Hb2
hb
H'b1

53
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

Implementação de codificador LDPC para padrão IEEE 802.22 WRAN em ASIC

Implementação de codificador LDPC para padrão IEEE 802.22 WRAN em ASIC

Recommandé

Recommandé

Contenu connexe

Similaire à Implementação de codificador LDPC para padrão IEEE 802.22 WRAN em ASIC

Similaire à Implementação de codificador LDPC para padrão IEEE 802.22 WRAN em ASIC (20)

Implementação de codificador LDPC para padrão IEEE 802.22 WRAN em ASIC