PROGRAMA DE PÓS GRADUAÇÃO EM ENGENHARIA · PDF fileTabela 7: Bits de...
Transcript of PROGRAMA DE PÓS GRADUAÇÃO EM ENGENHARIA · PDF fileTabela 7: Bits de...
UNIVERSIDADE FEDERAL DA BAHIA
ESCOLA POLITÉCNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA ELÉTRICA
Nelson Alves Ferreira Neto
DESENVOLVIMENTO E IMPLEMENTAÇÃO DE UMA ARQUITETURA DE
CODIFICADOR DE CANAL LDPC (LOW-DENSITY PARITY-CHECK CODES)
PARA O PADRÃO IEEE 802.22 WRAN (SUPER WI-FI) EM ASIC
Dissertação de Mestrado
Salvador – BA – Brasil Dezembro de 2015
UNIVERSIDADE FEDERAL DA BAHIA
ESCOLA POLITÉCNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA ELÉTRICA
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
Ferreira Neto, Nelson Alves
Desenvolvimento e Implementação de uma Arquitetura de Codificador de Canal
LDPC (Low-Density Parity-Check Codes) para o Padrão IEEE 802.22 WRAN (Super Wi-Fi) em
ASIC / Nelson Alves Ferreira Neto. – Salvador: UFBA/PPGEE, 2015.
XXII, 83 p.: il; 29,7cm.
Orientador: Wagner Luiz Alves de Oliveira
Dissertação (mestrado) – UFBA/PPGEE/Programa de Pós-Graduação em Engenharia
Elétrica, 2015.
Referências Bibliográficas: p. 80 – 83
1. Codificação de Canal. 2. LDPC. 3. ASIC. 4. 802.22. 5. WRAN. I. Oliveira, Wagner Luiz Alves
de. II. Universidade Federal da Bahia, PPGEE, Programa de Pós-Graduação em Engenharia
Elétrica. III. Título.
iii
Desenvolvimento e Implementação de uma Arquitetura de Codificador de Canal LDPC
(Low-Density Parity-Check Codes) para o Padrão IEEE 802.22 WRAN (Super Wi-Fi) em ASIC.
Nelson Alves Ferreira Neto
Dissertação de Mestrado apresentada ao Programa de Pós-Graduação em Engenharia
Elétrica (PPGEE), da Escola Politécnica da Universidade Federal da Bahia (UFBA), como parte
dos requisitos necessários à obtenção do título de Mestre em Engenharia Elétrica.
Banca Examinadora:
Prof. Dr. Wagner Luiz Alves de Oliveira (Orientador)
Prof.ª Dr.ª Ana Isabela Araújo Cunha (Universidade Federal da Bahia)
Prof. Dr. Eduardo Furtado de Simas Filho (Universidade Federal da Bahia)
Prof. Dr. Elmar Uwe Kurt Melcher (Universidade Federal de Campina Grande)
Salvador – BA – Brasil Dezembro de 2015
iv
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.
vi
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!
viii
ix
"A mente que se abre a uma nova ideia jamais voltará ao seu tamanho original"
(Albert Einstein)
x
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
xii
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
xiv
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 6: Matriz Hb para taxa de código 2/3............................................................................... 8
Figura 7: Matriz Hb para taxa de código 3/4............................................................................... 8
Figura 8: Matriz Hb para taxa de código 5/6............................................................................... 9
Figura 9: Modelo de sistema de comunicação digital. ............................................................. 11
Figura 10: Grafo de Tanner para uma matriz H. ....................................................................... 15
Figura 11: Grafo de Tanner para código (2, 4)-regular. ............................................................ 16
Figura 12: Grafo de Tanner para código irregular. ................................................................... 16
Figura 13: Matriz base Hb para código LDPC Quase Cíclico. ..................................................... 18
Figura 14: Fluxo geral de projeto de circuito integrado digital dividido por fases. ................. 22
Figura 15: Projeto em nível de sistema. ................................................................................... 23
Figura 16: Projeto lógico. .......................................................................................................... 25
Figura 17: Projeto físico ou backend. ....................................................................................... 29
Figura 18: Floorplanning. .......................................................................................................... 29
xvi
Figura 19: Placement. ............................................................................................................... 30
Figura 20: Síntese de árvore de clock – CTS. ............................................................................ 30
Figura 21: Roteamento. ............................................................................................................ 31
Figura 22: Planta do circuito integrado definida no Floorplanning. ........................................ 33
Figura 23: Die sem células padrão e com Placement realizado. .............................................. 34
Figura 24: Layout do Placement. .............................................................................................. 35
Figura 25: Conexão de VDD e VSS. ........................................................................................... 36
Figura 26: Roteamento global. ................................................................................................. 37
Figura 27: Ambiente de verificação UVM. ................................................................................ 42
Figura 28: Comunicação entre monitor e collector. ................................................................. 46
Figura 29: UVC de interface típico. ........................................................................................... 47
Figura 30: Máquina de estados com o fluxo do processo de codificação LDPC. ..................... 51
Figura 31: Região útil da matriz Hb. ......................................................................................... 52
Figura 32: Diagrama de blocos da arquitetura serial. .............................................................. 53
Figura 33: Barrel-Shifter............................................................................................................ 54
Figura 34: Multiplexador. ......................................................................................................... 55
Figura 35: Diagrama de blocos da arquitetura coprocessador. ............................................... 57
Figura 36: Valores não nulos úteis da matriz Hb para taxa de código 1/2. .............................. 58
Figura 37: Conexão entre portas do driver e do sequencer. .................................................... 60
xvii
Figura 38: Driver seq_item_port conectado à porta seq_item_export do sequencer.............. 60
Figura 39: Ambiente de verificação para arquitetura serial. ................................................... 61
Figura 40: Comunicação entre monitor, collector e scoreboard. ............................................. 62
Figura 41: Monitor conectado à porta item_collected_export do scoreboard. ....................... 62
Figura 42: Ambiente de verificação para arquitetura coprocessador. .................................... 64
Figura 43: Sumário de verificação para arquitetura serial. ...................................................... 65
Figura 44: Sumário de verificação para arquitetura coprocessador. ....................................... 66
Figura 45: Layout físico da arquitetura coprocessador. ........................................................... 69
Figura 46: Layout físico da arquitetura serial com SRAM interna. ........................................... 70
xviii
LISTA DE TABELAS
Tabela 1: Tamanho de palavras de código e matrizes de permutação. ................................... 10
Tabela 2: Estimativa de recursos de hardware. ....................................................................... 55
Tabela 3: Endereço inicial de cada taxa de código ................................................................... 59
Tabela 4: Comparativo de resultados de síntese do codificador LDPC. ................................... 68
Tabela 5: Resultados de síntese do codificador LDPC coprocessador. .................................... 70
Tabela 6: Resultados de síntese do codificador LDPC serial com SRAM interna. .................... 70
Tabela 7: Bits de memória e portas NAND equivalentes por arquitetura ............................... 72
Tabela 8: Comparação dos resultados de síntese da arquitetura serial com SRAM interna. .. 74
Tabela 9: Comparação dos resultados de síntese do codificador LDPC coprocessador .......... 74
xix
xx
LISTA DE SIGLAS
ALUT – Adaptive Look-Up Table (Bloco de Memória/Tabela de Pesquisa Adaptativa)
ASIC – Application-Specific Integrated Circuit (Circuito Integrado de Aplicação Específica)
AVM – Advanced Verification Methodology (Metodologia Avançada de Verificação)
AWGN – Additive White Gaussian Noise (Ruído Branco Aditivo e Gaussiano)
BPSK – Binary Phase-Shift Keying (Modulação por Deslocamento de Fase Binário)
CTS – Clock Tree Synthesis (Síntese de Árvore de Clock)
DEF – Design Exchange Format (Formato de Intercâmbio de Projetos)
DUT – Design Under Test (Projeto sob Teste) / Device Under Test (Dispositivo sob Teste)
DUV – Design Under Verification (Projeto sob Verificação)
ERB – Estação Rádio Base
eRM – e Reuse Methodology (Metodologia e de Reuso)
FFT – Fast Fourier Transform (Transformada Rápida de Fourier)
FPGA – Field-Programmable Gate Array (Arranjo de Portas Programável no Local)
GDSII – Graphic Database System II (Sistema de Banco de Dados Gráfico II)
HDL – Hardware Description Language (Linguagem de Descrição de Hardware)
IFFT – Inverse Fast Fourier Transform (Transformada Rápida de Fourier Inversa)
IP-Core – Intellectual Property Core (Módulo de Propriedade Intelectual)
LDPC – Low-Density Parity-Check Codes
LE – Logic Element (Elemento Lógico)
LEC – Logic Equivalence Checking (Verificação de Equivalência Lógica)
MCU – Microprogrammed Control Unit (Unidade de Controle Microprogramada)
xxi
OFDM – Orthogonal Frequency Division Multiplexing (Multiplexação por Divisão de
Frequências Ortogonais)
OFDMA – Orthogonal Frequency Division Multiple Access (Múltiplo Acesso por Divisão de
Frequências Ortogonais)
OVM – Open Verification Methodology (Metodologia de Verificação Aberta)
QAM – Quadrature Amplitude Modulation (Modulação de Amplitude em Quadratura)
QPSK – Quadrature Phase-Shift Keying (Modulação por Deslocamento de Fase em
Quadratura)
BPSK – Binary Phase-Shift Keying (Modulação por Deslocamento de Fase Binário)
IQ – In-phase and Quadrature (Em Fase e Quadratura)
RTL – Register-Transfer Level (Nível de Transferência entre Registradores)
SDC – Synopsys Design Constraints
SoC – System-on-Chip (Sistema-num-Chip)
STA – Static Timing Analysis (Análise Estática de Tempo)
TDD – Time Division Duplex (Duplexação por Divisão de Tempo)
TLM – Transaction-Level Modeling (Modelagem em Nível de Transações)
URM – Universal Reuse Methodology (Metodologia Universal de Reuso)
UVC – UVM Verification Component (Componente de Verificação da UVM)
UVM – Universal Verification Methodology (Metodologia de Verificação Universal)
VHDL – VHSIC Hardware Description Language (Linguagem de Descrição de Hardware
VHSIC)
VHSIC – Very High Speed Integrated Circuit (Circuito Integrado de Velocidade Muito Alta)
VMM – Verification Methodology Manual (Manual de Metodologia de Verificação)
WRAN – Wireless Regional Area Network (Rede Regional Sem Fios)
xxii
SUMÁRIO
1 Introdução .......................................................................................................................... 1
2 IEEE 802.22 WRAN .............................................................................................................. 4
2.1 Estrutura das Matrizes de Verificação de Paridade ..................................................... 7
2.2 Redimensionamento de Valores em Hb ....................................................................... 9
3 Codificador de Canal LDPC ............................................................................................... 11
3.1 Codificação de Canal .................................................................................................. 11
3.2 Verificação de Paridade ............................................................................................. 12
3.3 Códigos LDPC ............................................................................................................. 14
3.4 Processo de Codificação LDPC ................................................................................... 16
3.5 O Algoritmo ................................................................................................................ 17
4 Fluxo de Projeto de Circuitos Integrados Digitais ............................................................ 21
4.1 Visão Geral do Fluxo de Projeto ................................................................................ 21
4.2 Projeto em nível de Sistema ...................................................................................... 23
4.2.1 Especificação ...................................................................................................... 23
4.2.2 Microarquitetura ................................................................................................ 24
4.3 Projeto Lógico ............................................................................................................ 25
4.3.1 RTL (Register-Transfer Level) .............................................................................. 25
4.3.2 Síntese Lógica ..................................................................................................... 26
4.3.3 Verificação Formal .............................................................................................. 27
4.4 Projeto Físico .............................................................................................................. 28
4.4.1 Floorplanning ...................................................................................................... 31
4.4.2 Placement ........................................................................................................... 33
4.4.3 Routing................................................................................................................ 36
xxiii
4.4.4 Scan-Reorder, CTS e Verificação Física ............................................................... 38
5 Universal Verification Methodology (UVM) ..................................................................... 40
5.1 A Biblioteca de Classes da UVM ................................................................................. 41
5.2 Bancos de Teste e Ambiente de Verificação em UVM .............................................. 41
5.2.1 UVC de Interface ................................................................................................. 43
5.2.2 Itens de Dados (Data Items) ............................................................................... 43
5.2.3 Direcionadores de Estímulos das Entradas (Drivers) .......................................... 44
5.2.4 Geradores de Estímulos (Sequencers e Sequences) ........................................... 44
5.2.5 Monitores (Monitors) ......................................................................................... 45
5.2.6 Coletores (Collectors) ......................................................................................... 45
5.2.7 Agentes (Agents) ................................................................................................ 46
5.2.8 Ambiente (Environment) .................................................................................... 46
6 Desenvolvimento do trabalho .......................................................................................... 48
6.1 Arquitetura ................................................................................................................. 50
6.1.1 Arquitetura Com SRAM Interna.......................................................................... 53
6.1.2 Arquitetura Coprocessador ................................................................................ 56
6.2 Verificação Funcional ................................................................................................. 59
7 Apresentação e análise de dados ..................................................................................... 67
8 Conclusões ........................................................................................................................ 74
9 Referências Bibliográficas ................................................................................................. 76
10 Anexos ........................................................................................................................... 80
10.1 Anexo A - Artigos Publicados ................................................................................. 80
1
1 INTRODUÇÃO
Em geral, a troca e o armazenamento de informações digitais estão sujeitos a perdas
e erros de conteúdo provocados pelos meios físicos utilizados. Nos sistemas digitais, desde o
armazenamento em memória até a comunicação sem fio, a exatidão das informações deve
ser garantida. Interferências nos meios físicos podem provocar alteração nos bits da
representação da informação, o que precisa ser detectado e corrigido.
A detecção e a correção de erros podem ser feitas através da inserção de
redundância, seja no processo de armazenamento de informação ou na transmissão da
mesma. Nos primeiros sistemas de comunicação digital acreditava-se que informações
poderiam ser transmitidas através um meio ruidoso, contornando os efeitos danosos do
canal sobre estas, apenas através do aumento da potência de transmissão. Essa visão foi
mudada fundamentalmente pelo trabalho de Shannon (1948) [1], o qual mostrou que
informações digitais poderiam ser transmitidas com relativa confiabilidade por um canal
ruidoso, por meio de codificação dos dados e adição prévia de código(s) de correção de
erro(s) (FEC – Forward Error Correction) no dispositivo transmissor, para posterior
decodificação no dispositivo receptor [2].
O processo de codificação de informação consiste em mapear um dado de K bits em
uma palavra de código de N bits. A taxa de codificação r = K / N indica a porção de dados
úteis contida na palavra de código. Mesmo que os bits na palavra de código sejam
parcialmente alterados, respeitando-se um dado limite, o algoritmo de decodificação será
capaz de recuperar a informação original sem prejuízo [2]. O processo é válido tanto para a
transmissão quanto para a recuperação de informações armazenadas.
Os padrões mais recentes de transmissão sem fio demandam uma alta taxa de
transferência de dados (throughput), o que exige bons algoritmos de codificação, detecção e
correção de erros, para evitar a retransmissão de dados corrompidos.
Códigos de verificação de paridade de baixa densidade e de correção antecipada de
erro LDPC (Low-Density Parity-Check) foram propostos por Gallager [3] em 1962, sendo
2
utilizados somente décadas depois por MacKay [4] e Wiberg [5]. Tais códigos estão entre os
melhores algoritmos de correção de erros conhecidos, os quais proveem excelente
desempenho de decodificação e alta taxa de tratamento de dados [6]. Esta categoria de
algoritmos permite operar próximo ao limite de Shannon [1], [6] e [7], razão pela qual tem
sido adotada por diversos padrões de comunicação recentes, tais como DVB-S2, 802.16e,
802.11n e 802.22 WRAN [8], [9] e [10].
Códigos LDPC são definidos por matrizes de verificação de paridade esparsas , as
quais podem ser representadas por um grafo de Tanner e usadas para decodificar as
informações recebidas por um canal. Porém, o processo de codificação direta é obtido
através da multiplicação da mensagem pela matriz geradora , a qual é obtida a partir de
e geralmente é densa, podendo tornar impraticável a implementação para códigos extensos
[11]. Entretanto, em [11] e [12] é proposta uma abordagem que permite realizar a
codificação usando a própria matriz . Felizmente, o código LDPC definido no padrão IEEE
802.22 WRAN (Wireless Regional Area Network) foi estruturado de maneira a poder tirar
proveito da modelagem baseada em blocos proposta em [11] e do algoritmo proposto em
[13], os quais permitem a implementação prática em hardware.
A flexibilidade imposta pelo padrão 802.22 ao LDPC exige que este possa operar em
21 tamanhos de palavra de código (situados na faixa de 384 a 2304) e quatro taxas de
codificação diferentes (1/2, 2/3, 3/4 e 5/6) [10], gerando uma quantidade de 84
configurações possíveis. Essa flexibilidade demanda o desenvolvimento de uma arquitetura
de hardware que possa operar de maneira eficiente, na taxa de dados exigida pelo padrão,
consumindo a pouca área e potência.
Neste trabalho foram desenvolvidas e implementadas duas arquiteturas flexíveis,
baseadas no algoritmo apresentado em [13], para o padrão IEEE 802.22 WRAN. Ambas as
soluções em hardware são compatíveis com as restrições definidas pelo padrão e podem
executar outros códigos sem a necessidade de serem sintetizados novamente, apenas
substituindo-se as memórias das matrizes .
A pesquisa aqui relatada foi desenvolvida em cinco etapas. A primeira correspondeu
à modelagem do sistema em C e MATLAB. Na segunda parte foi feita a descrição das
operações do circuito digital, em nível de transferência entre registradores (RTL – Register-
3
Transfer Level), através de linguagem de descrição de hardware (HDL – Hardware
Description Language). Em seguida foi feita a verificação funcional do RTL produzido. Na
quarta etapa o projeto passou por todo o fluxo para projetos de circuitos integrados digitais,
indo da síntese lógica ao arquivo GDSII (Graphic Database System II – Sistema de Banco de
Dados Gráfico II), na tecnologia VLSI 55 nm. E, por último, foi feita a comparação de
desempenho de potência e área, entre as arquiteturas propostas e as soluções
desenvolvidas para outros padrões similares.
Esta dissertação é organizada como segue: o segundo capítulo expõe uma visão geral
do padrão IEEE 802.22 WRAN e como são definidas as matrizes de verificação de paridade ,
assim como o processo de adequação a cada um dos tamanhos de palavras de código; o
terceiro capítulo introduz o tema de codificação de canal, apresenta o codificador LDPC, o
algoritmo proposto em [13] e mostra as alterações feitas para adequá-lo às nossas
arquiteturas; o quarto capítulo traz um estudo sobre o fluxo de projeto para circuitos
integrados digitais; o quinto capítulo introduz o framework UVM (Universal Verification
Methodology – Metodologia de Verificação Universal); o capítulo seis mostra as arquiteturas
desenvolvidas bem como a construção do ambiente de verificação e todo o
desenvolvimento relacionado; o sétimo capítulo apresenta e discute os resultados obtidos,
além de comparar as soluções deste trabalho com outras implementações; no oitavo
capítulo são expostas as conclusões; e finalmente, no nono capítulo, têm-se as referências
bibliográficas.
4
2 IEEE 802.22 WRAN
O padrão de rádio cognitivo IEEE 802.22 WRAN define o LDPC como um dos seus
possíveis codificadores de canal. Esse padrão é voltado para comunicação em zona de baixa
densidade populacional, tendo como aplicação típica o fornecimento de cobertura de banda
larga para áreas rurais e de difícil alcance por cabos. Suas células proveem um raio de
alcance médio de 30 km, podendo chegar a 100 km em condições específicas [10]. A Figura 1
mostra um exemplo de uma célula para o padrão IEEE 802.22 WRAN.
Figura 1: Célula IEEE 802.22 WRAN com estação ERB e terminais de usuário.
Este padrão foi desenvolvido para operar em uma topologia ponto-multiponto
(P2MP), sendo o sistema formado por uma estação rádio base (ERB) e terminais de usuários.
Nesse conjunto, cada terminal de usuário se liga à ERB através de um link sem fio, sendo tal
estação a responsável por controlar o acesso ao meio por parte dos respectivos terminais.
Rural
Vila
64-QAM
20 km
16-QAM
23 km
QPSK
30 km
5
Este tipo de rede se enquadra na categoria das RAN (Regional Area Network – Rede
Regional) ou WRAN. A Figura 2 mostra a distribuição dos tipos de rede de acordo com suas
características.
Figura 2: Tipos de rede e características.
O padrão 802.22 foi concebido para operar, de maneira não interferente, em faixas
de frequências destinadas à transmissão de TV analógica: 54 – 862 MHz, com canais de 6, 7
ou 8 MHz [14]. O 802.22 é o primeiro padrão de rádio cognitivo aprovado pelo IEEE. Uma das
características das suas células é a capacidade de executar sensoriamento cognitivo do
espectro, na faixa que está operando e em canais adjacentes. Para executar sensoriamento,
a ERB coordena os terminais de usuários, sincronizando-os quando podem transmitir e
quando devem apenas vasculhar os canais (para descobrir canal em uso por alguma TV).
Em nível de processamento banda-base, a camada física do padrão é baseada em
OFDM/OFDMA (Orthogonal Frequency Division Multiplexing/Multiple Access – Multiplexação
por Divisão de Frequências Ortogonais/Múltiplo Acesso), com largura de banda de canais de
IEEE 802.15
IEEE 802.11a
IEEE 802.11b/g/n
IEEE 802.16
IEEE 802.22
PAN
LAN
MA
RAN
Tipos de Rede
20-50m
10m
Até 100m
1-2km
30km
1 Mbps 10 Mbps
11-600 Mbps
54-280 Mbps
~22 Mbps
2,4 GHs
2,4 GHs
2,4-5
GHs
<60 GHs
54-862
MHs Frequência
6
6, 7 ou 8 MHz. No processamento para a transmissão, os dados são codificados através de
um codificador de canal LDPC e modulados digitalmente em QPSK (Quadrature Phase-Shift
Keying – Modulação por Deslocamento de Fase em Quadratura), 16-QAM (Quadrature
Amplitude Modulation – Modulação de Amplitude em Quadratura), 64-QAM ou BPSK (Binary
Phase-Shift Keying – Modulação por Deslocamento de Fase Binário), sendo os símbolos IQ
(In-phase and Quadrature – Em Fase e Quadratura) no domínio da frequência, resultantes
destas modulações, aplicados a uma IFFT (Inverse Fast Fourier Transform – Transformada
Rápida de Fourier Inversa) de 2048 pontos (subportadoras). Antes de serem transmitidos, os
símbolos IQ no domínio do tempo, resultantes da IFFT, são encapsulados em símbolos OFDM
que também englobam um prefixo cíclico de 1/4, 1/8, 1/16 ou 1/32 do tamanho da FFT (Fast
Fourier Transform – Transformada Rápida de Fourier). Para a recepção dos sinais, é feito o
processamento inverso. A comunicação é TDD (Time Division Duplex – Duplexação por
Divisão de Tempo). Um esboço do processamento de transmissão e recepção é mostrado na
Figura 3 [10].
Figura 3: Diagrama de processamento para transmissão e recepção.
Devido às características associadas à baixa densidade populacional e ao longo
alcance, as condições do canal podem variar significativamente, o que demanda uma alta
Codific
ação d
e C
anal
-scra
mble
r -e
ncoder
-punctu
rer
-bit in
terle
aver
Mapeam
ento
de
Conste
lação
Dig
ital
Alo
cação d
e
Subport
adora
Inserç
ão d
e
Pilo
to
IFF
T
Inserç
ão d
e P
refixo
Cíc
lico
Inserção de Preâmbulo
D/A
Decodific
ação d
e
Canal
Dete
cção d
e
Conste
lação
Dig
ital
Desalo
cação
de
Subport
adora
FF
T
A/D
Sin
cro
niz
ador
e
Rem
oção d
e
Pre
fixo C
íclic
o
Estim
ação d
e
Canal e
Equaliz
ação
Dado R
ecupera
do
D
ad
o B
iná
rio
Sin
al O
FD
M
Tra
nsm
itid
o
Sin
al O
FD
M
Recebid
o
7
flexibilidade do codificador para obter o melhor desempenho possível (isto é, a maior taxa
de dados), garantindo a redundância necessária para a recomposição da informação. Para
tanto, é usado um codificador de canal LDPC, que está entre os melhores algoritmos de
codificação e correção de erros conhecidos. Esta categoria de algoritmo permite operar
próximo ao limite de Shannon [7].
2.1 ESTRUTURA DAS MATRIZES DE VERIFICAÇÃO DE PARIDADE
Os códigos LDPCs são definidos através de matrizes de baixa densidade. Tais matrizes
podem ser usadas no cálculo das matrizes geradoras que permitem executar o processo de
codificação de forma direta ou, em alguns casos, serem usadas, as próprias, como base para
o algoritmo de codificação, dependendo da estrutura do código. No padrão 802.22, para
cada uma das taxas de código r = k/n (1/2, 2/3, 3/4 e 5/6), é definida uma matriz de
verificação de paridade de baixa densidade , de tamanho por , onde está associado
ao tamanho da palavra de código a ser transmitida, ao tamanho do vetor de verificação
de paridade e ao número de bits sistemáticos (mensagem a ser transmitida) [10].
As matrizes de verificação de paridade são estruturadas a partir de arranjos de
blocos lineares , conforme a Figura 4, sendo tais blocos matrizes de permutação ou
matriz nula de tamanho x . As matrizes são definidas através de matrizes base , de
tamanho x . As Figuras 5 a 8 mostram as matrizes definidas pelo padrão IEEEE
802.22 WRAN. Tais matrizes podem ser expandidas através da substituição de cada
elemento seu por uma matriz nula ou de permutação, onde e . O
processo de conversão da matriz em uma matriz é feito substituindo-se cada elemento
em por uma matriz quadrada de tamanho x . Quando o elemento na matriz base é
o valor , deverá ser uma matriz nula; nos demais casos, o valor do elemento
determinará que seja uma matriz identidade deslocada circularmente para direita por
tal valor [10].
8
[
]
Figura 4: Matriz H definida por conjuntos de matrizes de permutação ou zeros Pi,j.
Figura 5: Matriz Hb para taxa de código 1/2.
Figura 6: Matriz Hb para taxa de código 2/3.
Figura 7: Matriz Hb para taxa de código 3/4.
–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
Figura 8: Matriz Hb para taxa de código 5/6.
2.2 REDIMENSIONAMENTO DE VALORES EM HB
O padrão permite operar com 21 diferentes tamanhos de palavras de código.
Entretanto, todos os valores de deslocamento, definidos nas matrizes base do padrão IEEE
802.22 (Figuras 5 a 8), são determinados tendo como parâmetro o tamanho máximo de
matriz ( ) para uma palavra de código de tamanho , ,
. Assim, faz-se necessário equacionar a diferença entre os valores de
deslocamento fixados nas matrizes base e o tamanho das submatrizes de permutação .
Portanto, os tamanhos dos deslocamentos para menor que 96 – novos valores dos
elementos de , devem ser calculados aplicando a equação (1), sendo ⌊ ⌋ a operação floor
(arredondamento na direção de -∞). A Tabela 1 define os tamanhos de palavras de código ,
em bits, relativos ao tamanho das matrizes de permutação , sendo o tamanho, em
bytes, da informação de acordo com taxa de código escolhida.
{
⌊
⌋
(1)
1 25 55 –1 47 4 –1 91 84 8 86 52 82 33 5 0 36 20 4 77 80 0 –1 –1
–1 6 –1 36 40 47 12 79 47 –1 41 21 12 71 14 72 0 44 49 0 0 0 0 –1
51 81 83 4 67 –1 21 –1 31 24 91 61 81 9 86 78 60 88 67 15 –1 –1 0 0
50 –1 50 15 –1 36 13 10 11 20 53 90 29 92 57 30 84 92 11 66 80 –1 –1 0
H b2 H b1
10
Tabela 1: Tamanho de palavras de código e matrizes de permutação.
r =1/2 r =1/2 r =3/4 r =5/6 r =1/2 r =1/2 r =3/4 r =5/6
384 16 24 24 36 40 1440 60 90 120 135 150
480 20 30 30 45 50 1536 64 96 128 144 160
576 24 36 36 54 60 1632 68 102 136 153 170
672 28 42 42 63 70 1728 72 108 144 162 180
768 32 48 48 72 80 1824 76 114 152 171 190
864 36 54 72 81 90 1920 80 120 160 180 200
960 40 60 80 90 100 2016 84 126 168 189 210
1056 44 66 88 99 110 2112 88 132 176 198 220
1152 48 72 96 108 120 2208 92 138 184 207 230
1248 52 78 104 117 130 2304 96 144 192 216 240
1344 56 84 112 126 140
znk
n zk
11
3 CODIFICADOR DE CANAL LDPC
Os códigos de verificação de paridade de baixa densidade LDPC constituem uma
classe de códigos de correção de erro, proposta por Gallager em 1962 [3]. Neste capítulo
serão vistos os aspectos principais do processo de codificação LDPC, assim como do
algoritmo utilizado como base na execução deste trabalho.
3.1 CODIFICAÇÃO DE CANAL
O primeiro sistema de comunicação digital foi construído por volta de 1940 [2]. Até
então, acreditava-se que a única maneira para se transmitir informação através de um canal
de comunicação ruidoso era aumentando a potência do sinal, de modo a garantir uma
relação sinal-ruído suficientemente elevada [2]. No entanto, Shannon, em seu trabalho
publicado em 1948 [1], mostrou que é possível transmitir dados digitais com elevada
confiabilidade através de um canal ruidoso por meio da inserção de informações
redundantes – codificação prévia de informações com códigos de correção de erro, antes da
transmissão, para posterior decodificação dessas informações codificadas. Esse processo de
codificação de canal visa garantir que as informações sejam transmitidas através de meio
ruidoso e, posteriormente, possam ser reconstituídas – códigos detectores e corretores de
erro permitem a detecção e correção dos erros introduzidos, pelo canal de comunicação, na
informação, entre a transmissão e a recepção [15]. A Figura 9 mostra um modelo de sistema
de comunicação digital.
Figura 9: Modelo de sistema de comunicação digital.
Codificação de Canal
Modulador
Demodulador Decodificação
de Canal
Informação Original
Informação Recebida
12
Um canal pode apresentar uma série de imperfeições, tais como ruídos, distorções,
interferências e desvanecimentos, dentre outras, que dificultam a correta interpretação e
reprodução das informações transmitidas. Para ser possível detectar e corrigir erros, são
adicionados bits redundantes à informação. Do lado do transmissor, as informações digitais,
contendo bits, são codificadas em palavras de código com bits. Os dados extras são
usados para verificar a consistência das informações que chegam ao receptor, para
determinar se estas foram corrompidas ou não e, em caso de corrompimento, permitir
restaurar a informação original. A relação entre o tamanho da mensagem, , e o tamanho
da palavra de código , , é denominada taxa de código [2] ou taxa de informação
[15], representando o total de informação utilizável dentro da palavra de código transmitida.
3.2 VERIFICAÇÃO DE PARIDADE
A ideia central por trás do código de correção de erro é conseguir aumentar a
quantidade de informação que pode ser transmitida através de um canal ruidoso. Para tal, é
feito o cálculo e a introdução de dados extras (as chamadas paridades), para serem
transmitidos junto à informação desejada (a mensagem). O conjunto mensagem mais
paridade forma a denominada palavra de código (codeword).
Considerando a informação binária e a palavra de código
, composta pela informação e o bit de paridade, é possível validar se a
palavra de código recebida está correta usando o vetor de verificação de paridade
, desde que se satisfaça a equação no campo de Galois GF(2),
conforme equação (2).
[
]
(2)
13
Entretanto, com a inserção de um bit de paridade, é possível detectar-se apenas um
número par de erros ocorrido na palavra transmitida, não sendo possível indicar ou corrigir
os bits modificados. Para detectar mais de um erro, é necessário aumentar a redundância
inserida na palavra de código, sendo que tal redundância deve obedecer a várias equações
de paridade, as quais são definidas por uma matriz de verificação de paridade.
Dadas uma palavra de código e a matriz de verificação
de paridade sendo a equação (3), todas as equações definidas por devem
ser satisfeitas pela palavra de código, conforme equação (4).
[
] (3)
[
]
[
]
[ ] {
(4)
Cada linha da matriz de verificação de paridade corresponde a uma equação de
verificação de paridade, enquanto que cada coluna relaciona-se a um bit da palavra de
código. Quando um elemento da matriz é ‘1’, o correspondente bit da palavra de código
é incluído na equação de paridade. Sendo assim, para um código com equações de
paridade e uma palavra de código de tamanho , tem-se uma matriz de verificação de
paridade, que descreve tal código, de tamanho x . Duas ou mais matrizes de paridade
podem descrever o mesmo código, desde que satisfaçam , onde é um vetor
coluna de tamanho , conforme pode ser visto em [2] e [16].
14
3.3 CÓDIGOS LDPC
Os códigos LDPC são códigos de blocos definidos por matrizes esparsas – matrizes de
verificação de paridade com um número reduzido de elementos não nulos. O fato das
matrizes serem esparsas permite que o processo de decodificação tenha complexidade
com crescimento linear [2]. Os códigos de blocos binários podem ser definidos como um
código que, a partir de uma palavra de informação , contendo bits, produza uma palavra
de código com bits. Para um dado existe mensagens possíveis, assim como
palavras de código de tamanho . Nesse processo de codificação, a palavra de código com
bits é sempre maior que a palavra de bits sistemática (mensagem) de tamanho [17].
Os códigos LDPC podem ser classificados como regulares ou irregulares. Quando são
regulares, as matrizes esparsas que os representam têm um número fixo de elementos não
nulos por coluna, , e linha, , , ou em outras palavras, cada bit da
palavra de código participa em um número fixo de equações de verificação de paridade ,
e cada equação faz uso de um número fixo de bits de código [2]. A equação (5) mostra
um exemplo de matriz para um código . Por outro lado quando os
códigos são irregulares, não há valores fixos que descrevam a quantas equações um
bit da palavra de código possa participar ou vice-versa – matrizes que representam tais
códigos não tem número fixo de elementos não nulos em linha e colunas (eles obedecem a
alguma distribuição [16]). A equação (6) mostra um exemplo de matriz para um código
irregular.
[
] (5)
[
] (6)
15
As matrizes de verificação de paridade que definem um código LDPC também podem
ser representadas por grafos de Tanner ou grafos bipartidos. Os grafos de Tanner são
compostos por dois conjuntos de nós: os nós de bits (ou variáveis), e os nós de paridade (ou
de verificação). Considerando uma matriz de tamanho x , há em um grafo bipartido
com nós de variáveis (correspondentes aos bits da palavra de código ) e (ou ) nós
de verificação (correspondentes às equações de paridade [16]). Dado uma matriz , o nó de
verificação irá se ligar ao nó de variável se o elemento não for nulo ( indica
que o nó de variável participa da equação ) – sendo assim, o número de arestas em um
grafo de Tanner é igual ao número de elementos ‘1’ em uma matriz de verificação de
paridade . A Figura 10 mostra um exemplo de grafo de Tanner para uma dada matriz .
Figura 10: Grafo de Tanner para uma matriz H.
Ainda sobre representação usando grafos, é possível notar que, para um dado código
, cada nó de bit terá “grau” e cada nó de verificação terá “grau” . A
Figura 11 mostra um exemplo de grafo de Tanner com grau 2 para nós de bit e grau 4 para
nós de verificação. Esse grafo representa o código definido pela matriz
na equação (5). Por outro lado, na Figura 12 temos um grafo que representa o código
irregular definido pela equação (6). Nesse grafo temos, por exemplo, o primeiro nó de bit
com grau 2, o segundo com grau 1 e o sexto com grau 3; também temos nós de verificação
com graus 5 e 3. O comportamento dos códigos LDPC pode ser melhorado quando estes
possuem nós com graus variados, obedecendo a alguma forma de distribuição [15].
Matriz de verificação de Paridade H
Nós de verificação ou paridade i
Nós de bit ou variável j
Grafo de Tanner
16
Figura 11: Grafo de Tanner para código (2, 4)-regular.
Figura 12: Grafo de Tanner para código irregular.
3.4 PROCESSO DE CODIFICAÇÃO LDPC
Uma matriz de verificação de paridade pode ser usada para definir um código
LDPC, ou seja, um conjunto de palavras de código válidas. Entretanto, no processo de
codificação é necessário gerar as palavras de código contendo mensagem e redundância. O
processo de codificação consiste em gerar um vetor contendo a palavra de código , a partir
de um vetor mensagem , onde . Nesse contexto, é uma palavra binária
contendo bits, é a palavra codificada resultante, com bits, e H é uma matriz de
verificação de paridade para um determinado código LDPC, sendo o seu tamanho x .
Na equação (4) foi mostrado um exemplo onde, partindo de uma palavra de código ,
é possível verificar se ela satisfaz a igualdade . Para proceder com a codificação é
17
necessário fazer o caminho inverso. É preciso, a partir dos bits da mensagem
que se quer transmitir, poder gerar os bits de paridade que
se somam aos bits de informação para compor a palavra de código , conforme
descrito pela equação (7).
{
{
(7)
As equações mostradas em (7) podem ser organizadas em uma matriz geradora ,
conforme equação (8). Sendo assim, é possível realizar a codificação LDPC usando a matriz
de tamanho x , onde e . No entanto, esse método pode se tornar
impraticável devido ao fato de normalmente ser uma matriz densa, fazendo com que o
codificador tenha complexidade , sendo o número de bits da palavra de código [2]
[18].
[ ]
3.5 O ALGORITMO
Para contornar o problema da codificação, ao invés de converter matrizes de
verificação de paridade em uma matriz geradora , as matrizes , de um código LDPC,
podem ser planejadas para permitir executar a codificação a partir delas próprias [2] – esse
(8)
18
tipo de código é chamado de LDPC Quase Cíclico. As matrizes de código definidas pelo
padrão IEEE 802.22 WRAN são desse tipo [10].
Tal como em [11] e [13], as matrizes para os códigos LDPC Quase Cíclicos do padrão
[10] são construídas por matrizes de permutação (matrizes identidade circularmente
deslocadas) ou matrizes nulas. A Figura 13 mostra um exemplo de matriz base para
código LDPC Quase Cíclico. Nela, os valores representam submatrizes (permutação ou
nula) de tamanho x .
[
]
Figura 13: Matriz base Hb para código LDPC Quase Cíclico.
Como pode ser observado nas Figuras 5 a 8, a estrutura das matrizes de verificação
de paridade, definida por matriz base , é dividida em duas seções, e , onde a
primeira coluna de , em tom de cinza mais escuro, contém apenas três matrizes de
permutação não nulas ( ,
e , com ), e a parte em cinza
claro é uma matriz diagonal dupla, cujo valor de cada elemento é ‘1’ para e ,
sendo e linhas e colunas, respectivamente. Essa peculiaridade das matrizes do padrão
IEEE 802.22 WRAN permite a aplicação do algoritmo de codificação de forma eficiente.
Considere a palavra de código como a concatenação dos vetores
mensagem e paridade , onde tem tamanho k e tem tamanho m (o vetor é gerado
pelo processo de codificação). Se for considerado o vetor subdividido em sequências
menores de tamanho z, , e for satisfeita a
igualdade , , equação (9), pode-se inferir as equações (10), (11), (12) e
(13).
19
[
]
[
]
(9)
∑
(10)
∑ (11)
∑ (12)
∑
(13)
Somando todas as equações de (10) a (13) em GF(2), obtém-se (14), que é usada para
encontrar . Se utilizarmos a definição da equação (15), é possível reescrever (14), (10),
(11), (12) e (13), como (16), (17), (18), (19) e (20), respectivamente, para se obter o vetor de
paridades.
∑ ∑
(14)
∑ (15)
∑ (16)
(17)
(18)
(19)
20
(20)
Note que a operação pode ser implementada como um deslocamento circular
para a esquerda sobre o vetor , , onde o elemento da matriz
define o valor do deslocamento. Considerando sempre que (matriz
zero), é possível generalizar as equações (18) e (19) em (21).
(21)
A chave para implementação de uma arquitetura de hardware que realize esse
algoritmo é manipular essas equações, de modo a rearranjá-las da maneira que mais
convém à arquitetura desejada.
21
4 FLUXO DE PROJETO DE CIRCUITOS INTEGRADOS DIGITAIS
Este capítulo descreve as etapas envolvidas no projeto de um circuito integrado
digital. Tal fluxo de projeto se divide em etapas de implementação (transformação em
diferentes formas de representação do circuito) e etapas de verificação (necessárias para
atestar o atendimento às especificações iniciais e a qualidade das transformações durante o
fluxo de implementação).
De modo geral, as etapas normalmente executadas no fluxo de projeto de um
circuito integrado digital são:
Especificação;
Descrição do hardware em RTL (Register-Transfer Level – Nível de Transferência entre
Registradores);
Síntese Lógica;
Verificação Funcional;
Foorplanning;
Placement;
Scan-Reorder;
CTS (Clock Tree Synthesis – Síntese de Árvore de Clock);
Roteamento;
Verificação Física;
Extração de Parasitas;
STA (Static Timing Analysis - Análise Estática de Tempo); e
Geração do arquivo de layout GDSII.
4.1 VISÃO GERAL DO FLUXO DE PROJETO
O fluxo de projeto de circuito integrado digital pode ser dividido em projeto físico,
projeto lógico e projeto em nível de sistema, sendo que em cada uma destas fases são
realizados os processos de implementação e verificação. Além disso, também há a divisão
22
clássica em dois grandes blocos de atividade: o frontend, que envolve toda a parte de
projeto lógico e de sistema, juntamente com a respectiva verificação; e o backend, que
corresponde à fase de implementação física [20] [21]. A Figura 14 mostra o fluxograma com
as subdivisões e fases de projeto para circuitos integrados digitais.
Figura 14: Fluxo geral de projeto de circuito integrado digital dividido por fases.
Projeto RTL
Síntese Lógica
Floorplanning
Placement
Scan Reorder CTS
Roteamento
GDSII Verificação Física (DRC e LVS)
Verificação Funcional
Verificação Funcional
Verificação Funcional
Verificação F
o
r
m
a
l RC
Extraction STA
Netlist DEF
Microarquitetura
Especificação
Simulação de Sistema
Simulação de Sistema
Projeto Físico
Projeto de Sistema
Projeto Lógico
Fron
tend
B
acken
d
23
4.2 PROJETO EM NÍVEL DE SISTEMA
Na fase de projeto em nível de sistema são determinados quais componentes de
hardware/software devem compor o CI, de forma que ele execute corretamente a função à
qual é destinado, consumindo a menor potência, área, tempo de execução e tempo de
projeto possível [20]. A fase de projeto em nível de sistema pode ser dividida basicamente
em especificação e microarquitetura, conforme Figura 15.
Figura 15: Projeto em nível de sistema.
4.2.1 Especificação
Em cada uma das etapas envolvidas no fluxo de projeto há um conjunto de artefatos
(documentos e/ou arquivos), os quais são usados como entrada ou podem ser gerados como
saída da etapa.
O ponto de partida para execução do fluxo é a especificação do sistema [19]. A
especificação do sistema pode ser composta por vários tipos de documentos, tais como
textos descritivos, gráficos, componentes de software (modelos em SystemVerilog, MATLAB,
C, C++, SystemC, etc.) e conjunto de normas que definam um novo padrão [20]. Na
especificação estão contidos os requisitos funcionais e não funcionais a serem satisfeitos,
tais como velocidade, memória, potência máxima consumida e tamanho máximo do die
(pastilha de silício onde o CI é fabricado), dentre outros. A especificação define o que deve
ser realizado pelo circuito integrado (processamento de banda base para um padrão de
Microarquitetura
Especificação
Simulação do Sistema
Simulação do Sistema
24
comunicação sem fio; codificação ou decodificação de áudio, vídeo ou algum tipo de
informação). Além disso, pode definir quais algoritmos podem ou devem ser usados.
Também na etapa de especificação do sistema podem ser realizadas simulações em
alto nível, para testar e validar os algoritmos envolvidos no processamento da informação.
4.2.2 Microarquitetura
A microarquitetura é responsável por definir como o RTL será desenvolvido. Ela parte
da extração de requisitos do projeto da especificação do sistema, entregando documentos
com textos e gráficos descritivos, os quais definem a arquitetura interna e interfaceamento
dos módulos de hardware.
Junto a textos e gráficos, também pode haver componentes de software que auxiliem
na definição da arquitetura [20]. Para cada bloco é definida uma microarquitetura, na qual
pode haver uma subdivisão em novos blocos que, por conseguinte, terão sua
microarquitetura detalhada. Nessa microarquitetura incluem-se dados como tamanhos de
barramentos, quantidade de bits em interfaces de controle, latência, paralelismos, pipelines,
tamanho exato de memórias, dentre outras características que orientarão a implementação
de tais blocos.
Enquanto na etapa de especificação os componentes de software são em alto nível,
na microarquitetura os componentes de software desenvolvidos funcionam como uma
espécie de simulação da arquitetura planejada. Em caso de filtros digitais, por exemplo, eles
são construídos considerando o tamanho das palavras, em ponto fixo ou ponto flutuante,
saturação ou estouro de resultado de operação, dentre outro fatores. Em muitos casos
esses componentes de software são usados como modelo de referência para a verificação
funcional do hardware.
25
4.3 PROJETO LÓGICO
O projeto lógico é composto por elaboração de RTL, verificação funcional e síntese
lógica. A etapa de verificação funcional, juntamente com a metodologia UVM, será descrita
em detalhes no capítulo 5.
Normalmente inclui-se no projeto lógico a primeira execução de verificação formal
ou de equivalência lógica LEC (Logic Equivalence Checking – Verificação de Equivalência
Lógica). Esse processo verifica se a netlist sintetizada é logicamente equivalente ao RTL
usado como entrada para a síntese [19]. O processo de verificação formal de equivalência
lógica pode e deve ser executado nas demais etapas que alteram a netlist.
Figura 16: Projeto lógico.
4.3.1 RTL (Register-Transfer Level)
O projeto do RTL consiste basicamente em transcrever a microarquitetura, escrita em
linguagem natural e diagrama de blocos, para uma HDL, de modo que a síntese lógica possa
ser executada.
A descrição em nível de transferência entre registradores (flip-flops) – RTL –
representa um nível de abstração abaixo da descrição comportamental do circuito e acima
da descrição presente em uma netlist em nível de portas lógicas. Entre os registradores, os
sinais ou dados são transferidos através de fios e lógicas combinacionais. Geralmente, o RTL
é escrito em alguma linguagem de descrição de hardware HDL (Hardware Description
Language – Linguagem de Descrição de Hardware), tal como Verilog, SystemVerilog, Chisel
Projeto RTL
Síntese Lógica Verificação Funcional
Verificação Funcional
Verificação Formal
26
ou VHDL (VHSIC Hardware Description Language – Linguagem de Descrição de Hardware
VHSIC), onde VHSIC quer dizer Very High Speed Integrated Circuit (Circuito Integrado de
Velocidade Muito Alta). As linguagens de descrição de hardwares mais usadas na construção
do RTL são Verilog e VHDL [22].
Um RTL bem desenvolvido facilita as etapas subsequentes do fluxo de projeto de
circuitos integrados digitais e permite acelerar o processo de construção do CI [22].
Dependendo do nível de documentação desejada e da complexidade do bloco em questão,
em alguns casos a microarquitetura e projeto de RTL podem ser realizados como uma única
atividade. Em todo caso, essa prática não é recomendada.
4.3.2 Síntese Lógica
As raízes da síntese lógica estão ligadas aos trabalhos do matemático George Boole
(1815-1865), no que hoje é chamado de álgebra booleana, e à descoberta de Shannon em
1938, mostrando que a álgebra booleana de dois valores pode descrever o funcionamento
de circuitos de comutação [21]. Nas últimas décadas houve muito progresso nesse campo, o
que tem proporcionado significativo impulso na produtividade de projeto de circuitos
integrados digitais. A capacidade de descrever e especificar projetos em níveis de abstração
mais altos tem permitido, aos times de projetistas, a utilização de um grande número de
transistores nos circuitos digitais atuais [21].
A síntese lógica é o processo pelo qual um circuito digital, descrito em um nível de
abstração alto (geralmente RTL), é convertido em uma netlist que descreve todos os
elementos combinacionais (portas lógicas simples e agregadas), sequenciais (flip-flops) e de
interconexão (fios) que representam logicamente o circuito desejado. Esse processo
costuma ser feito por ferramentas computacionais de síntese, as quais são capazes tanto de
gerar fluxos binários para configuração de dispositivos lógicos tais como FPGAs (Field-
Programmable Gate Array – Arranjo de Portas Programáveis no Local), quanto de gerar
netlists para criação de ASICs (Application-Specific Integrated Circuit – Circuito Integrado de
Aplicação Específica).
27
As ferramentas de síntese lógica assemelham-se a compiladores voltados para
componentes de hardware, capazes de mapear um código HDL para uma dada biblioteca de
células padrão, objetivando minimizar a área e potência consumida, assim como atender às
restrições de temporização. A síntese lógica produz circuitos que não são necessariamente
mais eficientes do que um projetado à mão, por um ser humano qualificado. Entretanto, ela
consegue lidar com uma quantidade de transistores que seria impraticável para uma pessoa
e, além do mais, os sintetizadores atuais são capazes de gerar netlists eficazes para a grande
maioria dos ASICs [19], em janelas de tempo muito mais curtas, o que favorece o
atendimento às restrições de custo de projeto e de disponibilização do produto no mercado
em janelas de tempo viáveis – o chamado time-to-market.
A etapa de síntese lógica recebe como entrada o RTL descrito em alguma HDL, os
arquivos com a descrição das temporizações das células padrão (formato Liberty – *.lib) e as
restrições de desempenho (área, consumo e tempo). Esse processo pode ser otimizado para
alcançar o menor consumo de energia, a menor área ou a maior velocidade. O resultado
desse processo tem como saída uma netlist em nível de portas lógicas e flip-flops disponíveis
na biblioteca adotada de células padrão.
As regras que definem como o circuito deve se comportar em relação à frequência de
operação e outras restrições do projeto físico são descritas no formato SDC (Synopsys Design
Constraints). Tais restrições permitem controlar atrasos de entradas e saídas, cargas nas
saídas, indicar se uma parte do circuito deve ter mais de ciclo de relógio para realizar suas
operações combinacionais, indicar tempos de transição de algum sinal, indicar caminhos
falsos de análise de tempo, dentre outras características.
4.3.3 Verificação Formal
Algumas vezes, devido a ambiguidades no RTL, o processo de síntese gera uma netlist
incorreta, a qual não condiz logicamente com a descrição funcional presente no RTL.
Idealmente isso não deve acontecer mas, caso aconteça, essa situação precisa ser detectada
e corrigida. Para tanto, pode-se refazer o processo de verificação funcional inicialmente
aplicado ao RTL, com a netlist gerada pela síntese, que descreve o circuito em nível de portas
28
lógicas e flip-flops [19]. Apesar desse processo alcançar resultados satisfatórios, geralmente
ele é desencorajado porque, dependendo da quantidade de testes realizados, o enorme
tempo requerido pode torná-lo impraticável.
A verificação formal de equivalência lógica consiste numa outra abordagem de
verificação e validação da netlist gerada pela síntese lógica, a qual busca atestar (ou não) a
equivalência lógica entre tal netlist e a descrição RTL usada como entrada no processo de
síntese lógica. Tal abordagem é capaz de provar matematicamente que ambas as descrições,
RTL e netlist em nível de portas lógicas, têm exatamente as mesmas funções booleanas [19].
Em outras palavras, a verificação formal de equivalência lógica é responsável por
comparar dois modelos e apontar se eles são equivalentes. Este procedimento serve tanto
para apontar se houve erros na síntese do RTL em netlist, quanto para apontar se, em
alguma das etapas intermediárias de projeto de CI, a netlist de saída não mais condiz com a
netlist de entrada [20].
4.4 PROJETO FÍSICO
O projeto físico ou backend consiste na fase do fluxo de projeto seguinte ao frontend
(projeto lógico). Esta fase engloba as etapas de Floorplanning, Placement, reordenamento de
cadeias de escaneamento (Scan-Reorder), síntese de árvore de clock (CTS) e roteamento
(Routing). Além dessas etapas, para garantir o correto funcionamento do CI, são executadas
um conjunto de verificações físicas, envolvendo as regras de projeto (DRC) e a disposição dos
elementos no circuito (LVS). Ainda seguindo com verificações físicas, é feito o cálculo das
resistências e capacitâncias parasitas existentes no circuito (RC Extraction), para alimentar a
base de dados utilizada nos cálculos de atrasos e tempo de propagação de sinais, necessária
à análise estática de tempo (STA) [21].
É no backend que a descrição dos componentes pertencentes a um projeto é
transformada em uma representação geométrica (arquivo no formato GDSII), contendo o
layout do CI que deverá ser fabricado. A Figura 17 mostra as etapas envolvidas no projeto
físico, enquanto as Figuras 18 a 21 mostram, respectivamente, os resultados obtidos após as
etapas de Floorplanning, Placement, CTS e roteamento (Routing) de um projeto físico.
29
Figura 17: Projeto físico ou backend.
Figura 18: Floorplanning.
Floorplanning
Placement
Scan Reorder CTS
Roteamento
GDSII Verificação Física (DRC e LVS)
Verificação Funcional
Verificação F
o
r
m
a
l RC
Extraction STA
Netlist DEF
30
Figura 19: Placement.
Figura 20: Síntese de árvore de clock – CTS.
31
Figura 21: Roteamento.
4.4.1 Floorplanning
O projeto físico começa na etapa de Floorplanning com o planejamento da planta
baixa do circuito integrado. O Floorplanning estima a área dos blocos que compõem o
circuito integrado e define o posicionamento dos mesmos. Além disso, nessa etapa também
são feitos o planejamento de alimentação de energia (Power Planning), a atribuição de pinos
e a fixação de memórias e macros [19]. O Floorplanning pode determinar se o projeto irá
caber dentro da área planejada para o CI, além de permitir estimar a extensão de
congestionamento de fios (isto é, a viabilidade futura do roteamento).
Geralmente é recomendado que se faça um Floorplanning preliminar para estimar, o
quanto antes, se o tamanho da lógica está de acordo com o especificado, servindo de
feedback para os projetistas. Desta forma, a execução de um Floorplanning preliminar
possibilita indicar que a microarquitetura de um projeto deva ser alterada, de modo a
diminuir a lógica e permitir que o projeto seja acomodado na área disponível para ele [19].
A etapa de Floorplanning recebe como entradas:
32
A netlist em nível de portas lógicas codificada em HDL;
As restrições da netlist no formato SDC – Synopsys Design Constraints;
As bibliotecas físicas no formato LEF (Library Exchange Format – Formato de Intercâmbio
de Bibliotecas);
As bibliotecas lógicas no formato Liberty (.lib), com informações de temporização e
consumo das células e memórias; e
Os scripts com restrições e diretivas para execução dessa etapa.
Por outro lado, como saída, o Floorplanning gera:
Arquivo no formato DEF (Design Exchange Format – Formato de Intercâmbio de Projetos),
usado para representar as conexões e o layout físico.
O arquivo DEF contém, inicialmente, as informações geradas no Floorplanning,
armazenando as descrições de aspectos físicos do projeto, tais como tamanho da pastilha de
silício (die), localização dos módulos e representação física dos pinos. Aapós as demais
etapas, tal arquivo é incrementado, passando a conter, por exemplo, a localização física das
células).
Por sua vez, as bibliotecas LEF encapsulam informações físicas das células e do
processo adotado. Algumas das informações contidas num arquivo LEF referem-se à
tecnologia e ao roteamento de metais, além dos formatos físicos das células. Além destas,
também há as bibliotecas Liberty, responsáveis por armazenar informações de atrasos e
consumo para as células padrão da tecnologia.
Para garantir que a planta definida para o circuito permita o roteamento e atenda
aos requisitos de utilização de área do die, assim como o tempo mínimo de propagação dos
sinais, o planejamento do Floorplanning tenta minimizar as distâncias entre as entradas e
saídas dos blocos que se comunicam. Além disso, devem ser feitas verificações prévias de
congestionamento de roteamento, de utilização de blocos e do plano de alimentação [19].
A Figura 22 mostra a planta de um circuito integrado, onde há três blocos A, B e C,
ligados entre si, a macroblocos de memória e a alguns pinos de entrada e saída. Pode-se ver
33
que, nesse exemplo, o Floorplanning define a posição dos blocos de modo a diminuir o
comprimento dos fios entre suas entras e saídas.
Figura 22: Planta do circuito integrado definida no Floorplanning.
4.4.2 Placement
O Placement é um passo essencial no backend. É nessa etapa que as células padrão e
as macros são colocadas dentro do layout do circuito inicialmente definido no Floorplanning
– ou seja, é feita a definição das localizações exatas dos componentes do circuito integrado.
A qualidade do Placement poderá afetar a desempenho ou inviabilizar o roteamento
e, por conseguinte, o CI. Sendo assim, o Placement considera os seguintes objetivos,
enquanto define a posições das células e macros [21]:
Comprimento total dos fios;
Temporização (atrasos);
Congestionamento; e
Consumo.
Bloco
B
RAM
DRAM
DP ROM
Bloco
A
Bloco
C
Bloco
B
RAM
DRAM DP ROM
Bloco
A
Bloco
C
34
A Figura 23 mostra uma planta de CI antes e após a atribuição de localização de
células padrão.
Figura 23: Die sem células padrão e com Placement realizado.
O Placement recebe como entradas:
A netlist do circuito sintetizado;
As definições do Floorplanning (arquivo DEF);
As bibliotecas tecnológicas (LEF e Liberty);
As restrições de tempo no formato SDC; e
Os scripts com restrições e diretivas para execução dessa etapa.
As saídas geradas pelo Placement são:
Netlist otimizada do projeto; e
Layout (arquivo DEF) com as células atribuídas aos devidos locais, de forma otimizada.
Nesse processo, a área do die é composta por fileiras de altura fixa, onde cada fileira
é composta por um número definido de posições (sites) que podem ser ocupadas por células
padrão, macros ou pinos de entrada e saída. As células padrão geralmente costumam ter
altura padrão, mas larguras variadas (sempre múltiplo do tamanho dos sites). Já os demais
componentes podem ter tamanho variado de fileiras e sites [20]. Nas tecnologias mais
antigas, com poucos níveis de metal, as fileiras precisam estar separadas para permitir o
roteamento. Em todo caso, tais informações são definidas na biblioteca física LEF.
A Figura 24 mostra um exemplo de layout de Placement.
35
Figura 24: Layout do Placement.
Alguns blocos podem ter tido sua localização atribuída, pelo Floorplanning, a um
determinado local, mediante restrições de localização que podem ser classificadas desde as
mais severas até as mais relaxadas. Em casos de restrições de localização severas, no
processo de Placement, as células para tais blocos deverão ser atribuídas nestes locais. Já
nos casos de restrições relaxadas, as células serão atribuídas livremente no processo de
Placement [21].
De qualquer forma, ao fim do processo de Placement, as células estarão fixadas nas
devidas posições, com o arquivo DEF sendo atualizado para refletir esta nova configuração.
Tal arquivo será usado no roteamento do circuito integrado [19].
Células Padrão Macro Blocos
Pinos de
Entrada
e Saída
Fileiras
36
O problema com a estratégia de fazer o Placement antes do roteamento é que
trabalha-se com valores estimados. Informações precisas de tempo de propagação dos sinais
dentro do CI só serão calculadas, com real precisão, depois que o layout estiver completo –
tal precisão somente é obtida com a extração dos valores de resistências e capacitâncias
parasitas, as quais são inseridas durante o roteamento.
Neste contexto, se houver problema de temporização (isto é, se o circuito não
atender as restrições de velocidade), o processo de Placement deverá ser executado
novamente, já considerando as novas restrições de tempo calculadas. O Placement dirigido
por restrições de temporização dá prioridade às células situadas nos caminhos mais críticos
(maior atraso de propagação), para minimizar o atraso de propagação entre elas [19].
4.4.3 Routing
Uma vez que as células e macros foram inseridas no die, elas precisam ser
conectadas. Para tanto, é feito o roteamento (Routing) dos fios internos do circuito
integrado, conectando efetivamente os componentes do circuito entre si, de acordo com as
chamadas regras de projeto (Design Rules) definidas pelo fabricante (foundry).
Primeiro é necessário conectar os sinais de VDD e VSS na parte superior e inferior das
células padrão, conforme destacado na Figura 25.
Figura 25: Conexão de VDD e VSS.
37
Na sequência, é feito o roteamento dos sinais que conectam as macros, células
padrão e pinos de entrada e saída [23]. Como o processo de roteamento geralmente envolve
conexões entre milhares, e até milhões de células, para lidar com tal complexidade, usa-se a
estratégia de dividir para conquistar [20] [23].
Assim, a etapa de roteamento é subdividida em roteamento global e roteamento
detalhado. Durante o processo de roteamento global, os fios são mapeados para grandes
células globais de roteamento conhecidas como gcells, sem serem conectados (apenas é
feita uma estimativa de quantos fios atravessam cada gcell). Já no roteamento detalhado, o
processo é concluído com os fios efetivamente conectados aos pinos.
O roteamento global abstrai o problema de roteamento através da noção de canais
adjacentes ou células de roteamento global (gcell), contendo trilhas de roteamento,
conforme pode ser visto na Figura 26. Nesse cenário, se a densidade de fios em um canal for
muito alta, os fios podem ser movidos de um canal para outro [19].
Figura 26: Roteamento global.
Capacidade de roteamento horizontal de 9 trilhas
Capacidade de roteamento vertical de 9 trilhas.
gcell
38
O processo de roteamento global é mais rápido que o de roteamento detalhado. Ele
consegue prover uma ideia razoável das dificuldades que estarão envolvidas no processo de
roteamento detalhado. Isso é feito através de mapas de congestionamento e informações de
número de rotas atribuídas para cada gcell, comparado à suas respectivas capacidades [21].
Se não houver uma quantidade significativa de regiões congestionadas, o roteamento
detalhado será capaz de resolver o problema aplicando desvios de rota através de regiões
vizinhas, mas se a quantidades de gcells congestionadas for muito elevada, existe uma
chance razoável de o roteamento detalhado falhar [21].
Por sua vez, o roteamento detalhado é responsável por concluir o processo,
efetivamente fazendo a conexão dos sinais. Ele é responsável por resolver violações de
regras de projeto (Design Rules) e evitar acoplamento capacitivo (crosstalk) [19].
Além desses tipos de roteamento, também há possibilidade de se fazer um
roteamento experimental (Trial Route), para saber se o projeto é roteável. O Trial Route
executa os roteamentos global e detalhado de maneira rápida e sem muita precisão,
objetivando estimar valores de parasitas e congestionamentos. A estimação de parasitas cria
os fios e gera uma representação dos parasitas RC, de forma a permitir otimizações prévias e
uma análise de temporização mais realista. Por outro lado, a estimação de
congestionamentos permite verificar, de maneira prévia, se o projeto poderá ser roteado.
4.4.4 Scan-Reorder, CTS e Verificação Física
Na etapa de Síntese Lógica pode-se inserir cadeias de varredura de flip-flops – as
chamadas scan-chains. Tais cadeias correspondem a redes de fios traçadas entre os flip-flops
da netlist, de forma a permitir o teste lógico do circuito após o processo de fabricação.
Durante o Placement, a ordenação de uma cadeia de varredura de flip-flops pode ocorrer de
forma não otimizada, de tal modo que é necessária uma etapa de reordenamento de tais
cadeias de escaneamento – etapa denominada Scan-Reorder.
Além disso, quase em sua totalidade, os circuitos eletrônicos digitais usam um
sincronismo proporcionado por um sinal de clock. Assim, deve-se garantir a devida
39
sincronização desse sinal nos flip-flops com mínima diferença de fase. Para tal objetivo, faz-
se necessário a síntese de uma árvore de clock (etapa denominada CTS – Clock Tree
Syntesis), a qual geralmente é acompanhada de processos de otimização pré e pós-CTS. Uma
vez que a CTS está pronta, é feito o roteamento (Routing) do circuito.
Por fim, para garantir o funcionamento adequado do Circuito Integrado, é necessário
um conjunto de verificações e validações tais como:
Verificação Física: Etapa formada pelos processos de DRC e LVS. O DRC (Design Rule
Checking) verifica se as regras de projeto especificadas pela foundry estão sendo
seguidas, enquanto o LVS (Layout Versus Schematic) verifica se o resultado final – a
disposição dos elementos no circuito físico final (o layout), está de acordo com a netlist
que representa o projeto lógico;
RC Extraction: É o processo de cálculo das resistências e capacitâncias parasitas dos fios
que ligam as células elementares do circuito. Os dados de RC obtidos permitem calcular
atrasos de propagação de sinal com grande precisão; e
STA (Static Timing Analysis): Etapa que calcula cada atraso para fios e portas, permitindo
verificar se as restrições de tempo – setup e hold – estão sendo cumpridas.
Após todas as verificações e validações, é feita a geração do arquivo padrão GDSII.
40
5 UNIVERSAL VERIFICATION METHODOLOGY (UVM)
UVM (Universal Verification Methodology – Metodologia de Verificação Universal) é
uma metodologia padrão usada na verificação de projetos de circuitos integrados. Essa
metodologia define uma biblioteca de classes e busca sistematizar as melhores práticas para
verificação exaustiva e eficiente. Um dos princípios-chave da UVM é incentivar o uso e o
desenvolvimento de componentes de verificação reutilizáveis – os UVCs (UVM Verification
Components – Componentes de Verificação da UVM) [24].
Em geral, UVM pode ser usada para verificação tanto de blocos individuais quanto
para SoCs (System-on-Chip – Sistema-em-Chip) baseados em IP-Cores (Intellectual Property
Cores – Módulos de Propriedade Intelectual). Tais IP-Cores são núcleos de propriedade
intelectual, constituídos de blocos de lógica e/ou dados, os quais são usados como parte de
projetos de FPGAs ou ASICs.
Em termos de composição, a metodologia UVM utiliza conceitos do VMM
(Verification Methodology Manual – Manual de Metodologia de Verificação) e é baseada na
biblioteca OVM (Open Verification Methodology – Metodologia de Verificação Aberta), a
qual combinou AVM (Advanced Verification Methodology – Metodologia Avançada de
Verificação) com URM (Universal Reuse Methodology – Metodologia Universal de Reuso) e
conceitos do eRM (e Reuse Methodology - Metodologia e de Reuso) [25].
Dentre outras vantagens, a UVM é um padrão aberto da Accellera Systems Initiative
suportado pela maioria das ferramentas de simulação existentes no mercado, permitindo a
construção de um ambiente de verificação particionado em conjunto de itens de dados
(data items) e componentes, onde tais componentes apresentam um conjunto de funções
pré-construídas para auxiliar na tarefa de verificação. Ela provê uma infraestrutura
completa, incluindo classes de componentes, o que permite a geração de estímulos de
forma eficiente. A geração desses estímulos pode ser: estática, aleatória ou aleatória
direcionada conforme o estado atual do ambiente de teste – o chamado DUT/DUV
(Design/Device Under Test/ Verification – Projeto/Dispositivo sob Teste/Verificação).
41
5.1 A BIBLIOTECA DE CLASSES DA UVM
A biblioteca de classes da UVM possibilita o desenvolvimento de ambientes e
componentes de verificação em SystemVerilog bem construídos, escaláveis e reutilizáveis
[25]. Ela provê classes-base e macros que facilitam o desenvolvimento e o uso de ambientes
de verificação, dando suporte à depuração através de mensagens controladas pelo usuário,
além da disponibilização de uma infraestrutura de comunicação padrão entre os
componentes de verificação através de TLM (Transaction-Level Modeling – Modelagem em
Nível de Transações) – TLM é uma abordagem usada para modelagem de comunicação, em
alto nível, em sistemas digitais. Além disso, é possível construir ambientes de
verificação flexíveis, através da UVM Factory. Componentes podem ser encapsulados e
instanciados hierarquicamente, além de serem controlados através de um conjunto de fases
que inicializa, executa e completa cada teste [26] – tais fases podem ser estendidas de
acordo com as necessidades do projeto.
5.2 BANCOS DE TESTE E AMBIENTE DE VERIFICAÇÃO EM UVM
Um banco de testes (testbench) em UVM é composto de ambientes de verificação
(também conhecidos como componentes de verificação UVCs, os quais são disponibilizados
pela biblioteca de classes do padrão), controles adicionais e lógicas de verificação e de
cobertura.
Um componente de verificação (UVC) pode ser entendido como um ambiente de
verificação configurável, destinado a verificar um sistema completo ou parte dele. Cada UVC
obedece a uma arquitetura consistente composta por um conjunto de elementos, tais como
monitor, drivers e sequencer, dentre outros. Tais elementos, através de uma UVC de
interface, têm a função de estimular, verificar e coletar informações de cobertura do DUT –
um projeto ou protocolo específico sob verificação [26]. Em geral, há dois tipos básicos de
UVCs de interface: ponto a ponto, que tem apenas um transmissor mestre e um receptor
escravo, e de barramento, que pode ter múltiplos mestres e escravos, assim como,
opcionalmente, um árbitro e um monitor de barramento [24].
42
A Figura 27 mostra um exemplo de ambiente de verificação com três componentes
de verificação de interface (Barramento UVC, Periférico A UVC e Periférico B UVC). Esses
componentes podem ser armazenados em um repositório de UVCs e reutilizados em outros
ambientes de verificação. Os componentes de verificação de interface são instanciados e
configurados para o modo de operação desejado. O ambiente de verificação também
contém um sequenciador virtual (Virtual Sequencer) – mecanismo de múltiplos canais de
sequências – que sincroniza os dados enviados para interfaces diferentes, permitindo
controlar o ambiente para executar um determinado teste em particular [26].
Figura 27: Ambiente de verificação UVM.
43
5.2.1 UVC de Interface
Um componente de verificação de interface é um ambiente de verificação que
contém os seguintes elementos/componentes:
Itens de dados (Data Items);
Direcionadores de estímulos das entradas (Drivers);
Geradores de estímulos (Sequencers e Sequences);
Monitores de DUT (Monitors);
Coletores (Collectors);
Agentes (Agents); e
Ambiente (Environment).
Tais componentes são descritos brevemente nas seções seguintes. Observa-se que
pode ocorrer de um Agent não ser ativo e funcionar apenas como escravo, monitorando o
DUT – nesse caso não haverá Drivers e nem Sequencers.
5.2.2 Itens de Dados (Data Items)
Um item de dado (Data Item) é um objeto que contém os estímulos da transação, ou
seja, as entradas para o DUT. Um pacote de internet, uma instrução ou uma transação de
barramento podem ser modelados como um item de dado.
Os campos ou atributos de um Data Item são derivados diretamente da especificação
dos itens de dados que se quer modelar na transação. Por exemplo, para a verificação de um
codificador de canal LDPC, os campos podem ser bits sistemáticos (bits de informação), bits
de paridade, taxa de código e tamanho da palavra de código.
Os campos dos itens de dados podem ser gerados aleatoriamente de maneira
controlada com o uso de restrições (constraints) do SystemVerilog. Através de restrições
direcionadas para a geração aleatória, uma grande quantidade de testes relevantes podem
ser obtidos, maximizando a cobertura [26].
44
5.2.3 Direcionadores de Estímulos das Entradas (Drivers)
Um driver é um tipo de BFM (Bus Functional Model – Modelo Funcional de
Barramento), limitado às entradas do DUT. Considerado uma entidade ativa, é utilizado para
emular a lógica que estimula o DUT.
Geralmente, o driver recebe os itens de dados e os insere nas entradas do DUT. Para
coordenar o envio dos dados na temporização adequada, o driver fica observando as saídas
do DUT e as regras de protocolo que devem ser seguidas.
5.2.4 Geradores de Estímulos (Sequencers e Sequences)
Um sequenciador (sequencer)é um gerador de estímulos avançado que controla a
geração dos itens de dados (Data Items) enviados para o driver.
Por padrão, um sequencer se comporta como um gerador de estímulo simples, o qual
entrega um item de dados aleatório para o driver sempre que for requisitado. Com esse
comportamento básico, é possível fazer com que as restrições de geração aleatória,
inseridas na construção das classes de itens de dados (Data Items), controlem a distribuição
dos valores gerados [26].
Um sequencer controla a geração de estímulos aleatórios através da execução de
sequences. Uma sequence define uma sequência de transações significativa dentro da
verificação. Uma sequence pode ser usada para gerar um ou mais itens de dados aleatórios,
além de conter parâmetros e restrições adicionais de temporização [24].
Conjuntos sequencer/sequence têm a capacidade de controlar a geração do Data
Item de acordo com o estado atual do DUT, promover a sincronização em nível de sistema e
controlar várias interfaces simultaneamente. De forma complementar, várias sequences
podem ser combinadas para formar uma sequência de itens de dados mais complexa [24].
45
5.2.5 Monitores (Monitors)
Um monitor, ao contrário de um driver, é uma entidade passiva que observa os sinais
de entrada e saída do DUT, mas não interfere neles – apenas coleta informações de
cobertura e executa alguma forma de verificação de protocolo de sinais.
Os monitores são responsáveis por coletar transações (data items) e torná-las
disponíveis para outros componentes. Eles detectam a disponibilidade das informações nos
barramentos ou interfaces de E/S, capturam tais informações e estruturam os dados,
emitindo eventos para notificar outros componentes da disponibilidade de uma transação.
Além disso, os monitores também podem executar a verificação de algum protocolo
de comunicação do DUT. O monitor de um barramento trata de todos os sinais presentes no
barramento considerado (isto é, analisa todas as transações), ao passo que o monitor de um
agent trata apenas dos sinais e transações referentes a esse agent [26].
Monitores e drivers devem ser construídos separadamente, sem dependências entre
si. Para permitir que agents possam funcionar de modo passivo, monitores e drivers não
devem trocar informações diretamente entre si.
Em [24] é recomendado que as atividades do monitor sejam divididas em atividades
em nível de sinais e atividades em nível de transações. Nesse caso, as atividades de baixo
nível devem ser executadas por uma classe collector, explicada na sequência.
5.2.6 Coletores (Collectors)
O collector também é uma entidade passiva, assim como o monitor. Ele é responsável
por seguir um protocolo específico, de modo a capturar sinais numa interface, formando
transações. Uma porta de análise é usada para enviar as transações capturadas para o
monitor, onde a verificação de cobertura pode ser executada [24]. A Figura 28 mostra como
se dá a comunicação entre o monitor e o collector.
46
Figura 28: Comunicação entre monitor e collector.
5.2.7 Agentes (Agents)
Um agente é usado para agrupar, configurar e conectar sequencers, drivers e
monitores. Cada um desses componentes pode ser reutilizado de forma independente dos
demais – contudo, para reduzir o trabalho de descrição de testes e a necessidade de
conhecimento de particularidades de configuração de cada um desses componentes, a
metodologia UVM recomenda o agrupamento dos mesmos num componente mais abstrato
(o agent), o qual pode emular e verificar um DUT.
Um UVC pode conter um ou mais agentes. Os agentes que iniciam uma transação
com o DUT são chamados de mestres (ou agentes de transmissão), ao passo que os agentes
que apenas reagem a uma transação são chamados de escravos (ou agentes recebedores).
Deve ser possível configurar os agentes para trabalharem como componentes ativos ou
passivos [26].
5.2.8 Ambiente (Environment)
O environment (env) é o elemento hierárquico mais elevado (top) dos componentes
de verificação UVM. Ele pode conter um ou mais agentes.
O env permite configurar propriedades que permitem alterar sua topologia e
comportamento, de modo a permitir seu reuso. Por exemplo, o agente ativo que verifica o
47
codificador LDPC, de maneira independente, pode ser configurado para o modo passivo,
permitindo que este componente se integre à verificação macro do sistema de comunicação
do qual ele faz parte [24].
A Figura 29 mostra um UVC de interface padrão. Como pode ser visto, o componente
de verificação pode conter um monitor de barramento, o qual é responsável por executar as
atividades que não estão ligadas a um único agente. Nesse contexto, os monitores dos
agentes podem aproveitar os dados coletados pelo monitor de barramento [26].
Figura 29: UVC de interface típico.
48
6 DESENVOLVIMENTO DO TRABALHO
O projeto e a pesquisa propostos neste trabalho foram desenvolvidos em cinco
etapas.
A primeira etapa correspondeu à pesquisa e à modelagem do sistema em MATLAB e
C. Na segunda parte foi desenvolvida a arquitetura do projeto e a sua implementação RTL,
em linguagem de descrição de hardware Verilog. Na terceira fase foi construído o ambiente
de verificação funcional, a partir da metodologia UVM, usando a linguagem SystemVerilog,
tendo sido executada a verificação. Na quarta etapa o projeto passou pelo fluxo backend de
circuitos integrados digitais, da síntese lógica ao GDSII, em tecnologia VLSI de 55 nm. Na
quinta parte foi feita a comparação de desempenho de potência e área, em relação a
soluções desenvolvidas para outros padrões.
O detalhamento de cada etapa é dado na sequência.
● Primeira Etapa: Desenvolvimento do Sistema
○ Estudo de algoritmos existentes, avaliando-os quanto ao custo computacional e à
facilidade de adequação a uma arquitetura de hardware;
○ Estudo e pesquisa de soluções desenvolvidas para outros padrões que utilizam LDPC,
tais como DVB-S2 e IEEE 802.11n WLAN;
○ Levantamento de requisitos de desempenho (throughput) para o rádio cognitivo
especificado pelo padrão IEEE 802.22 WRAN;
○ Implementação do algoritmo em uma linguagem de alto nível (MATLAB e C/C++),
para validação de conceitos e uso como modelo de referência para a verificação
funcional; e
○ Modelagem e validação das arquiteturas em linguagem de alto nível.
49
● Segunda Etapa: RTL do Frontend
○ Codificação do sistema em RTL, através da HDL Verilog. Esse processo resulta numa
forma de descrição da operação do circuito digital, na qual o comportamento do
sistema é definido em termos do fluxo de sinais entre registradores e das operações
realizadas, mediante etapas de controle definidas através de pulsos de clock.
● Terceira Etapa: Verificação Funcional
○ Desenvolvimento do ambiente de verificação funcional em UVM. Tal ambiente
incluiu os seguintes componentes:
Agents: usados para integrar os monitors, drivers, sequencers e suas
configurações;
Drivers: usados para emular o protocolo de acesso ao DUT (RTL a ser
verificado);
Monitors e Collectors: entidades passivas usadas para fazer a amostragem
dos sinais enviados ao DUT;
Sequencers: responsável por gerar data itens para os drivers;
Data itens: responsável por transportar os dados de cada transação para o
DUT; e
Scoreboard: módulo responsável por fazer a validação funcional dos dados
coletados do DUT, assim como a interface entre o modelo de referência (em
C/C++) com o ambiente UVM (em SystemVerilog).
○ Verificação das funcionalidades do RTL, através do uso do ambiente UVM
desenvolvido, para simular as situações de uso do hardware e verificar se este
funciona conforme o esperado; e
○ Verificação do protocolo de comunicação.
50
● Quarta Etapa: Fluxo ASIC
○ Síntese Lógica
○ Verificação Formal
○ Floorplanning
○ Placement
○ Scan-Reorder
○ CTS (Clock Tree Synthesis)
○ Routing
○ Verificação Física
○ RC Extraction
○ STA, DRC e LVS
○ Geração de GDSII
6.1 ARQUITETURA
Duas arquiteturas foram modeladas e implementadas para executar a codificação
requerida, através das etapas definidas nas equações (15), (16), (20) e (21), de forma
otimizada.
No início da execução, os valores intermediários são
calculados de acordo com a equação (15) e armazenados temporariamente.
Enquanto cada é calculado, ele é acumulado para compor o primeiro bloco de
paridade – equação (16), sendo salvo na memória. Fisicamente, os valores são salvos
nas posições reservadas para os blocos de paridade . A cada calculado, o respectivo é
descartado da memória.
Na sequência, o último bloco de paridade é calculado. Para executar esse
procedimento, é necessário ter o primeiro bloco de paridade e o último valor
intermediário prontos, para aplicá-los à equação (20).
Por fim, a equação (21) pode ser aplicada para calcular as demais paridades.
51
A chave para a modelagem de arquiteturas para codificadores LDPC, que usam a
matriz base de código de verificação de paridade , é manipular as equações que
satisfaçam a igualdade – equação (9) – de modo que as expressões resultantes se
adequem ao hardware que se quer implementar.
A partir do rearranjo de algumas expressões, foi possível inferir a equação (21). Tal
expressão permitiu calcular a paridade do final para o início, indo de até . Também
foi possível balancear o cálculo de blocos de paridade de modo que, a cada nova paridade
calculada, o respectivo valor temporário pudesse ser descartado. Além dessas
otimizações, a escolha em calcular os blocos de paridade de maneira decrescente,
possibilitou que o último valor a ser calculado em (15) , fosse o primeiro usado em
(20), permitindo que esse valor temporário não precisasse ser armazenado e lido da
memória.
O fluxo geral de execução das arquiteturas produzidas é definido pela máquina de
estados finita mostrada na Figura 30. No estado WAIT o sistema está aguardando um
comando externo – quando uma nova configuração chega, o sistema vai para o estado
START. No START, o hardware é inicializado com as configurações recebidas.
Figura 30: Máquina de estados com o fluxo do processo de codificação LDPC.
52
O estado SOMA LINHAS executa o processo de varrer uma linha em e o vetor
informação , bloco a bloco, fazendo com que cada bloco seja deslocado circularmente
para a esquerda, pelo valor em , e acumulado no registrador de trabalho. A matriz é
uma submatriz da matriz , conforme pode ser visto na Figura 31. Tal submatriz fica
armazenada em uma ROM.
Figura 31: Região útil da matriz Hb.
Ao final do processamento de SOMA LINHAS, obtém-se o valor intermediário , o
qual é guardado na memória reservada para e acumulado na posição de . Esse
procedimento ocorre no estado GUARDA E ACUMULA. O processo iterativo entre os estados
SOMA LINHAS e GUARDA E ACUMULA é feito até que todas as linhas tenham sido
percorridas – equações (15) e (16). No final, tem-se os valores intermediários armazenados e
o bloco de paridade zero calculado.
Uma vez que está pronto, o estado CALCULA ÚLTIMA PARIDADE controla o
cálculo de , equação (20), onde é deslocado circularmente para a esquerda pelo
valor (linha em ) – Figura 31 – e somado com o valor intermediário
, já guardado na posição de memória .
O estado CALCULA PARIDADES controla o cálculo das demais paridades. Estas são
calculadas de maneira similar à executada no estado CALCULA ÚLTIMA PARIDADE, só que o
bloco de paridade calculado anteriormente, , também é somado - equação (21). Os dois
outros estados controlam o descarregamento dos dados de informação e paridade.
Neste trabalho foram desenvolvidas duas arquiteturas seriais, uma para funcionar
como um coprocessador (considerando acesso compartilhado à memória do sistema) e
outra com memória SRAM interna (tendo entrada serial de bits da informação a ser
Pij
kb
mb
nb
Hb2
hb
H'b1
53
codificada). Ambas as arquitetura, são capazes executar a codificação de canal LDPC para 84
configurações, entre tamanhos taxa de códigos diferentes.
6.1.1 Arquitetura Com SRAM Interna
O que chamamos de arquitetura serial é a estrutura de hardware modelada para
funcionar com memória de trabalho (SRAM) própria e com operações internas executadas
de maneira totalmente serial.
Nesta arquitetura – Figura 32 – os dados são recebidos e tratados serialmente. Assim,
na execução de cada iteração definida em (15), o deslocamento circular para a esquerda
sobre o vetor , , é feito utilizando um multiplexador e um
demultiplexador de 96 entradas, que em termos de hardware é menos custoso que um
barrel-shifter – Figura 33.
Figura 32: Diagrama de blocos da arquitetura serial.
54
Figura 33: Barrel-Shifter.
Um barrel-shifter circular pode ser construído através de um conjunto de
multiplexadores de duas entradas, onde cada multiplexador pode conter duas portas AND,
uma OR e uma NOT.
Na Figura 33 temos um exemplo de barrel-shifter circular de quatro entradas, ,
e dois bits de seleção, . Para esta configuração há um total de oito
multiplexadores ou dezesseis ANDs, oito ORs e oito NOTs.
Pode-se generalizar o cálculo de recursos de um barrel-shifter circular como sendo
multiplexadores de duas entradas ou, ainda, ANDs, ORs e NOTs. A
título de comparação, considerando o multiplexador da Figura 34, podemos notar que, para
quatro entradas há o consumo de oito ANDs, três ORs e dois NOTs. Nota-se que os recursos
de hardware envolvidos na construção de um barrel-shifter é maior que os envolvidos na
construção um multiplexador de mesma quantidade de entradas, conforme pode ser visto
na Tabela 2. Pode-se generalizar o cálculo dos recursos envolvidos na construção de um
multiplexador como sendo ANDs, ORs e NOTs.
in_0
in_1
in_2
in_3
out_0
out_1
out_2
out_3
sel_0
sel_1
55
Figura 34: Multiplexador.
Tabela 2: Estimativa de recursos de hardware.
AND OR NOT Total
Barrel-Shifter 128 1792 896 896 3584
Multiplexador 128 896 127 7 1030
Barrel-Shifter 64 768 384 384 1536
Multiplexador 64 384 63 6 453
Na arquitetura da Figura 32, ao invés de armazenar e deslocar todos os bits de um
bloco de uma só vez, os dados são somados, um a um, e colocados no lugar onde iriam
estar após o deslocamento. O valor que define o tamanho do deslocamento é obtido a partir
da ROM contendo as matrizes base , Figura 31. Esses valores definem a posição inicial do
multiplexador, assim, a cada novo bit tratado, o valor do deslocamento é incrementado.
Devido ao fato de não precisar armazenar os dados da entrada serial para aplicar o
deslocamento de uma única vez, é economizado um registrador de 96 posições.
Nessa arquitetura, os valores das matrizes , Figuras 5 a 8, são armazenados
sequencialmente na memória e, diferentemente da arquitetura coprocessador, todos os
valores da região útil das matrizes, Figura 31, são armazenados, de maneira crescente, de
56
modo a permitir o acesso linha a linha. Para cada conjunto de valores (bloco de bits
sistemáticos) é obtido um valor correspondente em que indica se ele será ou não
somado para compor o valor e qual deslocamento circular deverá ser aplicado. Valores de
0 a 96 indicam o tamanho do deslocamento, enquanto 97 representa o valor nulo, isto é,
multiplicado por zero. Para armazenamento destas constantes, referentes às quatro
matrizes, foi usada uma ROM de 512 palavras de 7 bits.
O cálculo do primeiro bloco de valores intermediários é feito simultaneamente ao
recebimento da mensagem – vetor de bits sistemáticos – pela entrada
serial. Para o cálculo dos demais , os valores precisam ser armazenados internamente.
Os bits sistemáticos são armazenados em uma memória SRAM. Para gravar os dados na
memória é necessário armazená-los temporariamente em sram_input_reg, de 4 em 4 bits.
Após o cálculo de cada linha , os bits correspondentes são armazenados nas
posições de memória reservadas para os vetores de paridade. Os valores são usados
posteriormente nos cálculos dos blocos de paridade – conforme cada paridade vai sendo
definida, os valores são substituídos na SRAM.
O tamanho de 4 bits de palavra para a memória de trabalho foi escolhido por ser o
máximo divisor comum de todos os tamanhos de bloco z definidos para o padrão – Tabela 1.
Essa escolha, associada à organização das matrizes na ROM, facilita a tarefa de alcançar a
flexibilidade de tamanhos e taxas de código demandada pelo padrão IEEE 802.22 WRAN.
Para esta arquitetura foi usada uma SRAM de 576 palavras de 4 bits.
6.1.2 Arquitetura Coprocessador
A arquitetura coprocessador também é uma arquitetura serial. Ela foi modelada a
partir do hardware mostrado na subseção anterior, incorporando várias otimizações. Essa
arquitetura considera o cenário em que o codificador é usado como um coprocessador,
tendo acesso compartilhado à memória onde estão as informações a serem codificadas e
onde deverão ser gravados os bits de paridade calculados. Com isso é possível eliminar a
57
SRAM de trabalho interna, já que as informações são negociadas diretamente com a
memória do sistema. Esse módulo foi projetado para operar como um periférico escravo.
A arquitetura coprocessador é mostrada na Figura 35. Nela, os valores de
armazenados são organizados de maneira diferente. A primeira mudança significativa é que
são armazenadas apenas as informações de deslocamento válidas. Como as matrizes de
paridade, Figuras 5 a 8, são esparsas – isto é, com uma grande quantidade de elementos
nulos (representados pelo valor -1) – grande parte de seus valores não precisa ser
armazenada, diminuindo o tamanho da memória.
Figura 35: Diagrama de blocos da arquitetura coprocessador.
58
Na modelagem descrita na subseção anterior, todos os valores da submatriz e da
primeira coluna da matriz são armazenados na ROM, de modo a permitir que o
contador usado para iterar os blocos de informação , no cálculo da equação (15), seja
usado para selecionar o valor correspondente na matriz . Desse modo, se o valor em
for um valor nulo, então o valor correspondente não será computado. Naquela
abordagem puramente serial, a leitura sequencial dos valores permite que os dados
sistemáticos sejam usados conforme sua chegada pela entrada serial. Entretanto, na
arquitetura coprocessador, os dados sistemáticos são acessados sob demanda na memória
do sistema, o que permitiu otimizações na estrutura de armazenamento das matrizes na
ROM.
Nessa organização, apenas os elementos não nulos (úteis) em (Figura 36) são
armazenados, juntamente com os respectivos endereços. Sendo assim, para o cálculo de
em (15), é possível acessar apenas os blocos referentes aos valores de deslocamento não
nulos. Com isso vários ciclos são economizados. A Figura 36 mostra um exemplo de matriz
, para uma taxa de código de 1/2, com os respectivos valores que são armazenados
circulados em azul. Para esse exemplo, apenas 54 valores dos 156 são armazenados. Para
armazenar as quatro matrizes base, foi usada uma ROM de 320 palavras de 12 bits, onde 7
bits são usados para indicar o valor do deslocamento e 5 bits para indicar o endereço da
coluna em .
Figura 36: Valores não nulos úteis da matriz Hb para taxa de código 1/2.
–1 94 73 –1 –1 –1 –1 –1 55 83 –1 –1 7 0 –1 –1 –1 –1 –1 –1 –1 –1 –1 –1
–1 27 –1 –1 –1 22 79 9 –1 –1 –1 12 –1 0 0 –1 –1 –1 –1 –1 –1 –1 –1 –1
–1 –1 –1 24 22 81 –1 33 –1 –1 –1 0 –1 –1 0 0 –1 –1 –1 –1 –1 –1 –1 –1
61 –1 47 –1 –1 –1 –1 –1 65 25 –1 –1 –1 –1 –1 0 0 –1 –1 –1 –1 –1 –1 –1
–1 –1 39 –1 –1 –1 84 –1 –1 41 72 –1 –1 –1 –1 –1 0 0 –1 –1 –1 –1 –1 –1
–1 –1 –1 –1 46 40 –1 82 –1 –1 –1 79 0 –1 –1 –1 –1 0 0 –1 –1 –1 –1 –1
–1 –1 95 53 –1 –1 –1 –1 –1 14 18 –1 –1 –1 –1 –1 –1 –1 0 0 –1 –1 –1 –1
–1 11 73 –1 –1 –1 2 –1 –1 47 –1 –1 –1 –1 –1 –1 –1 –1 –1 0 0 –1 –1 –1
12 –1 –1 –1 83 24 –1 43 –1 –1 –1 51 –1 –1 –1 –1 –1 –1 –1 –1 0 0 –1 –1
–1 –1 –1 –1 –1 94 –1 59 –1 –1 70 72 –1 –1 –1 –1 –1 –1 –1 –1 –1 0 0 –1
–1 –1 7 65 –1 –1 –1 –1 39 49 –1 –1 –1 –1 –1 –1 –1 –1 –1 –1 –1 –1 0 0
43 –1 –1 –1 –1 66 –1 41 –1 –1 –1 26 7 –1 –1 –1 –1 –1 –1 –1 –1 –1 –1 0
H b1H b2
59
Além de não necessitar de uma SRAM de trabalho, não guardar valores nulos de
na ROM e evitar percorrer valores de que não são contabilizados em , essa segunda
arquitetura, Figura 35, também opera com 4 bits por vez, compatibilizando sua operação de
soma em GF(2), XOR entre bits, com o tamanho da palavra de trabalho interna.
Para compatibilizar o tamanho de palavra interna de trabalho com o tamanho de
palavra da memória do sistema, foi criada uma interface de SRAM. Ela é responsável por ler
e escrever na memória do sistema e entregar para o codificador as palavras adequadas à sua
operação interna. Para este projeto foi adotada uma interface de 32 para 4 bits, mas esta
interface pode ser facilmente alterada para compatibilizar com outros tamanhos de palavra
de barramento.
A escolha da taxa de código é feita através da seleção do endereço da ROM. Os
endereços onde ficam o primeiro valor de cada matriz , para uma determinada taxa de
código, são mostrados na Tabela 3.
Tabela 3: Endereço inicial de cada taxa de código
Taxa de Código Endereço Inicial
1/2 0x00
2/3 0x41
3/4 0x8B
5/6 0xDB
6.2 VERIFICAÇÃO FUNCIONAL
As verificações das duas arquiteturas de codificador LDPC foram implementadas com
a metodologia e a biblioteca de classes do UVM. O ambiente de verificação foi feito em
linguagem SystemVerilog, sendo que houve reaproveitamento (reuso), na verificação das
duas arquiteturas, de grande parte das classes desenvolvidas na construção do ambiente.
Foram usadas estruturas de geração aleatória de estímulos, direcionadas a partir de
restrições do SystemVerilog. O modelo de referência foi construído em linguagem C, sendo
60
este validado por modelos preexistentes em MATLAB. Posteriormente, o código C foi ligado
ao scoreboard para servir de referência para o DUT.
No ambiente de verificação, para a arquitetura serial com SRAM interna, há um
agente ativo (mestre) contendo um elemento ldpc_sequencer, o qual é responsável por
fornecer itens de dados ldpc_seq_item ao ldpc_fs_driver. O driver se liga ao sequenciador
(sequencer) através de TLM, tendo sua porta seq_item_port conectada à porta
seq_item_export do sequencer, como é mostrado na Figura 37. Nesse esquema, o sequencer
é responsável por produzir os itens de dados e provê-los à sua porta de saída, export. Por
outro lado, o driver é responsável por consumir os itens de dados através de sua porta de
entrada seq_item_port e avisar que o item foi usado. A conexão entre as portas do driver e
sequencer é feita dentro do agente. A conexão é feita como mostra a Figura 38.
Figura 37: Conexão entre portas do driver e do sequencer.
virtual function void connect_phase(uvm_phase phase);
super.connect_phase(phase);
collector.item_collected_port.connect(monitor.item_collected_export);
if (is_active == UVM_ACTIVE)
begin
driver.seq_item_port.connect(sequencer.seq_item_export);
end
endfunction : connect_phase
Figura 38: Driver seq_item_port conectado à porta seq_item_export do sequencer.
61
A arquitetura do ambiente de verificação, para a arquitetura serial, é mostrada na
Figura 39. Além do driver e do sequencer, o ldpc_agent também abriga o ldpc_fs_collector e
o ldpc_fs_monitor. Uma porta de análise é usada para enviar as transações amostradas no
ldpc_fs_collector para o ldpc_fs_monitor. O monitor, por sua vez, repassa o item coletado,
ldpc_collected_item, ao scoreboard instanciado fora do agente.
Figura 39: Ambiente de verificação para arquitetura serial.
A Figura 40 mostra como se dá a comunicação entre o monitor, o collector e o
scoreboard. O monitor é conectado ao scoreboard dentro do ldpc_env, na fase de conexão,
62
como mostra a Figura 41. Por sua vez, o collector se conecta ao monitor dentro do agente,
como pode ser visto na Figura 37. Tanto o collector quanto o driver se conectam ao DUT
através da interface de portas do SystemVerilog.
Figura 40: Comunicação entre monitor, collector e scoreboard.
virtual function void connect_phase(uvm_phase phase);
agent.monitor.item_collected_port.connect(scoreboard.item_collected_export);
endfunction : connect_phase
Figura 41: Monitor conectado à porta item_collected_export do scoreboard.
No ambiente de verificação, o scoreboard é responsável por receber os itens de
dados coletados da interface com o DUT, além de verificar a correção dos mesmos. Para tal,
o scoreboard consulta o modelo de referência construído em C – ele executa a verificação
em nível funcional, não se ocupando com detalhes do protocolo. Para usar o modelo de
referência em C, o scoreboard usa DPI-C. O DPI (Direct Programming Interface – Interface de
63
Programação Direta) do SystemVerilog é basicamente uma interface entre SystemVerilog e
uma outra linguagem de programação – nesse caso, a C. Ele permite fazer chamadas a
funções em C a partir do SystemVerilog e vice versa [27].
Além do componente de verificação UVC de interface descrito, há a classe que
estende uvm_test (test_ldpc_full_serial), a qual é responsável por configurar o teste
executado. Neste caso, ela seleciona o ambiente e a sequência de itens que será carregada.
Ela também pode sobrescrever elementos componentes do ambiente.
O testbench é instanciado no módulo hierárquico mais elevado (top). Este módulo é
responsável por importar os pacotes de classes do UVM e o ambiente criado, instanciar o
DUT e a interface, conectar ambos, passar a interface para o ambiente e iniciar o teste. Além
disso, o módulo top contém a geração de clock.
Para o ambiente de verificação da arquitetura coprocessador, várias classes foram
reutilizadas. A Figura 42 mostra em vermelho as classes que foram alteradas. Além do DUT e
da interface SystemVerilog, apenas o monitor, o collector, o driver e as configurações de
testes foram alteradas. Para refazer as configurações necessárias, ambos os testes
(test_ldpc_full_serial e test_ldpc_coprocessor) estendem uma classe test_base, apenas
sobrescrevendo a função build_phase. O teste test_ldpc_coprocessor sobrescreve as classes
monitor, collector e driver, através do uvm_config_db. As Figuras 43 e 44 mostram o sumário
de cada teste.
64
Figura 42: Ambiente de verificação para arquitetura coprocessador.
65
UVM_INFO @ 0: reporter [RNTST] Running test test_ldpc_full_serial... 0: uvm_test_top.ldpc_env0.ldpc_scoreboard: start_of_simulation
UVM_INFO @ 0: reporter [UVMTOP] UVM testbench topology: -----------------------------------------------------------------------
Name Type Size Value
----------------------------------------------------------------------- uvm_test_top test_ldpc_full_serial - @132
ldpc_env0 ldpc_env - @5359 agent0 ldpc_agent - @5358
driver ldpc_fs_driver - @5557 rsp_port uvm_analysis_port - @5967
recording_detail uvm_verbosity 32 UVM_FULL
sqr_pull_port uvm_seq_item_pull_port - @5862 recording_detail uvm_verbosity 32 UVM_FULL
req object - <null> recording_detail uvm_verbosity 32 UVM_FULL
monitor ldpc_fs_monitor - @5431
sb_post uvm_analysis_port - @5692 recording_detail uvm_verbosity 32 UVM_FULL
trans ldpc_collected_item - @5554 length integral 8 'h0
codeword sa(integral) 0 - systematics sa(integral) 0 -
rate rate_e 2 RATE_1_2
recording_detail uvm_verbosity 32 UVM_FULL sequencer ldpc_sequencer - @5755
rsp_export uvm_analysis_export - @6156 recording_detail uvm_verbosity 32 UVM_FULL
seq_item_export uvm_seq_item_pull_imp - @7335 recording_detail uvm_verbosity 32 UVM_FULL
recording_detail uvm_verbosity 32 UVM_FULL
arbitration_queue array 0 - lock_queue array 0 -
num_last_reqs integral 32 'd1 num_last_rsps integral 32 'd1
is_active uvm_active_passive_enum 1 UVM_ACTIVE recording_detail uvm_verbosity 32 UVM_FULL
ldpc_scoreboard ldpc_scoreboard - @5428
item_collected_export uvm_analysis_imp - @7504 recording_detail uvm_verbosity 32 UVM_FULL
is_enable ldpc_enable_disable_enum 32 ENABLE recording_detail uvm_verbosity 32 UVM_FULL
recording_detail uvm_verbosity 32 UVM_FULL -----------------------------------------------------------------------
Figura 43: Sumário de verificação para arquitetura serial.
66
UVM_INFO @ 0: reporter [RNTST] Running test test_ldpc_coprocessor... 0: uvm_test_top.ldpc_env0.ldpc_scoreboard: start_of_simulation UVM_INFO @ 0: reporter [UVMTOP] UVM testbench topology: ----------------------------------------------------------------------- Name Type Size Value ----------------------------------------------------------------------- uvm_test_top test_ldpc_coprocessor - @132 ldpc_env0 ldpc_env - @5359 agent0 ldpc_agent - @5358 driver ldpc_cp_driver - @5557 rsp_port uvm_analysis_port - @5967 recording_detail uvm_verbosity 32 UVM_FULL sqr_pull_port uvm_seq_item_pull_port - @5862 recording_detail uvm_verbosity 32 UVM_FULL req object - <null> recording_detail uvm_verbosity 32 UVM_FULL monitor ldpc_cp_monitor - @5431 sb_post uvm_analysis_port - @5692 recording_detail uvm_verbosity 32 UVM_FULL trans ldpc_collected_item - @5554 length integral 8 'h0 codeword sa(integral) 0 - systematics sa(integral) 0 - rate rate_e 2 RATE_1_2 recording_detail uvm_verbosity 32 UVM_FULL sequencer ldpc_sequencer - @5755 rsp_export uvm_analysis_export - @6156 recording_detail uvm_verbosity 32 UVM_FULL seq_item_export uvm_seq_item_pull_imp - @7335 recording_detail uvm_verbosity 32 UVM_FULL recording_detail uvm_verbosity 32 UVM_FULL arbitration_queue array 0 - lock_queue array 0 - num_last_reqs integral 32 'd1 num_last_rsps integral 32 'd1 is_active uvm_active_passive_enum 1 UVM_ACTIVE recording_detail uvm_verbosity 32 UVM_FULL ldpc_scoreboard ldpc_scoreboard - @5428 item_collected_export uvm_analysis_imp - @7504 recording_detail uvm_verbosity 32 UVM_FULL is_enable ldpc_enable_disable_enum 32 ENABLE recording_detail uvm_verbosity 32 UVM_FULL recording_detail uvm_verbosity 32 UVM_FULL -----------------------------------------------------------------------
Figura 44: Sumário de verificação para arquitetura coprocessador.
67
7 APRESENTAÇÃO E ANÁLISE DE DADOS
A princípio, para permitir a comparação com os trabalhos propostos em [13], [28] e
[29], foram considerados apenas os parâmetros utilizados pelos autores na descrição de suas
respectivas arquiteturas.
As propostas de codificadores, nos artigos referidos acima, não foram efetivamente
implementadas em hardware. Assim, a complexidade e o custo de hardware expressos em
tais trabalhos apenas referem-se a estimativas, baseadas nas respectivas arquiteturas
definidas pelos autores.
Também há outros fatores importantes a serem considerados nessa primeira análise.
Os codificadores propostos nesses artigos foram feitos para o padrão de comunicação
802.11n, com as arquiteturas esboçadas levando em consideração apenas uma taxa de
código, o que implica na utilização de uma única matriz de codificação. Por outro lado, as
arquiteturas desenvolvidas e implementadas neste trabalho são capazes de operar em 84
diferentes configurações de tamanho e taxas de código.
Na Tabela 4 é apresentada uma comparação de resultados, no que concerne à
quantidade de estruturas de hardware utilizadas, entre as arquiteturas esboçadas em [13],
[28] e [29], e as propostas neste trabalho. Para efeito de comparação e compatibilização das
arquiteturas desenvolvidas com o padrão IEEE 802.22 WRAN, o consumo de recursos foi
recalculado, tomando por base um bloco Z igual a 96 bits. Em [13] foi usada uma abordagem
totalmente paralela, o que garante uma baixa latência, mas gera o maior custo em termos
de hardware; o trabalho desenvolvido em [28] propõe uma abordagem mista, na qual cada
bloco de tamanho Z bits é executado por vez, operando-se somente sobre valores não nulos.
Essa estratégia aumenta a latência, mas diminui drasticamente a quantidade de recursos
consumida pela arquitetura; por outro lado, na abordagem apresentada em [29], o
processamento dos blocos de Z bits também é feita em paralelo, só que, ao contrário de
[13], a execução é feita coluna a coluna. Essa estratégia permite alcançar a mesma latência
de [13], porém consumindo aproximadamente a metade dos flip-flops e portas XOR, além de
eliminar a necessidade da memória usada para guardar os valores .
68
Tabela 4: Comparação entre a quantidade de estruturas utilizadas nas arquiteturas propostas.
Flip-Flops XOR Barrel-shifter Outros Memória
[13] 2016 1920 20 * + RAM
[28] 192 288 1 * + RAM + FIFO
[29] 1248 1248 12 * + FIFO
Serial Com SRAM 104 1 0 2 MUX + RAM + RAM
Coprocessador 192 100 0 3 MUX
Ambas as arquiteturas propostas neste trabalho conseguem alcançar os requisitos de
flexibilidade de 84 configurações diferentes, entre tamanho de palavras de códigos e taxa de
codificação, impostos pelo padrão IEEE 802.22 WRAN, usando uma quantidade menor de
recursos que as arquiteturas apresentadas em [13], [28] e [29].
Para a arquitetura serial com SRAM interna foram utilizados apenas (Figura 35):
uma porta XOR;
dois registradores de 4 bits;
um registrador de 96 bits;
três multiplexadores;
um demultiplexador;
um contador de deslocamento;
um módulo de memória ROM para guardar as matrizes ; e
um módulo de memória SRAM de trabalho.
Para a arquitetura coprocessador foram utilizados (Figura 35):
quatro portas XOR para a operação principal;
noventa e seis portas XOR para o acumulador que calcula ;
um registrador de 96 bits para a operação principal;
um registrador de 96 bits para guardar ;
três multiplexadores;
um demultiplexador; e
um módulo de memória ROM para armazenar os valores de .
69
Para ser coerente, na comparação com as arquiteturas propostas em [13], [28] e [29]
– as quais não consideram os circuitos lógicos usados para controle, nem questões
relacionadas à codificação de tamanhos e taxas diferentes – a análise feita até aqui levou em
consideração apenas os principais componentes das arquiteturas. Entretanto, no presente
trabalho, para construção dos codificadores, além das estruturas relacionadas
anteriormente, foram usados controladores compostos por FSMs, contadores e estruturas
para o cálculo de configurações, a partir da taxa e tamanho da palavra de código.
Os IP-Cores dos codificadores foram sintetizados em tecnologia de 55 nm, chegando
até o GDSII, para uma frequência de 300 MHz – Figuras 45 e 46. As Tabelas 5 e 6 mostram os
resultados de área e consumo obtidos na implementação ASIC destes componentes.
Figura 45: Layout físico da arquitetura coprocessador.
70
Figura 46: Layout físico da arquitetura serial com SRAM interna.
Tabela 5: Resultados de síntese do codificador LDPC coprocessador.
Tipo de Célula Área (µm2) Leakage (nW) Consumo (nW)
Memórias 4.800 197 275.696
Registradores 2.187 65 786.923
Inversores 222 12 13.793
Buffers 22 2 4.801
Células 7.468 290 623.013
Total 14.701 567 1.704.228
Tabela 6: Resultados de síntese do codificador LDPC serial com SRAM interna.
Tipo de Célula Área (µm2) Leakage (nW) Consumo (nW)
Memórias 21.317 871 2.328.491
Registradores 1.514 46 526.183
Inversores 100 5 4.608
Buffers 3 0 822
Células 3.102 137 234.262
Total 26.038 1.061 3.094.368
71
A opção por arquiteturas usando abordagem serial traz grandes vantagens em
termos de custo de hardware, mas em contrapartida, torna a codificação mais lenta,
diminuindo a quantidade de bits codificados por ciclo de clock. Entretanto, para o padrão
IEEE 802.22 WRAN, a escolha deste tipo de arquitetura se mostrou acertada, já que, de
acordo com [8], a taxa de dados máxima é de 22,69 Mbps para uma taxa de código 5/6, e de
13,61 Mbps para uma taxa de código 1/2. Com frequência de 300 MHz, a taxa de dados de
informação codificada na arquitetura serial com SRAM interna é de 78,947 Mbps para a taxa
de código 5/6, e de 17,647 Mbps para a taxa de código 1/2. Por sua vez, para a arquitetura
coprocessador, a taxa de dados de informação codificada é de 236,065 Mbps para a taxa de
código 5/6, e de 324,324 Mbps para a taxa de código 1/2. Portanto, ambas as arquiteturas
propostas neste trabalho satisfazem, por larga margem, os requisitos do padrão.
Em comparação, o trabalho proposto em [30], que usa a decomposição LU como
base para codificação LDPC, voltada para o padrão CMMB (China Mobile Multimedia
Broadcasting – Sistema de Transmissão Terrestre Multimídia Chinês) [31], alcançou 32,44
Mbps na taxa de código 1/2 e 67,16 Mbps na taxa de código 3/4. O trabalho proposto em
[30] funciona apenas com estas duas taxas de código (1/2 e 3/4) e com tamanho de palavra
de código fixa, rodando a 200 MHz. Para alcançar seus objetivos, os autores implementaram
um pipeline de cinco estágios. Tal arquitetura foi prototipada em um FPGA Altera Stratix II
EP2S90. O protótipo usou 581 ALUTs (Adaptive Look-Up Table – Bloco de Memória/Tabela
de Pesquisa Adaptativa), 726 LEs (Logic Elements – Elementos Lógicos) equivalentes e
2.015.232 bits de memória. Embora a nossa arquitetura tenha sido sintetizada em ASIC, o
que torna difícil a comparação com FPGA, foi usada a relação entre FPGA System Gates e
portas NAND equivalentes. Baseando-se em [32], que estima a capacidade típica de portas
(FPGA System Gates) que podem ser implementadas por LEs, e no número de LEs
equivalentes (arquitetura baseada em LUT de 4 entradas) presentes em um dispositivo
Stratix [33], foi adotada a equivalência de 1 LE para 25 FPGA System Gates ou portas NAND
equivalentes em ASIC. Desse modo, foi estimado que a arquitetura proposta em [30]
consumiu o equivalente a 18.150 portas NAND e 2.015.232 bits de memória.
As arquiteturas apresentadas neste trabalho também foram comparadas com a
implementação paralela proposta em [34], referente a uma arquitetura de codificador LDPC
72
para o padrão IEEE 802.11n/ac de alto rendimento. Tal arquitetura usa acumuladores
com barrel-shifters em paralelo para executar os deslocamentos circulares e as somas,
durante iterações, enquanto que as arquiteturas apresentadas aqui não usam barrel-
shifters e usam apenas um acumulador. Para calcular os valores dos bits de paridade, após o
cálculo dos valores intermediários, a modelagem apresentada em [34] executa a soma de
todos os acumuladores em paralelo, simultaneamente, em apena um ciclo de clock. Por
outro lado, as nossas arquiteturas implementam a soma de maneira iterativa, serialmente,
sendo mais lentas que a apresentada em [34]. Contudo, a escolha por uma abordagem serial
se mostrou acertada e adequada ao padrão IEEE 802.22 WRAN, pois o rendimento é
suficiente e o consumo de área e potência são menores do que os apresentados em [34].
A Tabela 7 mostra uma comparação entre as arquiteturas propostas neste trabalho e
as descritas em [30] e em [34].
Tabela 7: Bits de memória e portas NAND equivalentes por arquitetura
Serial com SRAM Coprocessador [30] [34]
Bits de Memória 5.888 3.840 2.015.232 -
Portas Equivalentes 3.880 7.821 18.150 273.000
Embora os IPs tenham sido feitos considerando a frequência do sistema a que eles
estão inseridos, 300 MHz, a frequência mínima necessária para eles executarem a
codificação de canal para o IEEE 802.22 WRAN é menor. No caso da arquitetura serial com
SRAM interna, a frequência mínima é 231.370 MHz, e para a arquitetura coprocessador, a
frequência é 20.988 MHz. Essa diferença de frequência impacta no consumo energia do
circuito integrado, como podem ser visto nas Tabelas 8 e 9. Em todo caso, aplicando-se
técnica de clock gating, será possível fazer com que o circuito consuma menos energia
relativa a chaveamento dinâmico enquanto está ocioso, fazendo com que o consumo,
mesmo a 300 MHz, se aproxima do consumo na frequência menor.
73
Tabela 8: Comparação dos resultados de síntese da arquitetura serial com SRAM interna.
Frequência Área (µm2) Leakage (nW) Consumo (nW)
300 MHz 26.038 1.061 3.094.368
231.370 MHz 25.877 1.048 2.467.226
Tabela 9: Comparação dos resultados de síntese do codificador LDPC coprocessador.
Frequência Área (µm2) Leakage (nW) Consumo (nW)
300 MHz 14.701 567 1.704.228
20.988 MHz 14.107 521 140.214
74
8 CONCLUSÕES
Ao longo desta pesquisa, foram desenvolvidas duas arquiteturas seriais para
codificadores LDPC destinados ao padrão IEEE 802.22 WRAN. Uma das arquiteturas,
denominada coprocessador, foi desenvolvida como uma evolução da primeira arquitetura,
denominada serial com SRAM interna, a qual é completamente serial. Tal evolução foi
possível a partir de algumas otimizações.
O trabalho foi desenvolvido seguindo o fluxo completo para projetos de circuitos
integrados digitais, desde a modelagem do sistema em alto nível, passando pela etapas de
elaboração da arquitetura, implementação, verificação funcional, até a geração do GDSII.
Na parte final do trabalho, foi feita a comparação das arquiteturas propostas com
outras implementações de codificadores LDPCs, destinadas a outros padrões. Pode-se
concluir que a escolha de uma abordagem serial, para o padrão IEEE 802.22 WRAN, se
mostrou adequada, sendo que foi possível cumprir os requisitos de velocidade (throughput),
com menor consumo de área e potência frente às outras abordagens comparadas.
A inovação deste trabalho está centrada na proposta de arquiteturas serializadas
para o padrão IEEE 802.22 WRAN, o que foi possível através do adequado reordenamento
das equações presentes no algoritmo apresentado. Além disso, ambas arquiteturas atendem
à flexibilidade imposta pelo padrão, permitindo a execução de 84 modos de operação
distintos.
As arquiteturas apresentadas neste trabalho também mostraram eficácia quanto à
velocidade de processamento exigida pelo padrão. Mesmo adotando uma abordagem serial,
para todas as configurações possíveis, elas foram capazes de cumprir com os requisitos de
flexibilidade impostos pelo padrão, sem comprometer os custos em termos de hardware. Foi
possível construir codificadores LDPCs compatíveis com os 84 modos de operação distintos,
com consumo mínimo de área e potência.
Também foi verificado que a arquitetura coprocessador se mostrou mais eficiente
que a arquitetura totalmente serial com SRAM interna. Com a modelagem coprocessador foi
75
possível eliminar o uso de uma memória SRAM interna, assim como rearranjar os
componentes para executar a codificação de maneira mais rápida (até 13 vezes mais rápida),
consumindo menos área e energia.
Tais arquiteturas fazem parte de um projeto maior, de um processador de banda
base OFDMA (Orthogonal Frequency-Division Multiple Access – Múltiplo Acesso por Divisão
de Frequências Ortogonais), destinado ao padrão IEEE 802.22 WRAN, com núcleo
microprocessador. Nesse contexto, ainda há espaço para pesquisas futuras sobre a
modelagem de arquiteturas para decodificadores LDPCs com decisão suave (soft decision)
ou, ainda, o desenvolvimento de arquiteturas eficientes que apliquem técnicas de
decodificação LDPC e demodulação digital iterativas, que visem melhorar a qualidade da
detecção de símbolos IQ recebidos através de um canal AWGN (Additive White Gaussian
Noise – Ruído Branco Aditivo e Gaussiano).
76
9 REFERÊNCIAS BIBLIOGRÁFICAS
1. SHANNON, C. E. A Mathematical Theory of Communication. The Bell System Technical
Journal, n. 27, p. 623–656, Octobe 1948.
2. JOHNSON, S. J. Iterative Error Correction. 1ª Edição. ed. Edimburgo: Cambridge
University Press, 2009.
3. GALLAGER, R. G. Low-density parity-check codes. IRE Trans. Inf. Theory, v. IT-8, n. 1, p.
21-28, Jan. 1962.
4. MACKAY, D. J. C.; NEAL, R. M. Near Shannon limit performance of low density parity
check codes. Electron Lett, v. 32, p. 1645-1646, 1996.
5. WIBERG, N. Codes and Decoding on General Graphs. Ph.D. dissertation, Linkoping:
Linkoping Univ, 1996.
6. KARKOOTI, M.; RADOSAVLJEVIC, P.; CAVALLARO, J. R. Configurable, High Throughput,
Irregular LDPC Decoder Architecture: Tradeoff Analysis and Implementation. IEEE 17th
International Conference on Application-specific Systems, Architectures, and
Processors (ASAP), Sept. 2006. 360-367.
7. ENGLING YEO; BORIVOJE NIKOLIC; READ CHANNEL ARCHIT., STMICROELECTRON., SAN
DIEGO, CA. A 1.1-Gb/s 4092-bit Low-Density Parity-Check Decoder. Asian Solid-State
Circuits Conference, Nov. 2005. 237 – 240.
8. IEEE P802.16e/D12. Draft IEEE Standard for Local Metropolitan Area Networks. Part 16:
Air Interface for Fixed and Mobile Broadband Wireless Access Systems, Outubro 2005.
9. IEEE P802.11n/D10. ‘Draft IEEE Standard for Local Metropolitan networks– Specific
requirements. Part 11: Wireless LAN Medium Access Control (MAC), and Physical Layer
(PHY) specifications: Enhancements for Higher Throughput, Março 2006.
77
10. IEEE 802.22™.. Standard for Wireless Regional Area Networks Part 22: Cognitive
Wireless RAN Medium Access Control (MAC) and Physical Layer (PHY) specifications:
Policies and procedures for operation in the TV Bands, Julho 2011.
11. ZHONG, H.; ZHANG, T. Block-LDPC: a practical LDPC coding system design approach. IEEE
Trans. Circuits and Systems I: Fundamental Theory and Applications, v. 52, p. 766-775,
Abril 2005.
12. RICHARDSON, T.; URBANKE, R. Efficient encoding of low-density parity-check codes. IEEE
Trans. Inf. Theory, v. 47, n. 2, p. 638–656, Fevereiro 2001.
13. CAI, Z. et al. Efficient encoding of IEEE 802.11n LDPC codes. Electron. Lett, v. 42, n. 25, p.
1471–1472, 2006.
14. WYGLINSKI, A. M.; NEKOVEE, M.; HOU, T. Cognitive Radio Communications and
Networks. San Diego, CA: Elsevier Inc, 2010.
15. HUFFMAN, W. C.; PLESS, V. Fundamentals of Error-Correcting Codes. New York:
Cambridge University Press, v. I, 2003.
16. RICHARDSON, T.; URBANKE, R. Modern Coding Theory. 1ª. ed. Nova York: Cambridge
University Press, v. I, 2008.
17. LIN, S.; COSTELLO, D. J. Error Control Coding. 2ª. ed. Englewood Cliffs: Prentice Hall, v. I,
2004.
18. FEWER, C. P.; FLANAGAN, M. F.; FAGAN, A. D. A versatile variable rate LDPC codec
architecture. IEEE Trans. Circuits Syst. I, Reg. Papers, v. 54, n. 10, p. 2240 -2251, 2007.
19. WESTE, N. H. E.; HARRIS, D. M. CMOS VLSI Design: A Circuits and Systems Perspective.
4ª. ed. Boston - EUA: Addison Wesley, v. I, 2011.
20. SCHEFFER, L.; LAVAGNO, L.; MARTIN, G. EDA for IC System Design, Verification, and
Testing. 1ª. ed. Boca Raton-FL, EUA: CRC Press, v. I, 2006.
78
21. LAVAGNO, L.; SCHEFFER, L.; MARTIN, G. EDA for IC Implementation, Circuit Design, and
Process Technology. 1ª. ed. Boca Raton-FL, EUA: CRC Press, v. I, 2006.
22. CHURIWALA, S.; GARG, S. Principles of VLSI RTL Design: A Practical Guide. 1ª. ed. New
York-NY, EUA: Springer, v. I, 2011.
23. LEE, P. Introduction to Place and Route Design in VLSIs. 1ª. ed. Raleigh-NC, EUA:
Lulu.com, v. I, 2007.
24. MEADE, K.; ROSENBERG, S. A Practical Guide to Adopting the Universal Verification
Methodology (Uvm). 2ª. ed. San Jose, CA, USA: Cadence Design Systems, Inc., v. I, 2013.
25. ACCELLERA. UVM Class Reference Manual. Napa, CA, EUA: Accellera Systems Initiative
Inc., v. 1.2, 2014. Disponivel em: <www.accellera.org>.
26. ACCELLERA; CADENCE; MENTOR; SYNOPSYS. UVM User Guide. Napa, CA, EUA: Accellera
Systems Initiative In., v. 1.2, 2011. Disponivel em: <www.accellera.org>.
27. DOULOS. SystemVerilog DPI Tutorial. Doulos, 2015. Disponivel em:
<https://www.doulos.com/knowhow/sysverilog/tutorial/dpi/>. Acesso em: 17 set. 2015.
28. PÉREZ, J. M.; FERNÁNDEZ, V. Low-cost encoding of IEEE 802.11n LDPC. Electron. Lett., v.
44, n. 4, p. 307–308, Julho 2008.
29. JUNG, Y.; JUNG, Y.; KIM, J. Memory-efficient and high-speed LDPC encoder. Electron.
Lett., v. 36, n. 14, p. 1035–1036, Julho 2010.
30. PENG, W.; YONG-EN, C. Low-complexity Real-time LDPC Encoder Design for CMMB.
International Conference on Intelligent Information Hiding and Multimedia Signal
Processing, 2008. 1209-1212.
31. CMMB. China Mobile Multimedia Broadcasting. Part 1: Framing Structure, Channel
Coding and Modulation for Broadcasting Channel, GY/T220. 1, 2006.
32. ALTERA CORPORATION. Gate Counting Methodology for APEX 20K Devices. Application
79
Note 110, v. 1.01, September 1999.
33. ALTERA CORPORATION. Introduction. Stratix II Device Family Data Sheet, Maio 2007.
34. JUNG, Y. et al. 7.7 Gbps encoder design for IEEE 802.11n/ac QC-LDPC codes.
International SoC Design Conference, Jeju Island, Coreia do Sul, Novembro 2012. 215 -
218.
80
10 ANEXOS
10.1 ANEXO A - ARTIGOS PUBLICADOS
Ao longo do desenvolvimento deste trabalho foram publicados cinco artigos
relacionados ao tema de projeto de circuitos integrados. Dentre eles, quatro estão ligados às
pesquisas envolvendo o padrão IEEE 802.22 WRAN, sendo dois deste relativos a
codificadores de canal LDPC.
Segue a lista dos artigos publicados:
Desenvolvimento e Implementação de uma Arquitetura de Codificação LDPC para o Padrão
IEEE 802.22 WRAN em ASIC 55nm;
o 20th IBERCHIP Workshop, Santiago, Chile, 2014.
VLSI Architecture Design and Implementation of a LDPC Encoder for the IEEE 802.22 WRAN
Standard;
o 25th PATMOS (International Workshop on Power And Timing Modeling, Optimization and
Simulation) Salvador, BA, 2015.
Implementação VLSI de uma Autocorrelação para Sincronização em receptores OFDM no
Padrão IEEE 802.22 WRAN;
o 20th IBERCHIP Workshop, Santiago, Chile, 2014.
Hardware Implementation of an OFDMA-WRAN Auto-correlation;
o 5th WCAS (Workshop on Circuits and System Design), Salvador, BA, 2015.
Proposta de arquitetura de segmentação rápida de imagens por cores em FPGA;
o 20º CBA (Congresso Brasileiro de Automática), Belo Horizonte, MG, 2014.