UNIVERSIDADE FEDERAL DA BAHIA
ESCOLA POLITÉCNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA ELÉTRICA
Nelson Alves Ferreira Ne...
UNIVERSIDADE FEDERAL DA BAHIA
ESCOLA POLITÉCNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA ELÉTRICA
Nelson Alves Ferreira Ne...
ii
F383 Ferreira Neto, Nelson Alves.
Desenvolvimento e implementação de uma arquitetura de
codificador de canal LDPC (low-...
iv
v
Dedico este trabalho ao meu pai, Antonio Gilmar Cordeiro
Ferreira, que se tornou o meu maior incentivador, e se
ainda es...
vi
vii
AGRADECIMENTOS
Agradeço a todos que, de alguma forma, direta ou indiretamente, passaram pela minha vida
e contribuíram...
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 Pari...
xii
xiii
ABSTRACT
This work presents the development of two serial architectures for LDPC (Low-Density Parity-
Check Codes) en...
xiv
xv
LISTA DE FIGURAS
Figura 1: Célula IEEE 802.22 WRAN com estação ERB e terminais de usuário. .........................4
F...
xvi
Figura 19: Placement.....................................................................................................
xvii
Figura 38: Driver seq_item_port conectado à porta seq_item_export do sequencer..............60
Figura 39: Ambiente de...
xviii
xix
LISTA DE TABELAS
Tabela 1: Tamanho de palavras de código e matrizes de permutação....................................1...
xx
xxi
LISTA DE SIGLAS
ALUT – Adaptive Look-Up Table (Bloco de Memória/Tabela de Pesquisa Adaptativa)
ASIC – Application-Spec...
xxii
OFDM – Orthogonal Frequency Division Multiplexing (Multiplexação por Divisão de
Frequências Ortogonais)
OFDMA – Ortho...
xxiii
SUMÁRIO
1 Introdução ..................................................................................................
xxiv
4.4.4 Scan-Reorder, CTS e Verificação Física...............................................................38
5 Unive...
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 pro...
2
utilizados somente décadas depois por MacKay [4] e Wiberg [5]. Tais códigos estão entre os
melhores algoritmos de correç...
3
Level), através de linguagem de descrição de hardware (HDL – Hardware Description
Language). Em seguida foi feita a veri...
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 d...
5
de rede se enquadra na categoria das RAN (Regional Area Network – Rede Regional) ou WRAN.
A Figura 2 mostra a distribuiç...
6
codificador de canal LDPC e modulados digitalmente em QPSK (Quadrature Phase-Shift Keying
– Modulação por Deslocamento d...
7
garantindo a redundância necessária para a recomposição da informação. Para tanto, é usado
um codificador de canal LDPC,...
8
, ,
, ,
, ⋯
, ⋯
, ,
, ,
, , , ⋯ , ,
⋮ ⋮
, ,
⋮ ⋯
, ⋯
⋮ ⋮
, ,
Figura 4: Matriz H definida por conjuntos de matrizes de per...
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 difer...
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...
11
3 CODIFICADOR DE CANAL LDPC
Os códigos de verificação de paridade de baixa densidade LDPC constituem uma classe
de códi...
12
Um canal pode apresentar uma série de imperfeições, tais como ruídos, distorções,
interferências e desvanecimentos, den...
13
Entretanto, com a inserção de um bit de paridade, é possível detectar-se apenas um
número par de erros ocorrido na pala...
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 par...
15
compostos por dois conjuntos de nós: os nós de bits (ou variáveis), e os nós de paridade (ou
de verificação). Considera...
16
Figura 11: Grafo de Tanner para código (2, 4)-regular.
Figura 12: Grafo de Tanner para código irregular.
3.4 PROCESSO D...
17
somam aos bits de informação para compor a palavra de código = [ , ], conforme descrito
pela equação (7).
. →
+ + = 0,
...
18
Tal como em [11] e [13], as matrizes para os códigos LDPC Quase Cíclicos do padrão
[10] são construídas por matrizes de...
19
, ,
, ,
⋯
⋯
, 0 −1 ⋯ −1
, 0 0 ⋯ −1
⋮ ⋮
, ,
⋯
⋯
⋮ ⋮
, −1
⋮ ⋮ ⋮
⋯ 0 −1
⋮ ⋮
, ,
⋯
⋯
⋮ ⋮
, −1
⋮ ⋮ ⋮
⋯ −1 0
×
⋮
⋮
= 0
(9)
∑ ...
20
Note que a operação , . pode ser implementada como um deslocamento circular
para a esquerda sobre o vetor , , . = ⋘ , ,...
21
4 FLUXO DE PROJETO DE CIRCUITOS INTEGRADOS DIGITAIS
Este capítulo descreve as etapas envolvidas no projeto de um circui...
22
clássica em dois grandes blocos de atividade: o frontend, que envolve toda a parte de projeto
lógico e de sistema, junt...
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/s...
24
fio; codificação ou decodificação de áudio, vídeo ou algum tipo de informação). Além disso,
pode definir quais algoritm...
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 d...
26
(VHSIC Hardware Description Language – Linguagem de Descrição de Hardware VHSIC), onde
VHSIC quer dizer Very High Speed...
27
As ferramentas de síntese lógica assemelham-se a compiladores voltados para
componentes de hardware, capazes de mapear ...
28
lógicas e flip-flops [19]. Apesar desse processo alcançar resultados satisfatórios, geralmente
ele é desencorajado porq...
29
Figura 17: Projeto físico ou backend.
Figura 18: Floorplanning.
Floorplanning
Placement
Scan Reorder
CTS
Roteamento
GDS...
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 plan...
32
 As restrições da netlist no formato SDC – Synopsys Design Constraints;
 As bibliotecas físicas no formato LEF (Libra...
33
Figura 22: Planta do circuito integrado definida no Floorplanning.
4.4.2 Placement
O Placement é um passo essencial no ...
34
Figura 23: Die sem células padrão e com Placement realizado.
O Placement recebe como entradas:
 A netlist do circuito ...
35
Figura 24: Layout do Placement.
Alguns blocos podem ter tido sua localização atribuída, pelo Floorplanning, a um
determ...
36
dentro do CI só serão calculadas, com real precisão, depois que o layout estiver completo –
tal precisão somente é obti...
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]. C...
38
O processo de roteamento global é mais rápido que o de roteamento detalhado. Ele
consegue prover uma ideia razoável das...
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 d...
40
5 UNIVERSAL VERIFICATION METHODOLOGY (UVM)
UVM (Universal Verification Methodology – Metodologia de Verificação Univers...
41
5.1 A BIBLIOTECA DE CLASSES DA UVM
A biblioteca de classes da UVM possibilita o desenvolvimento de ambientes e
componen...
42
A Figura 27 mostra um exemplo de ambiente de verificação com três componentes de
verificação de interface (Barramento U...
43
5.2.1 UVC de Interface
Um componente de verificação de interface é um ambiente de verificação que contém
os seguintes e...
44
5.2.3 Direcionadores de Estímulos das Entradas (Drivers)
Um driver é um tipo de BFM (Bus Functional Model – Modelo Func...
45
5.2.5 Monitores (Monitors)
Um monitor, ao contrário de um driver, é uma entidade passiva que observa os sinais
de entra...
46
Figura 28: Comunicação entre monitor e collector.
5.2.7 Agentes (Agents)
Um agente é usado para agrupar, configurar e c...
47
codificador LDPC, de maneira independente, pode ser configurado para o modo passivo,
permitindo que este componente se ...
48
6 DESENVOLVIMENTO DO TRABALHO
O projeto e a pesquisa propostos neste trabalho foram desenvolvidos em cinco etapas.
A pr...
49
● Segunda Etapa: RTL do Frontend
○ Codificação do sistema em RTL, através da HDL Verilog. Esse processo resulta numa
fo...
50
● Quarta Etapa: Fluxo ASIC
○ Síntese Lógica;
○ Verificação Formal;
○ Floorplanning;
○ Placement;
○ Scan-Reorder;
○ CTS ...
51
A chave para a modelagem de arquiteturas para codificadores LDPC, que usam a matriz
base de código de verificação de pa...
52
O estado SOMA LINHAS executa o processo de varrer uma linha em e o vetor
informação , bloco a bloco, fazendo com que ca...
53
Ambas as arquitetura, são capazes executar a codificação de canal LDPC para 84
configurações, entre tamanhos taxa de có...
54
Figura 33: Barrel-Shifter.
Um barrel-shifter circular pode ser construído através de um conjunto de
multiplexadores de ...
Dissertação - Mestrado - Nelson Alves - Final com ficha d e aprovação
Dissertação - Mestrado - Nelson Alves - Final com ficha d e aprovação
Dissertação - Mestrado - Nelson Alves - Final com ficha d e aprovação
Dissertação - Mestrado - Nelson Alves - Final com ficha d e aprovação
Dissertação - Mestrado - Nelson Alves - Final com ficha d e aprovação
Dissertação - Mestrado - Nelson Alves - Final com ficha d e aprovação
Dissertação - Mestrado - Nelson Alves - Final com ficha d e aprovação
Dissertação - Mestrado - Nelson Alves - Final com ficha d e aprovação
Dissertação - Mestrado - Nelson Alves - Final com ficha d e aprovação
Dissertação - Mestrado - Nelson Alves - Final com ficha d e aprovação
Dissertação - Mestrado - Nelson Alves - Final com ficha d e aprovação
Dissertação - Mestrado - Nelson Alves - Final com ficha d e aprovação
Dissertação - Mestrado - Nelson Alves - Final com ficha d e aprovação
Dissertação - Mestrado - Nelson Alves - Final com ficha d e aprovação
Dissertação - Mestrado - Nelson Alves - Final com ficha d e aprovação
Dissertação - Mestrado - Nelson Alves - Final com ficha d e aprovação
Dissertação - Mestrado - Nelson Alves - Final com ficha d e aprovação
Dissertação - Mestrado - Nelson Alves - Final com ficha d e aprovação
Dissertação - Mestrado - Nelson Alves - Final com ficha d e aprovação
Dissertação - Mestrado - Nelson Alves - Final com ficha d e aprovação
Dissertação - Mestrado - Nelson Alves - Final com ficha d e aprovação
Dissertação - Mestrado - Nelson Alves - Final com ficha d e aprovação
Dissertação - Mestrado - Nelson Alves - Final com ficha d e aprovação
Dissertação - Mestrado - Nelson Alves - Final com ficha d e aprovação
Dissertação - Mestrado - Nelson Alves - Final com ficha d e aprovação
Dissertação - Mestrado - Nelson Alves - Final com ficha d e aprovação
Dissertação - Mestrado - Nelson Alves - Final com ficha d e aprovação
Dissertação - Mestrado - Nelson Alves - Final com ficha d e aprovação
Dissertação - Mestrado - Nelson Alves - Final com ficha d e aprovação
Próximos SlideShares
Carregando em…5
×

Dissertação - Mestrado - Nelson Alves - Final com ficha d e aprovação

6 visualizações

Publicada em

0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
6
No SlideShare
0
A partir de incorporações
0
Número de incorporações
2
Ações
Compartilhamentos
0
Downloads
0
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Dissertação - Mestrado - Nelson Alves - Final com ficha d e aprovação

  1. 1. 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
  2. 2. 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
  3. 3. ii F383 Ferreira Neto, Nelson Alves. Desenvolvimento e implementação de uma arquitetura de codificador de canal LDPC (low-density parity-check codes) para o padrão IEEE 802.22 WRAN (super wi-fi) em ASIC/ Nelson Alves Ferreira Neto. – Salvador, 2015. 105 f. : il. color. Orientador: Prof. Dr. Wagner Luiz Alves de Oliveira. Dissertação (Mestrado) – Universidade Federal da Bahia. Escola Politécnica, 2015. 1. Codificação de canal. 2. Padrão IEEE 802.22. 3. Circuitos integrados digitais. I. Oliveira, Wagner Luiz Alves de. II. Universidade Federal da Bahia. III. Título. CDD: 621.381
  4. 4. iv
  5. 5. 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.
  6. 6. vi
  7. 7. 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!
  8. 8. viii
  9. 9. ix "A mente que se abre a uma nova ideia jamais voltará ao seu tamanho original" (Albert Einstein)
  10. 10. x
  11. 11. 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
  12. 12. xii
  13. 13. 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
  14. 14. xiv
  15. 15. 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
  16. 16. 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
  17. 17. 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
  18. 18. xviii
  19. 19. xix LISTA DE TABELAS Tabela 1: Tamanho de palavras de código e matrizes de permutação....................................10 Tabela 2: Estimativa de recursos de hardware. .......................................................................55 Tabela 3: Endereço inicial de cada taxa de código...................................................................59 Tabela 4: Comparativo de resultados de síntese do codificador LDPC....................................68 Tabela 5: Resultados de síntese do codificador LDPC coprocessador. ....................................70 Tabela 6: Resultados de síntese do codificador LDPC serial com SRAM interna.....................70 Tabela 7: Bits de memória e portas NAND equivalentes por arquitetura ...............................72 Tabela 8: Comparação dos resultados de síntese da arquitetura serial com SRAM interna...74 Tabela 9: Comparação dos resultados de síntese do codificador LDPC coprocessador..........74
  20. 20. xx
  21. 21. xxi LISTA DE SIGLAS ALUT – Adaptive Look-Up Table (Bloco de Memória/Tabela de Pesquisa Adaptativa) ASIC – Application-Specific Integrated Circuit (Circuito Integrado de Aplicação Específica) AVM – Advanced Verification Methodology (Metodologia Avançada de Verificação) AWGN – Additive White Gaussian Noise (Ruído Branco Aditivo e Gaussiano) BPSK – Binary Phase-Shift Keying (Modulação por Deslocamento de Fase Binário) CTS – Clock Tree Synthesis (Síntese de Árvore de Clock) DEF – Design Exchange Format (Formato de Intercâmbio de Projetos) DUT – Design Under Test (Projeto sob Teste) / Device Under Test (Dispositivo sob Teste) DUV – Design Under Verification (Projeto sob Verificação) ERB – Estação Rádio Base eRM – e Reuse Methodology (Metodologia e de Reuso) FFT – Fast Fourier Transform (Transformada Rápida de Fourier) FPGA – Field-Programmable Gate Array (Arranjo de Portas Programável no Local) GDSII – Graphic Database System II (Sistema de Banco de Dados Gráfico II) HDL – Hardware Description Language (Linguagem de Descrição de Hardware) IFFT – Inverse Fast Fourier Transform (Transformada Rápida de Fourier Inversa) IP-Core – Intellectual Property Core (Módulo de Propriedade Intelectual) LDPC – Low-Density Parity-Check Codes LE – Logic Element (Elemento Lógico) LEC – Logic Equivalence Checking (Verificação de Equivalência Lógica) MCU – Microprogrammed Control Unit (Unidade de Controle Microprogramada)
  22. 22. xxii OFDM – Orthogonal Frequency Division Multiplexing (Multiplexação por Divisão de Frequências Ortogonais) OFDMA – Orthogonal Frequency Division Multiple Access (Múltiplo Acesso por Divisão de Frequências Ortogonais) OVM – Open Verification Methodology (Metodologia de Verificação Aberta) QAM – Quadrature Amplitude Modulation (Modulação de Amplitude em Quadratura) QPSK – Quadrature Phase-Shift Keying (Modulação por Deslocamento de Fase em Quadratura) BPSK – Binary Phase-Shift Keying (Modulação por Deslocamento de Fase Binário) IQ – In-phase and Quadrature (Em Fase e Quadratura) RTL – Register-Transfer Level (Nível de Transferência entre Registradores) SDC – Synopsys Design Constraints SoC – System-on-Chip (Sistema-num-Chip) STA – Static Timing Analysis (Análise Estática de Tempo) TDD – Time Division Duplex (Duplexação por Divisão de Tempo) TLM – Transaction-Level Modeling (Modelagem em Nível de Transações) URM – Universal Reuse Methodology (Metodologia Universal de Reuso) UVC – UVM Verification Component (Componente de Verificação da UVM) UVM – Universal Verification Methodology (Metodologia de Verificação Universal) VHDL – VHSIC Hardware Description Language (Linguagem de Descrição de Hardware VHSIC) VHSIC – Very High Speed Integrated Circuit (Circuito Integrado de Velocidade Muito Alta) VMM – Verification Methodology Manual (Manual de Metodologia de Verificação) WRAN – Wireless Regional Area Network (Rede Regional Sem Fios)
  23. 23. xxiii SUMÁRIO 1 Introdução ..........................................................................................................................1 2 IEEE 802.22 WRAN..............................................................................................................4 2.1 Estrutura das Matrizes de Verificação de Paridade ...............................................7 2.2 Redimensionamento de Valores em Hb ...............................................................9 3 Codificador de Canal LDPC ...............................................................................................11 3.1 Codificação de Canal........................................................................................11 3.2 Verificação de Paridade ...................................................................................12 3.3 Códigos LDPC..................................................................................................14 3.4 Processo de Codificação LDPC ..........................................................................16 3.5 O Algoritmo....................................................................................................17 4 Fluxo de Projeto de Circuitos Integrados Digitais ............................................................21 4.1 Visão Geral do Fluxo de Projeto........................................................................21 4.2 Projeto em nível de Sistema.............................................................................23 4.2.1 Especificação ......................................................................................................23 4.2.2 Microarquitetura................................................................................................24 4.3 Projeto Lógico.................................................................................................25 4.3.1 RTL (Register-Transfer Level)..............................................................................25 4.3.2 Síntese Lógica .....................................................................................................26 4.3.3 Verificação Formal..............................................................................................27 4.4 Projeto Físico..................................................................................................28 4.4.1 Floorplanning......................................................................................................31 4.4.2 Placement...........................................................................................................33 4.4.3 Routing................................................................................................................36
  24. 24. xxiv 4.4.4 Scan-Reorder, CTS e Verificação Física...............................................................38 5 Universal Verification Methodology (UVM) .....................................................................40 5.1 A Biblioteca de Classes da UVM........................................................................41 5.2 Bancos de Teste e Ambiente de Verificação em UVM .........................................41 5.2.1 UVC de Interface.................................................................................................43 5.2.2 Itens de Dados (Data Items)...............................................................................43 5.2.3 Direcionadores de Estímulos das Entradas (Drivers)..........................................44 5.2.4 Geradores de Estímulos (Sequencers e Sequences) ...........................................44 5.2.5 Monitores (Monitors).........................................................................................45 5.2.6 Coletores (Collectors) .........................................................................................45 5.2.7 Agentes (Agents) ................................................................................................46 5.2.8 Ambiente (Environment) ....................................................................................46 6 Desenvolvimento do trabalho..........................................................................................48 6.1 Arquitetura.....................................................................................................50 6.1.1 Arquitetura Com SRAM Interna..........................................................................53 6.1.2 Arquitetura Coprocessador ................................................................................56 6.2 Verificação Funcional.......................................................................................59 7 Apresentação e análise de dados.....................................................................................67 8 Conclusões........................................................................................................................74 Referências Bibliográficas.........................................................................................................76 Anexos ......................................................................................................................................81 Anexo A – Artigos Publicados.................................................................................81
  25. 25. 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
  26. 26. 2 utilizados somente décadas depois por MacKay [4] e Wiberg [5]. Tais códigos estão entre os melhores algoritmos de correção de erros conhecidos, os quais proveem excelente desempenho de decodificação e alta taxa de tratamento de dados [6]. Esta categoria de algoritmos permite operar próximo ao limite de Shannon [1], [6] e [7], razão pela qual tem sido adotada por diversos padrões de comunicação recentes, tais como DVB-S2, 802.16e, 802.11n e 802.22 WRAN [8], [9] e [10]. Códigos LDPC são definidos por matrizes de verificação de paridade esparsas , as quais podem ser representadas por um grafo de Tanner e usadas para decodificar as informações recebidas por um canal. Porém, o processo de codificação direta é obtido através da multiplicação da mensagem pela matriz geradora , a qual é obtida a partir de e geralmente é densa, podendo tornar impraticável a implementação para códigos extensos [11]. Entretanto, em [11] e [12] é proposta uma abordagem que permite realizar a codificação usando a própria matriz . Felizmente, o código LDPC definido no padrão IEEE 802.22 WRAN (Wireless Regional Area Network) foi estruturado de maneira a poder tirar proveito da modelagem baseada em blocos proposta em [11] e do algoritmo proposto em [13], os quais permitem a implementação prática em hardware. A flexibilidade imposta pelo padrão 802.22 ao LDPC exige que este possa operar em 21 tamanhos de palavra de código (situados na faixa de 384 a 2304) e quatro taxas de codificação diferentes (1/2, 2/3, 3/4 e 5/6) [10], gerando uma quantidade de 84 configurações possíveis. Essa flexibilidade demanda o desenvolvimento de uma arquitetura de hardware que possa operar de maneira eficiente, na taxa de dados exigida pelo padrão, consumindo a pouca área e potência. Neste trabalho foram desenvolvidas e implementadas duas arquiteturas flexíveis, baseadas no algoritmo apresentado em [13], para o padrão IEEE 802.22 WRAN. Ambas as soluções em hardware são compatíveis com as restrições definidas pelo padrão e podem executar outros códigos sem a necessidade de serem sintetizados novamente, apenas substituindo-se as memórias das matrizes . A pesquisa aqui relatada foi desenvolvida em cinco etapas. A primeira correspondeu à modelagem do sistema em C e MATLAB. Na segunda parte foi feita a descrição das operações do circuito digital, em nível de transferência entre registradores (RTL – Register- Transfer
  27. 27. 3 Level), através de linguagem de descrição de hardware (HDL – Hardware Description Language). Em seguida foi feita a verificação funcional do RTL produzido. Na quarta etapa o projeto passou por todo o fluxo para projetos de circuitos integrados digitais, indo da síntese lógica ao arquivo GDSII (Graphic Database System II – Sistema de Banco de Dados Gráfico II), na tecnologia VLSI 55 nm. E, por último, foi feita a comparação de desempenho de potência e área, entre as arquiteturas propostas e as soluções desenvolvidas para outros padrões similares. Esta dissertação é organizada como segue: o segundo capítulo expõe uma visão geral do padrão IEEE 802.22 WRAN e como são definidas as matrizes de verificação de paridade , assim como o processo de adequação a cada um dos tamanhos de palavras de código; o terceiro capítulo introduz o tema de codificação de canal, apresenta o codificador LDPC, o algoritmo proposto em [13] e mostra as alterações feitas para adequá-lo às nossas arquiteturas; o quarto capítulo traz um estudo sobre o fluxo de projeto para circuitos integrados digitais; o quinto capítulo introduz o framework UVM (Universal Verification Methodology – Metodologia de Verificação Universal); o capítulo seis mostra as arquiteturas desenvolvidas bem como a construção do ambiente de verificação e todo o desenvolvimento relacionado; o sétimo capítulo apresenta e discute os resultados obtidos, além de comparar as soluções deste trabalho com outras implementações; no oitavo capítulo são expostas as conclusões; e finalmente, têm-se as referências bibliográficas.
  28. 28. 4 2 IEEE 802.22 WRAN O padrão de rádio cognitivo IEEE 802.22 WRAN define o LDPC como um dos seus possíveis codificadores de canal. Esse padrão é voltado para comunicação em zona de baixa densidade populacional, tendo como aplicação típica o fornecimento de cobertura de banda larga para áreas rurais e de difícil alcance por cabos. Suas células proveem um raio de alcance médio de 30 km, podendo chegar a 100 km em condições específicas [10]. A Figura 1 mostra um exemplo de uma célula para o padrão IEEE 802.22 WRAN. Figura 1: Célula IEEE 802.22 WRAN com estação ERB e terminais de usuário. Este padrão foi desenvolvido para operar em uma topologia ponto-multiponto (P2MP), sendo o sistema formado por uma estação rádio base (ERB) e terminais de usuários. Nesse conjunto, cada terminal de usuário se liga à ERB através de um link sem fio, sendo tal estação a responsável por controlar o acesso ao meio por parte dos respectivos terminais. Este tipo Rural Vila 64-QAM 20 km 16-QAM 23 km QPSK 30 km
  29. 29. 5 de rede se enquadra na categoria das RAN (Regional Area Network – Rede Regional) ou WRAN. A Figura 2 mostra a distribuição dos tipos de rede de acordo com suas características. Figura 2: Tipos de rede e características. O padrão 802.22 foi concebido para operar, de maneira não interferente, em faixas de frequências destinadas à transmissão de TV analógica: 54 – 862 MHz, com canais de 6, 7 ou 8 MHz [14]. O 802.22 é o primeiro padrão de rádio cognitivo aprovado pelo IEEE. Uma das características das suas células é a capacidade de executar sensoriamento cognitivo do espectro, na faixa que está operando e em canais adjacentes. Para executar sensoriamento, a ERB coordena os terminais de usuários, sincronizando-os quando podem transmitir e quando devem apenas vasculhar os canais (para descobrir canal em uso por alguma TV). Em nível de processamento banda-base, a camada física do padrão é baseada em OFDM/OFDMA (Orthogonal Frequency Division Multiplexing/Multiple Access – Multiplexação por Divisão de Frequências Ortogonais/Múltiplo Acesso), com largura de banda de canais de 6, 7 ou 8 MHz. No processamento para a transmissão, os dados são codificados através de um IEEE 802.15 IEEE 802.11a IEEE 802.11b/g/n IEEE 802.16 IEEE 802.22 PAN LAN MA RAN Tipos de Rede 20-50m 10m Até 100m 1-2km 30km 1 Mbps 10 Mbps 11-600 Mbps 54-280 Mbps ~22 Mbps 2,4 GHs 2,4 GHs 2,4-5 <60 GHs 54-862 Frequência
  30. 30. 6 codificador de canal LDPC e modulados digitalmente em QPSK (Quadrature Phase-Shift Keying – Modulação por Deslocamento de Fase em Quadratura), 16-QAM (Quadrature Amplitude Modulation – Modulação de Amplitude em Quadratura), 64-QAM ou BPSK (Binary Phase-Shift Keying – Modulação por Deslocamento de Fase Binário), sendo os símbolos IQ (In-phase and Quadrature – Em Fase e Quadratura) no domínio da frequência, resultantes destas modulações, aplicados a uma IFFT (Inverse Fast Fourier Transform – Transformada Rápida de Fourier Inversa) de 2048 pontos (subportadoras). Antes de serem transmitidos, os símbolos IQ no domínio do tempo, resultantes da IFFT, são encapsulados em símbolos OFDM que também englobam um prefixo cíclico de 1/4, 1/8, 1/16 ou 1/32 do tamanho da FFT (Fast Fourier Transform – Transformada Rápida de Fourier). Para a recepção dos sinais, é feito o processamento inverso. A comunicação é TDD (Time Division Duplex – Duplexação por Divisão de Tempo). Um esboço do processamento de transmissão e recepção é mostrado na Figura 3 [10]. Figura 3: Diagrama de processamento para transmissão e recepção. Devido às características associadas à baixa densidade populacional e ao longo alcance, as condições do canal podem variar significativamente, o que demanda uma alta flexibilidade do codificador para obter o melhor desempenho possível (isto é, a maior taxa de dados), CodificaçãodeCanal -scrambler -encoder -puncturer -bitinterleaver Mapeamentode ConstelaçãoDigital Alocaçãode Subportadora Inserçãode Piloto IFFT InserçãodePrefixo Cíclico Inserção de Preâmbulo D/A Decodificaçãode Canal Detecçãode ConstelaçãoDigital Desalocaçãode Subportadora FFT A/D Sincronizadore Remoçãode PrefixoCíclico Estimaçãode Canale Equalização DadoRecuperadoDadoBinário SinalOFDM TransmitidoSinalOFDM Recebido
  31. 31. 7 garantindo a redundância necessária para a recomposição da informação. Para tanto, é usado um codificador de canal LDPC, que está entre os melhores algoritmos de codificação e correção de erros conhecidos. Esta categoria de algoritmo permite operar próximo ao limite de Shannon [7]. 2.1 ESTRUTURA DAS MATRIZES DE VERIFICAÇÃO DE PARIDADE Os códigos LDPCs são definidos através de matrizes de baixa densidade. Tais matrizes podem ser usadas no cálculo das matrizes geradoras que permitem executar o processo de codificação de forma direta ou, em alguns casos, serem usadas, as próprias, como base para o algoritmo de codificação, dependendo da estrutura do código. No padrão 802.22, para cada uma das taxas de código r = k/n (1/2, 2/3, 3/4 e 5/6), é definida uma matriz de verificação de paridade de baixa densidade , de tamanho por , onde está associado ao tamanho da palavra de código a ser transmitida, ao tamanho do vetor de verificação de paridade e = − ao número de bits sistemáticos (mensagem a ser transmitida) [10]. As matrizes de verificação de paridade são estruturadas a partir de arranjos de blocos lineares , , conforme a Figura 4, sendo tais blocos matrizes de permutação ou matriz nula de tamanho x . As matrizes são definidas através de matrizes base , de tamanho x . As Figuras 5 a 8 mostram as matrizes definidas pelo padrão IEEEE 802.22 WRAN. Tais matrizes podem ser expandidas através da substituição de cada elemento seu por uma matriz nula ou de permutação, onde = ∗ e = ∗ . O processo de conversão da matriz em uma matriz é feito substituindo-se cada elemento em por uma matriz quadrada , de tamanho x . Quando o elemento na matriz base é o valor −1 , , deverá ser uma matriz nula; nos demais casos, o valor do elemento determinará que , seja uma matriz identidade deslocada circularmente para direita por tal valor [10].
  32. 32. 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
  33. 33. 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 , ( = 96) para uma palavra de código de tamanho = ∗ , = 24 ∗ 96, = 2304. Assim, faz-se necessário equacionar a diferença entre os valores de deslocamento fixados nas matrizes base e o tamanho das submatrizes de permutação , . Portanto, os tamanhos dos deslocamentos para menor que 96 – novos valores dos elementos de , devem ser calculados aplicando a equação (1), sendo a operação floor (arredondamento na direção de -∞). A Tabela 1 define os tamanhos de palavras de código , em bits, relativos ao tamanho das matrizes de permutação , , sendo o tamanho, em bytes, da informação de acordo com taxa de código escolhida. ( , ) = ( , ) , ( , ) = −1 ( , )∗ , (1) 1 25 55 –1 47 4 –1 91 84 8 86 52 82 33 5 0 36 20 4 77 80 0 –1 –1 –1 6 –1 36 40 47 12 79 47 –1 41 21 12 71 14 72 0 44 49 0 0 0 0 –1 51 81 83 4 67 –1 21 –1 31 24 91 61 81 9 86 78 60 88 67 15 –1 –1 0 0 50 –1 50 15 –1 36 13 10 11 20 53 90 29 92 57 30 84 92 11 66 80 –1 –1 0 H b2 H b1
  34. 34. 10 Tabela 1: Tamanho de palavras de código e matrizes de permutação. r =1/2 r =1/2 r =3/4 r =5/6 r =1/2 r =1/2 r =3/4 r =5/6 384 16 24 24 36 40 1440 60 90 120 135 150 480 20 30 30 45 50 1536 64 96 128 144 160 576 24 36 36 54 60 1632 68 102 136 153 170 672 28 42 42 63 70 1728 72 108 144 162 180 768 32 48 48 72 80 1824 76 114 152 171 190 864 36 54 72 81 90 1920 80 120 160 180 200 960 40 60 80 90 100 2016 84 126 168 189 210 1056 44 66 88 99 110 2112 88 132 176 198 220 1152 48 72 96 108 120 2208 92 138 184 207 230 1248 52 78 104 117 130 2304 96 144 192 216 240 1344 56 84 112 126 140 zn k n z k
  35. 35. 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
  36. 36. 12 Um canal pode apresentar uma série de imperfeições, tais como ruídos, distorções, interferências e desvanecimentos, dentre outras, que dificultam a correta interpretação e reprodução das informações transmitidas. Para ser possível detectar e corrigir erros, são adicionados bits redundantes à informação. Do lado do transmissor, as informações digitais, contendo bits, são codificadas em palavras de código com bits. Os dados extras são usados para verificar a consistência das informações que chegam ao receptor, para determinar se estas foram corrompidas ou não e, em caso de corrompimento, permitir restaurar a informação original. A relação entre o tamanho da mensagem, , e o tamanho da palavra de código , = / , é denominada taxa de código [2] ou taxa de informação [15], representando o total de informação utilizável dentro da palavra de código transmitida. 3.2 VERIFICAÇÃO DE PARIDADE A ideia central por trás do código de correção de erro é conseguir aumentar a quantidade de informação que pode ser transmitida através de um canal ruidoso. Para tal, é feito o cálculo e a introdução de dados extras (as chamadas paridades), para serem transmitidos junto à informação desejada (a mensagem). O conjunto mensagem mais paridade forma a denominada palavra de código (codeword). Considerando a informação binária = [ ] e a palavra de código = [ ], composta pela informação e o bit de paridade, é possível validar se a palavra de código recebida está correta usando o vetor de verificação de paridade = [ 1 1 1 1 1], desde que se satisfaça a equação . = 0 no campo de Galois GF(2), conforme equação (2). . = [ 1 1 1 1 1] × = + + + + = 0 (2)
  37. 37. 13 Entretanto, com a inserção de um bit de paridade, é possível detectar-se apenas um número par de erros ocorrido na palavra transmitida, não sendo possível indicar ou corrigir os bits modificados. Para detectar mais de um erro, é necessário aumentar a redundância inserida na palavra de código, sendo que tal redundância deve obedecer a várias equações de paridade, as quais são definidas por uma matriz de verificação de paridade. Dadas uma palavra de código = [ ] e a matriz de verificação de paridade sendo a equação (3), todas as equações definidas por . = [0 0 0] devem ser satisfeitas pela palavra de código, conforme equação (4). = 1 0 1 0 0 0 0 1 0 1 0 1 0 1 0 0 1 0 0 0 1 0 1 0 (3) . = 1 0 1 0 0 0 0 1 0 1 0 1 0 1 0 0 1 0 0 0 1 0 1 0 × = 0 0 0 → + + = 0, + + = 0, + + = 0 (4) Cada linha da matriz de verificação de paridade corresponde a uma equação de verificação de paridade, enquanto que cada coluna relaciona-se a um bit da palavra de código. Quando um elemento da matriz é ‘1’, o correspondente bit da palavra de código é incluído na equação de paridade. Sendo assim, para um código com equações de paridade e uma palavra de código de tamanho , tem-se uma matriz de verificação de paridade, que descreve tal código, de tamanho x . Duas ou mais matrizes de paridade podem descrever o mesmo código, desde que satisfaçam . = [0], onde [0] é um vetor coluna de tamanho , conforme pode ser visto em [2] e [16].
  38. 38. 14 3.3 CÓDIGOS LDPC Os códigos LDPC são códigos de blocos definidos por matrizes esparsas – matrizes de verificação de paridade com um número reduzido de elementos não nulos. O fato das matrizes serem esparsas permite que o processo de decodificação tenha complexidade com crescimento linear [2]. Os códigos de blocos binários podem ser definidos como um código que, a partir de uma palavra de informação , contendo bits, produza uma palavra de código com bits. Para um dado existe 2 mensagens possíveis, assim como 2 palavras de código de tamanho . Nesse processo de codificação, a palavra de código com bits é sempre maior que a palavra de bits sistemática (mensagem) de tamanho [17]. Os códigos LDPC podem ser classificados como regulares ou irregulares. Quando são regulares, as matrizes esparsas que os representam têm um número fixo de elementos não nulos por coluna, , e linha, , ( , ) − , ou em outras palavras, cada bit da palavra de código participa em um número fixo de equações de verificação de paridade , e cada equação faz uso de um número fixo de bits de código [2]. A equação (5) mostra um exemplo de matriz para um código (2, 4) − . Por outro lado quando os códigos são irregulares, não há valores fixos ( , ) que descrevam a quantas equações um bit da palavra de código possa participar ou vice-versa – matrizes que representam tais códigos não tem número fixo de elementos não nulos em linha e colunas (eles obedecem a alguma distribuição [16]). A equação (6) mostra um exemplo de matriz para um código irregular. = 1 0 1 0 0 0 1 1 0 1 0 0 1 1 0 1 1 0 1 1 0 1 0 0 0 1 0 1 1 0 1 0 (5) = 1 0 1 0 0 1 0 1 0 1 0 1 1 1 0 1 1 0 0 1 0 1 0 0 (6) As matrizes de verificação de paridade que definem um código LDPC também podem ser representadas por grafos de Tanner ou grafos bipartidos. Os grafos de Tanner são
  39. 39. 15 compostos por dois conjuntos de nós: os nós de bits (ou variáveis), e os nós de paridade (ou de verificação). Considerando uma matriz de tamanho x , há em um grafo bipartido com nós de variáveis (correspondentes aos bits da palavra de código ) e (ou − ) nós de verificação (correspondentes às equações de paridade [16]). Dado uma matriz , o nó de verificação irá se ligar ao nó de variável se o elemento , não for nulo ( , = 1 indica que o nó de variável participa da equação ) – sendo assim, o número de arestas em um grafo de Tanner é igual ao número de elementos ‘1’ em uma matriz de verificação de paridade . A Figura 10 mostra um exemplo de grafo de Tanner para uma dada matriz . Figura 10: Grafo de Tanner para uma matriz H. Ainda sobre representação usando grafos, é possível notar que, para um dado código ( , ) − , cada nó de bit terá “grau” e cada nó de verificação terá “grau” . A Figura 11 mostra um exemplo de grafo de Tanner com grau 2 para nós de bit e grau 4 para nós de verificação. Esse grafo representa o código (2, 4) − definido pela matriz na equação (5). Por outro lado, na Figura 12 temos um grafo que representa o código irregular definido pela equação (6). Nesse grafo temos, por exemplo, o primeiro nó de bit com grau 2, o segundo com grau 1 e o sexto com grau 3; também temos nós de verificação com graus 5 e 3. O comportamento dos códigos LDPC pode ser melhorado quando estes possuem nós com graus variados, obedecendo a alguma forma de distribuição [15]. Matriz de verificação de Paridade H Nós de verificação ou paridade i Nós de bit ou variável j Grafo de Tanner
  40. 40. 16 Figura 11: Grafo de Tanner para código (2, 4)-regular. Figura 12: Grafo de Tanner para código irregular. 3.4 PROCESSO DE CODIFICAÇÃO LDPC Uma matriz de verificação de paridade pode ser usada para definir um código LDPC, ou seja, um conjunto de palavras de código válidas. Entretanto, no processo de codificação é necessário gerar as palavras de código contendo mensagem e redundância. O processo de codificação consiste em gerar um vetor contendo a palavra de código , a partir de um vetor mensagem , onde . = 0. Nesse contexto, é uma palavra binária contendo bits, é a palavra codificada resultante, com bits, e H é uma matriz de verificação de paridade para um determinado código LDPC, sendo o seu tamanho x . Na equação (4) foi mostrado um exemplo onde, partindo de uma palavra de código , é possível verificar se ela satisfaz a igualdade . = 0. Para proceder com a codificação é necessário fazer o caminho inverso. É preciso, a partir dos bits da mensagem = [ ] que se quer transmitir, poder gerar os bits de paridade = [ ] que se
  41. 41. 17 somam aos bits de informação para compor a palavra de código = [ , ], conforme descrito pela equação (7). . → + + = 0, + + = 0, + + = 0 → = + , = + , = + (7) As equações mostradas em (7) podem ser organizadas em uma matriz geradora , conforme equação (8). Sendo assim, é possível realizar a codificação LDPC usando a matriz de tamanho x , onde = . e . = 0. No entanto, esse método pode se tornar impraticável devido ao fato de normalmente ser uma matriz densa, fazendo com que o codificador tenha complexidade ( ), sendo o número de bits da palavra de código [2] [18]. . = → [ ] × 1 0 0 0 0 0 1 1 0 1 0 0 0 1 0 0 0 0 1 0 0 0 0 1 0 0 0 1 0 1 0 0 0 0 0 0 1 0 1 0 = [ ] 3.5 O ALGORITMO Para contornar o problema da codificação, ao invés de converter matrizes de verificação de paridade em uma matriz geradora , as matrizes , de um código LDPC, podem ser planejadas para permitir executar a codificação a partir delas próprias [2] – esse tipo de código é chamado de LDPC Quase Cíclico. As matrizes de código definidas pelo padrão IEEE 802.22 WRAN são desse tipo [10]. (8)
  42. 42. 18 Tal como em [11] e [13], as matrizes para os códigos LDPC Quase Cíclicos do padrão [10] são construídas por matrizes de permutação (matrizes identidade circularmente deslocadas) ou matrizes nulas. A Figura 13 mostra um exemplo de matriz base para código LDPC Quase Cíclico. Nela, os valores , representam submatrizes (permutação ou nula) de tamanho x . , , , , ⋯ ⋯ , , ⋯ ⋯ , , ⋮ ⋮ , , ⋯ ⋯ ⋮ , ⋯ ⋯ ⋮ , ⋮ ⋮ , , ⋯ ⋯ ⋮ , ⋯ ⋯ ⋮ , Figura 13: Matriz base Hb para código LDPC Quase Cíclico. Como pode ser observado nas Figuras 5 a 8, a estrutura das matrizes de verificação de paridade, definida por matriz base , é dividida em duas seções, e , onde a primeira coluna de , em tom de cinza mais escuro, contém apenas três matrizes de permutação não nulas ( , , , e , , com − 1 < < 0), e a parte em cinza claro é uma matriz diagonal dupla, cujo valor de cada elemento é ‘1’ para = e = + 1, sendo e linhas e colunas, respectivamente. Essa peculiaridade das matrizes do padrão IEEE 802.22 WRAN permite a aplicação do algoritmo de codificação de forma eficiente. Considere a palavra de código = [ , ] como a concatenação dos vetores mensagem e paridade , onde tem tamanho k e tem tamanho m (o vetor é gerado pelo processo de codificação). Se for considerado o vetor subdividido em sequências menores de tamanho z, = [ , ] = [ , , … , , , … ], e for satisfeita a igualdade . = 0, . = 0, equação (9), pode-se inferir as equações (10), (11), (12) e (13).
  43. 43. 19 , , , , ⋯ ⋯ , 0 −1 ⋯ −1 , 0 0 ⋯ −1 ⋮ ⋮ , , ⋯ ⋯ ⋮ ⋮ , −1 ⋮ ⋮ ⋮ ⋯ 0 −1 ⋮ ⋮ , , ⋯ ⋯ ⋮ ⋮ , −1 ⋮ ⋮ ⋮ ⋯ −1 0 × ⋮ ⋮ = 0 (9) ∑ , . + , . + = 0, = 0 (10) ∑ , . + + = 0, ≠ 0, , − 1 (11) ∑ , . + + + = 0, = (12) ∑ , . + , . + = 0, = − 1 (13) Somando todas as equações de (10) a (13) em GF(2), obtém-se (14), que é usada para encontrar . Se utilizarmos a definição da equação (15), é possível reescrever (14), (10), (11), (12) e (13), como (16), (17), (18), (19) e (20), respectivamente, para se obter o vetor de paridades. = ∑ ∑ , . (14) λ = ∑ , . (15) = ∑ λ (16) = λ + , . (17) = λ + , ≠ 0, , − 1 (18) = λ + + (19) = λ + , . (20)
  44. 44. 20 Note que a operação , . pode ser implementada como um deslocamento circular para a esquerda sobre o vetor , , . = ⋘ , , onde o elemento , da matriz define o valor do deslocamento. Considerando , . = 0 sempre que , = −1 (matriz zero), é possível generalizar as equações (18) e (19) em (21). = + λ + , . , = 1: − 2 (21) A chave para implementação de uma arquitetura de hardware que realize esse algoritmo é manipular essas equações, de modo a rearranjá-las da maneira que mais convém à arquitetura desejada.
  45. 45. 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
  46. 46. 22 clássica em dois grandes blocos de atividade: o frontend, que envolve toda a parte de projeto lógico e de sistema, juntamente com a respectiva verificação; e o backend, que corresponde à fase de implementação física [20] [21]. A Figura 14 mostra o fluxograma com as subdivisões e fases de projeto para circuitos integrados digitais. Figura 14: Fluxo geral de projeto de circuito integrado digital dividido por fases. Projeto RTL Síntese Lógica Floorplanning Placement Scan Reorder CTS Roteamento GDSIIVerificação Física (DRC e LVS) Verificação Funcional Verificação Funcional Verificação Funcional V e r i f i c a ç ã o F o r m a l RC Extraction STA Netlist DEF Microarquitetura Especificação Simulação de Sistema Simulação de Sistema Projeto Físico Projeto de Sistema Projeto Lógico FrontendBackend
  47. 47. 23 4.2 PROJETO EM NÍVEL DE SISTEMA Na fase de projeto em nível de sistema são determinados quais componentes de hardware/software devem compor o CI, de forma que ele execute corretamente a função à qual é destinado, consumindo a menor potência, área, tempo de execução e tempo de projeto possível [20]. A fase de projeto em nível de sistema pode ser dividida basicamente em especificação e microarquitetura, conforme Figura 15. Figura 15: Projeto em nível de sistema. 4.2.1 Especificação Em cada uma das etapas envolvidas no fluxo de projeto há um conjunto de artefatos (documentos e/ou arquivos), os quais são usados como entrada ou podem ser gerados como saída da etapa. O ponto de partida para execução do fluxo é a especificação do sistema [19]. A especificação do sistema pode ser composta por vários tipos de documentos, tais como textos descritivos, gráficos, componentes de software (modelos em SystemVerilog, MATLAB, C, C++, SystemC, etc.) e conjunto de normas que definam um novo padrão [20]. Na especificação estão contidos os requisitos funcionais e não funcionais a serem satisfeitos, tais como velocidade, memória, potência máxima consumida e tamanho máximo do die (pastilha de silício onde o CI é fabricado), dentre outros. A especificação define o que deve ser realizado pelo circuito integrado (processamento de banda base para um padrão de comunicação sem Microarquitetura Especificação Simulação do Sistema Simulação do Sistema
  48. 48. 24 fio; codificação ou decodificação de áudio, vídeo ou algum tipo de informação). Além disso, pode definir quais algoritmos podem ou devem ser usados. Também na etapa de especificação do sistema podem ser realizadas simulações em alto nível, para testar e validar os algoritmos envolvidos no processamento da informação. 4.2.2 Microarquitetura A microarquitetura é responsável por definir como o RTL será desenvolvido. Ela parte da extração de requisitos do projeto da especificação do sistema, entregando documentos com textos e gráficos descritivos, os quais definem a arquitetura interna e interfaceamento dos módulos de hardware. Junto a textos e gráficos, também pode haver componentes de software que auxiliem na definição da arquitetura [20]. Para cada bloco é definida uma microarquitetura, na qual pode haver uma subdivisão em novos blocos que, por conseguinte, terão sua microarquitetura detalhada. Nessa microarquitetura incluem-se dados como tamanhos de barramentos, quantidade de bits em interfaces de controle, latência, paralelismos, pipelines, tamanho exato de memórias, dentre outras características que orientarão a implementação de tais blocos. Enquanto na etapa de especificação os componentes de software são em alto nível, na microarquitetura os componentes de software desenvolvidos funcionam como uma espécie de simulação da arquitetura planejada. Em caso de filtros digitais, por exemplo, eles são construídos considerando o tamanho das palavras, em ponto fixo ou ponto flutuante, saturação ou estouro de resultado de operação, dentre outro fatores. Em muitos casos esses componentes de software são usados como modelo de referência para a verificação funcional do hardware.
  49. 49. 25 4.3 PROJETO LÓGICO O projeto lógico é composto por elaboração de RTL, verificação funcional e síntese lógica. A etapa de verificação funcional, juntamente com a metodologia UVM, será descrita em detalhes no capítulo 5. Normalmente inclui-se no projeto lógico a primeira execução de verificação formal ou de equivalência lógica LEC (Logic Equivalence Checking – Verificação de Equivalência Lógica). Esse processo verifica se a netlist sintetizada é logicamente equivalente ao RTL usado como entrada para a síntese [19]. O processo de verificação formal de equivalência lógica pode e deve ser executado nas demais etapas que alteram a netlist. Figura 16: Projeto lógico. 4.3.1 RTL (Register-Transfer Level) O projeto do RTL consiste basicamente em transcrever a microarquitetura, escrita em linguagem natural e diagrama de blocos, para uma HDL, de modo que a síntese lógica possa ser executada. A descrição em nível de transferência entre registradores (flip-flops) – RTL – representa um nível de abstração abaixo da descrição comportamental do circuito e acima da descrição presente em uma netlist em nível de portas lógicas. Entre os registradores, os sinais ou dados são transferidos através de fios e lógicas combinacionais. Geralmente, o RTL é escrito em alguma linguagem de descrição de hardware HDL (Hardware Description Language – Linguagem de Descrição de Hardware), tal como Verilog, SystemVerilog, Chisel ou VHDL Projeto RTL Síntese Lógica Verificação Funcional Verificação Funcional Verificação Formal
  50. 50. 26 (VHSIC Hardware Description Language – Linguagem de Descrição de Hardware VHSIC), onde VHSIC quer dizer Very High Speed Integrated Circuit (Circuito Integrado de Velocidade Muito Alta). As linguagens de descrição de hardwares mais usadas na construção do RTL são Verilog e VHDL [22]. Um RTL bem desenvolvido facilita as etapas subsequentes do fluxo de projeto de circuitos integrados digitais e permite acelerar o processo de construção do CI [22]. Dependendo do nível de documentação desejada e da complexidade do bloco em questão, em alguns casos a microarquitetura e projeto de RTL podem ser realizados como uma única atividade. Em todo caso, essa prática não é recomendada. 4.3.2 Síntese Lógica As raízes da síntese lógica estão ligadas aos trabalhos do matemático George Boole (1815-1865), no que hoje é chamado de álgebra booleana, e à descoberta de Shannon em 1938, mostrando que a álgebra booleana de dois valores pode descrever o funcionamento de circuitos de comutação [21]. Nas últimas décadas houve muito progresso nesse campo, o que tem proporcionado significativo impulso na produtividade de projeto de circuitos integrados digitais. A capacidade de descrever e especificar projetos em níveis de abstração mais altos tem permitido, aos times de projetistas, a utilização de um grande número de transistores nos circuitos digitais atuais [21]. A síntese lógica é o processo pelo qual um circuito digital, descrito em um nível de abstração alto (geralmente RTL), é convertido em uma netlist que descreve todos os elementos combinacionais (portas lógicas simples e agregadas), sequenciais (flip-flops) e de interconexão (fios) que representam logicamente o circuito desejado. Esse processo costuma ser feito por ferramentas computacionais de síntese, as quais são capazes tanto de gerar fluxos binários para configuração de dispositivos lógicos tais como FPGAs (Field- Programmable Gate Array – Arranjo de Portas Programáveis no Local), quanto de gerar netlists para criação de ASICs (Application-Specific Integrated Circuit – Circuito Integrado de Aplicação Específica).
  51. 51. 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
  52. 52. 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.
  53. 53. 29 Figura 17: Projeto físico ou backend. Figura 18: Floorplanning. Floorplanning Placement Scan Reorder CTS Roteamento GDSIIVerificação Física (DRC e LVS) Verificação Funcional V e r i f i c a ç ã o F o r m a l RC Extraction STA Netlist DEF
  54. 54. 30 Figura 19: Placement. Figura 20: Síntese de árvore de clock – CTS.
  55. 55. 31 Figura 21: Roteamento. 4.4.1 Floorplanning O projeto físico começa na etapa de Floorplanning com o planejamento da planta baixa do circuito integrado. O Floorplanning estima a área dos blocos que compõem o circuito integrado e define o posicionamento dos mesmos. Além disso, nessa etapa também são feitos o planejamento de alimentação de energia (Power Planning), a atribuição de pinos e a fixação de memórias e macros [19]. O Floorplanning pode determinar se o projeto irá caber dentro da área planejada para o CI, além de permitir estimar a extensão de congestionamento de fios (isto é, a viabilidade futura do roteamento). Geralmente é recomendado que se faça um Floorplanning preliminar para estimar, o quanto antes, se o tamanho da lógica está de acordo com o especificado, servindo de feedback para os projetistas. Desta forma, a execução de um Floorplanning preliminar possibilita indicar que a microarquitetura de um projeto deva ser alterada, de modo a diminuir a lógica e permitir que o projeto seja acomodado na área disponível para ele [19]. A etapa de Floorplanning recebe como entradas:  A netlist em nível de portas lógicas codificada em HDL;
  56. 56. 32  As restrições da netlist no formato SDC – Synopsys Design Constraints;  As bibliotecas físicas no formato LEF (Library Exchange Format – Formato de Intercâmbio de Bibliotecas);  As bibliotecas lógicas no formato Liberty (.lib), com informações de temporização e consumo das células e memórias; e  Os scripts com restrições e diretivas para execução dessa etapa. Por outro lado, como saída, o Floorplanning gera:  Arquivo no formato DEF (Design Exchange Format – Formato de Intercâmbio de Projetos), usado para representar as conexões e o layout físico. O arquivo DEF contém, inicialmente, as informações geradas no Floorplanning, armazenando as descrições de aspectos físicos do projeto, tais como tamanho da pastilha de silício (die), localização dos módulos e representação física dos pinos. Aapós as demais etapas, tal arquivo é incrementado, passando a conter, por exemplo, a localização física das células). Por sua vez, as bibliotecas LEF encapsulam informações físicas das células e do processo adotado. Algumas das informações contidas num arquivo LEF referem-se à tecnologia e ao roteamento de metais, além dos formatos físicos das células. Além destas, também há as bibliotecas Liberty, responsáveis por armazenar informações de atrasos e consumo para as células padrão da tecnologia. Para garantir que a planta definida para o circuito permita o roteamento e atenda aos requisitos de utilização de área do die, assim como o tempo mínimo de propagação dos sinais, o planejamento do Floorplanning tenta minimizar as distâncias entre as entradas e saídas dos blocos que se comunicam. Além disso, devem ser feitas verificações prévias de congestionamento de roteamento, de utilização de blocos e do plano de alimentação [19]. A Figura 22 mostra a planta de um circuito integrado, onde há três blocos A, B e C, ligados entre si, a macroblocos de memória e a alguns pinos de entrada e saída. Pode-se ver que, nesse exemplo, o Floorplanning define a posição dos blocos de modo a diminuir o comprimento dos fios entre suas entras e saídas.
  57. 57. 33 Figura 22: Planta do circuito integrado definida no Floorplanning. 4.4.2 Placement O Placement é um passo essencial no backend. É nessa etapa que as células padrão e as macros são colocadas dentro do layout do circuito inicialmente definido no Floorplanning – ou seja, é feita a definição das localizações exatas dos componentes do circuito integrado. A qualidade do Placement poderá afetar a desempenho ou inviabilizar o roteamento e, por conseguinte, o CI. Sendo assim, o Placement considera os seguintes objetivos, enquanto define a posições das células e macros [21]:  Comprimento total dos fios;  Temporização (atrasos);  Congestionamento; e  Consumo. A Figura 23 mostra uma planta de CI antes e após a atribuição de localização de células padrão. Bloco B RAM DRAM DP ROM Bloco A Bloco C Bloco B RAM DRAMDP ROM Bloco A Bloco C
  58. 58. 34 Figura 23: Die sem células padrão e com Placement realizado. O Placement recebe como entradas:  A netlist do circuito sintetizado;  As definições do Floorplanning (arquivo DEF);  As bibliotecas tecnológicas (LEF e Liberty);  As restrições de tempo no formato SDC; e  Os scripts com restrições e diretivas para execução dessa etapa. As saídas geradas pelo Placement são:  Netlist otimizada do projeto; e  Layout (arquivo DEF) com as células atribuídas aos devidos locais, de forma otimizada. Nesse processo, a área do die é composta por fileiras de altura fixa, onde cada fileira é composta por um número definido de posições (sites) que podem ser ocupadas por células padrão, macros ou pinos de entrada e saída. As células padrão geralmente costumam ter altura padrão, mas larguras variadas (sempre múltiplo do tamanho dos sites). Já os demais componentes podem ter tamanho variado de fileiras e sites [20]. Nas tecnologias mais antigas, com poucos níveis de metal, as fileiras precisam estar separadas para permitir o roteamento. Em todo caso, tais informações são definidas na biblioteca física LEF. A Figura 24 mostra um exemplo de layout de Placement.
  59. 59. 35 Figura 24: Layout do Placement. Alguns blocos podem ter tido sua localização atribuída, pelo Floorplanning, a um determinado local, mediante restrições de localização que podem ser classificadas desde as mais severas até as mais relaxadas. Em casos de restrições de localização severas, no processo de Placement, as células para tais blocos deverão ser atribuídas nestes locais. Já nos casos de restrições relaxadas, as células serão atribuídas livremente no processo de Placement [21]. De qualquer forma, ao fim do processo de Placement, as células estarão fixadas nas devidas posições, com o arquivo DEF sendo atualizado para refletir esta nova configuração. Tal arquivo será usado no roteamento do circuito integrado [19]. O problema com a estratégia de fazer o Placement antes do roteamento é que trabalha-se com valores estimados. Informações precisas de tempo de propagação dos sinais Células Padrão Macro Blocos Pinos de Entrada e Saída Fileiras
  60. 60. 36 dentro do CI só serão calculadas, com real precisão, depois que o layout estiver completo – tal precisão somente é obtida com a extração dos valores de resistências e capacitâncias parasitas, as quais são inseridas durante o roteamento. Neste contexto, se houver problema de temporização (isto é, se o circuito não atender as restrições de velocidade), o processo de Placement deverá ser executado novamente, já considerando as novas restrições de tempo calculadas. O Placement dirigido por restrições de temporização dá prioridade às células situadas nos caminhos mais críticos (maior atraso de propagação), para minimizar o atraso de propagação entre elas [19]. 4.4.3 Routing Uma vez que as células e macros foram inseridas no die, elas precisam ser conectadas. Para tanto, é feito o roteamento (Routing) dos fios internos do circuito integrado, conectando efetivamente os componentes do circuito entre si, de acordo com as chamadas regras de projeto (Design Rules) definidas pelo fabricante (foundry). Primeiro é necessário conectar os sinais de VDD e VSS na parte superior e inferior das células padrão, conforme destacado na Figura 25. Figura 25: Conexão de VDD e VSS.
  61. 61. 37 Na sequência, é feito o roteamento dos sinais que conectam as macros, células padrão e pinos de entrada e saída [23]. Como o processo de roteamento geralmente envolve conexões entre milhares, e até milhões de células, para lidar com tal complexidade, usa-se a estratégia de dividir para conquistar [20] [23]. Assim, a etapa de roteamento é subdividida em roteamento global e roteamento detalhado. Durante o processo de roteamento global, os fios são mapeados para grandes células globais de roteamento conhecidas como gcells, sem serem conectados (apenas é feita uma estimativa de quantos fios atravessam cada gcell). Já no roteamento detalhado, o processo é concluído com os fios efetivamente conectados aos pinos. O roteamento global abstrai o problema de roteamento através da noção de canais adjacentes ou células de roteamento global (gcell), contendo trilhas de roteamento, conforme pode ser visto na Figura 26. Nesse cenário, se a densidade de fios em um canal for muito alta, os fios podem ser movidos de um canal para outro [19]. Figura 26: Roteamento global. Capacidade de roteamento horizontal de Capacidade de roteamento vertical de 9 trilhas. gcell
  62. 62. 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
  63. 63. 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.
  64. 64. 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).
  65. 65. 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].
  66. 66. 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.
  67. 67. 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].
  68. 68. 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].
  69. 69. 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.
  70. 70. 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
  71. 71. 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.
  72. 72. 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.
  73. 73. 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.
  74. 74. 50 ● Quarta Etapa: Fluxo ASIC ○ Síntese Lógica; ○ Verificação Formal; ○ Floorplanning; ○ Placement; ○ Scan-Reorder; ○ CTS (Clock Tree Synthesis); ○ Routing; ○ Verificação Física; ○ RC Extraction; ○ STA, DRC e LVS; e ○ Geração de GDSII. 6.1 ARQUITETURA Duas arquiteturas foram modeladas e implementadas para executar a codificação requerida, através das etapas definidas nas equações (15), (16), (20) e (21), de forma otimizada. No início da execução, os valores intermediários = [ , , … ] são calculados de acordo com a equação (15) e armazenados temporariamente. Enquanto cada é calculado, ele é acumulado para compor o primeiro bloco de paridade – equação (16), sendo salvo na memória. Fisicamente, os valores são salvos nas posições reservadas para os blocos de paridade . A cada calculado, o respectivo é descartado da memória. Na sequência, o último bloco de paridade é calculado. Para executar esse procedimento, é necessário ter o primeiro bloco de paridade e o último valor intermediário prontos, para aplicá-los à equação (20). Por fim, a equação (21) pode ser aplicada para calcular as demais paridades.
  75. 75. 51 A chave para a modelagem de arquiteturas para codificadores LDPC, que usam a matriz base de código de verificação de paridade , é manipular as equações que satisfaçam a igualdade . = 0 – equação (9) – de modo que as expressões resultantes se adequem ao hardware que se quer implementar. A partir do rearranjo de algumas expressões, foi possível inferir a equação (21). Tal expressão permitiu calcular a paridade do final para o início, indo de até . Também foi possível balancear o cálculo de blocos de paridade de modo que, a cada nova paridade calculada, o respectivo valor temporário pudesse ser descartado. Além dessas otimizações, a escolha em calcular os blocos de paridade de maneira decrescente, possibilitou que o último valor a ser calculado em (15) , fosse o primeiro usado em (20), permitindo que esse valor temporário não precisasse ser armazenado e lido da memória. O fluxo geral de execução das arquiteturas produzidas é definido pela máquina de estados finita mostrada na Figura 30. No estado WAIT o sistema está aguardando um comando externo – quando uma nova configuração chega, o sistema vai para o estado START. No START, o hardware é inicializado com as configurações recebidas. Figura 30: Máquina de estados com o fluxo do processo de codificação LDPC.
  76. 76. 52 O estado SOMA LINHAS executa o processo de varrer uma linha em e o vetor informação , bloco a bloco, fazendo com que cada bloco seja deslocado circularmente para a esquerda, pelo valor em , , e acumulado no registrador de trabalho. A matriz é uma submatriz da matriz , conforme pode ser visto na Figura 31. Tal submatriz fica armazenada em uma ROM. Figura 31: Região útil da matriz Hb. Ao final do processamento de SOMA LINHAS, obtém-se o valor intermediário , o qual é guardado na memória reservada para e acumulado na posição de . Esse procedimento ocorre no estado GUARDA E ACUMULA. O processo iterativo entre os estados SOMA LINHAS e GUARDA E ACUMULA é feito até que todas as linhas tenham sido percorridas – equações (15) e (16). No final, tem-se os valores intermediários armazenados e o bloco de paridade zero calculado. Uma vez que está pronto, o estado CALCULA ÚLTIMA PARIDADE controla o cálculo de , equação (20), onde é deslocado circularmente para a esquerda pelo valor , (linha − em ) – Figura 31 – e somado com o valor intermediário , já guardado na posição de memória . O estado CALCULA PARIDADES controla o cálculo das demais paridades. Estas são calculadas de maneira similar à executada no estado CALCULA ÚLTIMA PARIDADE, só que o bloco de paridade calculado anteriormente, , também é somado - equação (21). Os dois outros estados controlam o descarregamento dos dados de informação e paridade. Neste trabalho foram desenvolvidas duas arquiteturas seriais, uma para funcionar como um coprocessador (considerando acesso compartilhado à memória do sistema) e outra com memória SRAM interna (tendo entrada serial de bits da informação a ser codificada). Pij kb mb nb Hb2 hb H'b1
  77. 77. 53 Ambas as arquitetura, são capazes executar a codificação de canal LDPC para 84 configurações, entre tamanhos taxa de códigos diferentes. 6.1.1 Arquitetura Com SRAM Interna O que chamamos de arquitetura serial é a estrutura de hardware modelada para funcionar com memória de trabalho (SRAM) própria e com operações internas executadas de maneira totalmente serial. Nesta arquitetura – Figura 32 – os dados são recebidos e tratados serialmente. Assim, na execução de cada iteração definida em (15), o deslocamento circular para a esquerda sobre o vetor , , . = ⋘ , , é feito utilizando um multiplexador e um demultiplexador de 96 entradas, que em termos de hardware é menos custoso que um barrel-shifter – Figura 33. Figura 32: Diagrama de blocos da arquitetura serial.
  78. 78. 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

×