2008.2Monografia Milton Cerqueira 2004.1

(1)

Decodificador de ´

Audio MPEG-2 AAC-LC:

Estruturas de Controle e Armazenamento

Feira de Santana - BA, Brasil

(2)

Decodificador de ´

Audio MPEG-2 AAC-LC:

Estruturas de Controle e Armazenamento

Monografia de Trabalho de Conclusão de Curso para obten¸cão do Grau de Bacharel em Engenharia de Computa¸cão pela Univer-sidade Estadual de Feira de Santana.

Orientador:

Prof. Dr. Wagner Luiz Alves de Oliveira

Curso de Engenharia de Computac¸˜ao Departamento de Tecnologia

Universidade Estadual de Feira de Santana

Feira de Santana - BA, Brasil

(3)

Esta monografia descreve o trabalho realizado sobre a especifica¸cão e a verifica¸cão fun-cional de módulos de controle e armazenamento para um decodificador de áudio MPEG-2 AAC-LC, de acordo com as especifica¸cões da norma ISO/IEC 13818-7. Esta norma de-fine um esquema de codifica¸cão/decodifica¸cão de áudio de alto desempenho, capaz de produzir áudio com qualidade superior a do mp3 e a do CD, devido a maior capacidade de armazenamento/transmissão, isto é, a maior quantidade de canais de áudio em um disco compacto. A especifica¸cão dos módulos baseou-se na metodologia ipProcess, a qual é voltada ao desenvolvimento de IP-Cores. Por outro lado, a verifica¸cão funcional dos módulos baseou-se na metodologia BVM (Brazil-IP Verification Methodology), a qual é suportada pela linguagem de descri¸cão de hardware SystemVerilog e pela metodologia de verifica¸cão OVM (Open Verification Methodology). Em rela¸cão aos módulos tratados, o módulo de armazenamento é responsável por opera¸cões de leitura e escrita relativas à uma memória interna, a qual armazena informa¸cões auxiliares, usadas pelos demais módulos do decodificador. Ao passo que, o módulo de controle é responsável por diversas ativi-dades: configura¸cão, ativa¸cão e desativa¸cão de módulos do decodificador; requisi¸cão de opera¸cões de leitura e escrita ao controlador de memória; controle de fluxo de dados entre módulos do decodificador; e controle de um conversor D/A Stereo (Stereo DAC).

(4)

This monograph reports a graduate work aimed at the functional especification and verification of control and storage modules for a MPEG-2 AAC-LC audio decoder, ac-cording to ISO/IEC 13818-7 standard. Such standard defines a high perfomance audio coding/decoding scheme, capable of producing superior quality audio when compared to mp3 and CD schemes, due to the larger data storage/transmission capacity, e.g., the greatest number of audio channels on a compact disc. The functional specification of the modules was based on the ipProcess methodology, which is turned to IP-Core de-velopment. On the other hand, their functional verification was based on the Brazil-IP Verification Methodology (BVM), which is supported by both the hardware description language SystemVerilog and the Open Verification Methodology (OVM). Regarding the developed modules, the storage one is responsible for reading and writing operations on an internal memory, which stores auxiliary information used by other modules of the de-coder. The other module - control - is responsible for several activities: configuration, activation and deactivation of the decoder modules, requisition of reading and writing operations to the memory controller, data flow control between modules of the decoder and control of a D/A Stereo (Stereo DAC) converter.

(5)

(6)

Agrade¸co primeiramente a Deus.

A minha fam´ılia, pelo apoio. Destacando a ajuda de Camila na revisão, corre¸cão e, principalmente, pelo seu carinho e paciência.

Ao professor Wagner pelo esfor¸co despendido na orienta¸cão e supervisão, além da paciência no decorrer do projeto.

(7)

Lista de Figuras

Lista de Tabelas

Lista de Abreviaturas e Siglas

1 Introdu¸c˜ao P. 13

1.1 Motiva¸c˜oes . . . P. 13

1.2 Padr˜ao do SBTVD-T . . . P. 15

1.3 Cons´orcio Brazil-IP . . . P. 16

1.4 Objetivos . . . P. 17

1.5 Estrutura da Monografia . . . P. 18

2 Fundamenta¸c˜ao Te´orica P. 19

2.1 A Fam´ılia MPEG . . . P. 19

2.2 O Padr˜ao MPEG–2 . . . P. 21

2.3 Modelo Psico-Ac´ustico . . . P. 21

2.4 Codifica¸c˜ao Avan¸cada de ´Audio – AAC . . . P. 22

2.5 Resumo . . . P. 28

3 Materiais e M´etodos P. 29

3.1 Metodologia . . . P. 29

3.1.1 ipProcess . . . P. 29

(8)

3.1.2.2 BVM . . . P. 33

3.1.2.3 eTBc . . . P. 35

4 Desenvolvimento e Resultados P. 37

4.1 ipProcess – Requisitos . . . P. 37

4.1.1 Documento de Especifica¸c˜ao de Requisitos . . . P. 37

4.1.2 Documento de Especifica¸c˜ao de Casos de Uso . . . P. 38

4.2 ipProcess – An´alise & Projeto . . . P. 42

4.2.1 Documento de An´alise . . . P. 42

4.2.2 Documento de Arquitetura . . . P. 44

4.3 ipProcess – Verifica¸c˜ao . . . P. 48

4.3.1 Plano de Verifica¸c˜ao . . . P. 48

4.3.2 Documento de Casos de Teste . . . P. 48

4.3.2.1 Controlador Principal . . . P. 49

4.3.2.2 Controlador de Mem´oria . . . P. 53

4.4 Verifica¸cão Funcional . . . P. 55 4.5 Resumo . . . P. 57 5 Discussão P. 58 6 Conclusões P. 59 Referências P. 60 Glossário P. 64

Apˆendice A -- ipProcess – Especifica¸c˜ao de Requisitos P. 68

A.1 Controlador Principal . . . P. 68

(9)

B.1 Controlador Principal . . . P. 71

B.2 Controlador de Mem´oria . . . P. 81

Apˆendice C -- ipProcess – Verifica¸c˜ao P. 89

C.1 Arquivo TLN . . . P. 89

C.2 Arquivo tb.sv . . . P. 90

C.3 Arquivo refmod ddr ctrl.svh . . . P. 92

(10)

1 PNAD – Domic´ılios com Bens Dur´aveis - 2005-2007. . . P. 15

2 Padr˜ao japonˆes ISDB-T. . . P. 16

3 Decodificador de ´audio MPEG-2 AAC-LC proposto – Chamada Brazil

IP 2008. . . P. 18

4 Sistema MPEG composto pelo codificador, canal de transmiss˜ao e

deco-dificador. . . P. 19

5 Sistema assim´etrico. . . P. 20

6 Fam´ılia MPEG normas 1, 2 , 4 e 7. . . P. 20

7 Fluxograma do ipProcess . . . P. 30

8 Fases do ipProcess . . . P. 31

9 Evolu¸c˜ao do custo em um projeto de CI . . . P. 32

10 Lei de Moore . . . P. 32

11 Metodologias BVM e OVM – Fluxo de projeto . . . P. 35

12 M´odulos do testbench gerados pelo eTBc. . . P. 36

13 Diagrama geral de casos de uso . . . P. 41

14 Diagrama geral de an´alise . . . P. 43

15 Diagrama geral de arquitetura – Camadas . . . P. 45

16 Diagrama de arquitetura – Acionar . . . P. 46

17 Diagrama de arquitetura – Disponibilizar Amostras . . . P. 47

18 Diagrama de arquitetura – Executar Opera¸c˜ao . . . P. 47

(11)

1 Compara¸c˜oes entre o AAC e o MP3 . . . P. 22

2 M´odulos do decodificador AAC . . . P. 23

3 Interoperabilidade entre perfis AAC . . . P. 23

4 Caso de Teste Direcionado relacionado ao Controlador Principal . . . . P. 49

(12)

AAC Codifica¸cão Avan¸cada de Áudio (Advanced Audio Coding) AVM Metodologia de Verifica¸cão Avan¸cada (Advanced Verification

Methodology)

Brazil-IP Programa de Desenvolvimento de Propriedade Intelectual de Semicondutores do Brasil (Brazil Semiconductor Intellectual Property)

BVM Metodologia de Verifica¸c˜ao do Brazil-IP (Brazil-IP Verification Methodology)

CMS Controlador de Mem´oria do Sistema

CNPq Conselho Nacional de Desenvolvimento Cient´ıfico e Tecnol´ogico (National Counsel of Technological and Scientific Develop-ment )

CP Controlador Principal

DPCM Modula¸c˜ao por C´odigo de Pulso Diferencial (Differential Pulse Code Modulation)

DSM-CC Comando e Controle para M´ıdia de Armazenamento Digital (Digital Storage Media Command and Control )

DUT Dispositivo sob Teste, Projeto sob Teste (Device Under Test, Design Under Test )

DUV Projeto sob Verifica¸c˜ao (Design Under Verification)

EDA Automa¸c˜ao de Projetos Eletrˆonicos (Eletronic Design Automa-tion)

eTBc Gerador Auxiliar de Testbench (Easy Testbench Creator ) FPGA Arranjo de Portas L´ogicas Program´avel no Local (Field

Pro-grammable Gate Array)

IBGE Instituto Brasileiro de Geografia e Estat´ıstica

IMDCT Transformada Discreta Modificada Inversa de Cosseno (Inverse Modified Discrete Cosine Transform)

(13)

ISDB-T Servi¸co Integrado de Transmiss˜ao Digital Terrestre (Integrated Services Digital Broadcasting Terrestrial )

ISO Organiza¸c˜ao Internacional de Padr˜oes (International Standards Organization)

MCT Ministério da Ciência e Tecnologia MEF Máquina de Estados Finitos

MPEG Grupo de Peritos em Imagens Dinˆamicas (Moving Picture Ex-perts Group)

NBC Compatibilidade n˜ao Retroativa (Non Backward Compatible) OVM Metodologia de Verifica¸c˜ao Aberta (Open Verification

Metho-dology)

PADIS Programa de Apoio ao Desenvolvimento Tecnol´ogico da Ind´ustria de Semicondutores

PATVD Programa de Apoio ao Desenvolvimento Tecnol´ogico da Ind´ustria de Equipamentos para a TV Digital

PCM Modula¸cão por Código de Pulso (Pulse Code Modulation) PQF Filtro de Quadratura Polifásica (Polyphase Quadrature Filter ) RUP Processo Unificado da Rational (Rational Unified Process) SBTVD-T Sistema Brasileiro de Televisão Digital Terrestre

TLM Modelagem em N´ıvel de Transa¸c˜oes (Transaction-Level Mode-ling)

TSN Modelador de Ru´ıdo Temporal (Temporal Noise Shapping) UML-RT Linguagem de Modelagem Unificada para Tempo Real (Unified

Modeling Language for Real Time)

URM Metodologia de Re´uso Universal (Universal Reuse Methodo-logy)

VLSI Integra¸c˜ao em Escala Muito Ampla (Very Large Scale Integra-tion)

(14)

1 Introdu¸

c˜

ao

Esta monografia aborda o desenvolvimento de módulos que compõem um sistema maior, a saber, o Decodificador de Áudio AAC-LC. A partir dessa análise, novos conceitos concernentes ao contexto de desenvolvimento de IP-Cores serão apresentados. Neste cap´ıtulo contextualiza-se o presente trabalho, além de se apresentar os objetivos e sua estrutura.

1.1 Motiva¸

c˜

oes

Em fase de implanta¸cão no pa´ıs, a TV digital supera a analógica principalmente nos aspectos de qualidade de imagem e interatividade, através do uso de vários tipos de circuitos/esquemas, seja na capta¸cão, transmissão e reprodu¸cão de áudio e v´ıdeo ( ROES-LER, 2007). Esse novo sistema, ao trabalhar com sinal digital, irá ampliar o potencial do sistema de televisão atual, além de gerar avan¸cos nos cenários social, econômico e cient´ıfico-tecnológico.

O decreto n.o _{5.820, de 29 de Junho de 2006(}_BRASIL_{, 2006) define o SBTVD-T} (Sis-tema Brasileiro de Televisão Digital Terrestre) como o conjunto de padrões tecnológicos a serem adotados para transmissão e recep¸cão de sinais digitais terrestres de radiodifusão de sons e imagens. O decreto n.o _{4.901, de 26 de novembro de 2003 (}_BRASIL_{, 2003) define} um conjunto de objetivos para a implanta¸cão do SBTVD-T:

I - promover a inclusão social, a diversidade cultural do Pa´ıs e a l´ıngua pátria por meio do acesso à tecnologia digital, visando à democratiza¸cão da informa¸cão;

II - propiciar a cria¸cão de rede universal de educa¸cão à distância;

III - estimular a pesquisa e o desenvolvimento e propiciar a expansão de tecnologias brasileiras e da indústria nacional relacionadas à tecnologia de informa¸cão e comu-nica¸cão;

(15)

IV - planejar o processo de transi¸cão da televisão analógica para a digital, de modo a garantir a gradual adesão de usuários a custos compat´ıveis com sua renda;

V - viabilizar a transi¸cão do sistema analógico para o digital, possibilitando às conces-sionárias do servi¸co de radiodifusão de sons e imagens, se necessário, o uso de faixa adicional de radiofreqüência, observada a legisla¸cão espec´ıfica;

VI - estimular a evolu¸cão das atuais exploradoras de servi¸co de televisão analógica, bem assim o ingresso de novas empresas, propiciando a expansão do setor e possibilitando o desenvolvimento de inúmeros servi¸cos decorrentes da tecnologia digital, conforme legisla¸cão espec´ıfica;

VII - estabelecer a¸cões e modelos de negócios para a televisão digital adequados à reali-dade econômica e empresarial do Pa´ıs;

VIII - aperfei¸coar o uso do espectro de radiofreq¨uˆencias;

IX - contribuir para a convergência tecnológica e empresarial dos servi¸cos de comu-nica¸cões;

X - aprimorar a qualidade de ´audio, v´ıdeo e servi¸cos, consideradas as atuais condi¸c˜oes do parque instalado de receptores no Brasil; e

XI - incentivar a ind´ustria regional e local na produ¸c˜ao de instrumentos e servi¸cos digi-tais.

A televisão é um dos equipamentos com maior penetra¸cão social, sendo várias as oportunidades de explora¸cão. Desde a explora¸cão educacional, programas educacionais `

a distância que interagem com os alunos, até a explora¸cão comercial e programas com catálogos 3D, nos quais o consumidor pode interagir com o produto solicitando a com-pra on-line. Segundo dados da Pesquisa Nacional por Amostra de Domic´ılios 2007 do IBGE (Instituto Brasileiro de Geografia e Estat´ıstica, 2007) mais de 94% dos lares (domic´ılios particulares permanentes) brasileiros possuem televisão, como apresentado na Figura 1.

A implanta¸cão da TV Digital é uma ótima oportunidade para o fortalecimento de vários setores, principalmente aqueles vinculados ao desenvolvimento e produ¸cão de cir-cuitos integrados (CI). Segundo o secretário de Pol´ıtica de Informática do MCT, Augusto Gadelha, atualmente toda a demanda de CI’s do Brasil é importada, o que contribui para o déficit da balan¸ca comercial (GODOI, 2008). Nesse contexto, o governo, através de um conjunto de medidas, procura fortalecer o setor de eletrônica tornando-o menos

(16)

Figura 1: PNAD – Domic´ılios com Bens Dur´aveis - 2005-2007.

dependente de importa¸cões. Uma dessas medidas foi a Lei n.o 11.484 de maio de 2007 (BRASIL, 2007) que criou dois programas: O PADIS (Programa de Apoio ao Desenvolvi-mento Tecnológico da Indústria de Semicondutores) e o PATVD (Programa de Apoio ao Desenvolvimento Tecnológico da Indústria de Equipamentos para a TV Digital). Ambos possuem a meta de proteger a topologia de circuitos integrados, visando incentivar pesqui-sas relacionadas a esses circuitos, de forma a impulsionar o desenvolvimento tecnológico do Pa´ıs nesse setor industrial. Mais especificamente no PADIS, o governo assegura uma série de incentivos fiscais às empresas que investirem em pesquisa e desenvolvimento (P&D) e produzirem componentes eletrônicos associados à TV Digital.

1.2 Padr˜

ao do SBTVD-T

O SBTVD-T adotou como base (Art. 5odo decreto n.o 5.820, de 29 de Junho de 2006) o padrão de sinais do ISDB-T (Servi¸co Integrado de Transmissão Digital Terrestre – Inte-grated Services Digital Broadcasting Terrestrial ), incorporando as inova¸cões tecnológicas aprovadas pelo Comitê de Desenvolvimento de que trata o Decreto n.o _{4.901, de 26 de} no-vembro de 2003. Dentre essas inova¸cões devem ser destacadas as modifica¸cões no codec de v´ıdeo e áudio, sendo H.264AVC com áudio AAC-LC (5.1) no programa principal (único ou multi) e v´ıdeo H.264AVC com áudio HE-AAC no sub-programa para móveis. Ambos são padrões de codifica¸cão e decodifica¸cão superiores àqueles presentes no ISDB-T(BECHARA, 2007). A Figura 2 apresenta o modelo japonês.

(17)

Figura 2: Padr˜ao japonˆes ISDB-T.

1.3 Cons´

orcio Brazil-IP

Como definido no documento The Brazil-IP Network (ARA ÚJO, 2002), o Brazil-IP (Propriedade Intelectual do Brasil – Brazil Intelectual Property) é um consórcio de la-boratórios e universidades brasileiras que visa a produ¸cão, estrutura¸cão e confeçcão de circuitos integrados VLSI (Integra¸cão em Escala Muito Ampla – Very Large Scale Inte-gration) e IP-Cores (Núcleo de Propriedade Intelectual – Intellectual Property Core). O programa de capacita¸cão desenvolvido por este consórcio é apoiado com recursos do MCT (Ministério da Ciência e Tecnologia), implementados pelo CNPq (Conselho Nacional de Desenvolvimento Cient´ıfico e Tecnológico), sendo o programa acompanhado pelas duas institui¸cões.

A missão do Brazil-IP pode ser dividida em duas partes. Em primeiro lugar, deve ser criada a competência nacional para projetar circuitos, colocando as institui¸cões de pesquisa e desenvolvimento em contato com práticas de projeto e verifica¸cão de padrão internacional. É também missão do consórcio a cria¸cão de massa cr´ıtica no projeto de IP-Cores, proporcionando a cria¸cão de start ups de Design Houses no pa´ıs, as quais são unidades de produ¸cão e desenvolvimento de projetos de CI’s. Para isso, essa rede emprega o processo de desenvolvimento de IP-Cores ipProcess, como também uma metodologia de verifica¸cão funcional, ambos serão descritos no cap´ıtulo 3.

A UEFS, a partir de 2008, passou a integrar o Programa Brazil-IP, através do projeto intitulado “Decodificador de Áudio MPEG-2 AAC-LC”. Atualmente, a equipe vinculada ao Programa Brazil-IP/UEFS desenvolve o IP-Core de um decodificador de áudio MPEG-2 AAC-LC, de acordo com as especifica¸cões da norma ISO/IEC 13818-7 (MPEG, 1997). Este decodificador será explicado no cap´ıtulo 2 desta monografia, visto que a mesma relata o trabalho de desenvolvimento de parte de tal decodificador.

(18)

1.4 Objetivos

No contexto descrito nas se¸cões anteriores, esta monografia relata um trabalho de conclusão de curso desenvolvido junto ao Programa Brazil-IP/UEFS. Como o projeto do Decodificador de Áudio MPEG-2 AAC-LC tem escopo muito amplo (a Figura 3 apresenta seus módulos constituintes), coube o desenvolvimento de uma parte do mesmo ao executor do presente trabalho, a qual é identificada pelos seguintes módulos (em destaque na Figura 3):

Controlador de memória interna : Módulo de controle de opera¸cões de leitura/es-crita relativas à Memória Interna, a qual armazenará informa¸cões auxiliares, usadas pelos demais módulos;

Controlador principal do decodificador : Módulo de controle, responsável por várias tarefas, a saber:

I - requisi¸c˜ao de leitura de blocos do arquivo AAC selecionado pela Interface com Usu´ario;

II - configura¸cão/ativa¸cão/desativa¸cão de módulos;

III - requisi¸cão de opera¸cões de leitura/escrita ao Controlador de Memória Interna, de acordo com solicita¸cões dos módulos;

IV - controle de fluxo de dados entre m´odulos;

V - controle do conversor D/A Stereo (Stereo DAC).

A implementa¸cão destes módulos está sendo feita na linguagem de descri¸cão de hard-ware SystemVerilog. Espera-se que os resultados obtidos neste protótipo, a ser desenvol-vido em FPGA, sejam incorporados ao projeto do circuito integrado em desenvolvimento no âmbito UEFS/Brazil-IP, referente ao reprodutor de áudio MPEG-2 AAC-LC.

Assim, este trabalho trata de uma área de pesquisa emergente, principalmente em rela¸cão às novas tendências de TV Digital, eletrônica de consumo e formatos de v´ıdeo para transferência via Internet.

(19)

Figura 3: Decodificador de ´audio MPEG-2 AAC-LC proposto – Chamada Brazil IP 2008.

1.5 Estrutura da Monografia

No cap´ıtulo 2 são apresentados os conhecimentos necessários para o desenvolvimento deste trabalho, descrevendo a fam´ılia de padrões MPEG, com ênfase no padrão MPEG-2 e no esquema de codifica¸cão de áudio AAC (Advanced Audio Coding), incluindo o modelo psico-acústico utilizado em tal esquema. O cap´ıtulo 3 aborda os materiais e métodos utili-zados para o desenvolvimento do trabalho, envolvendo metodologias e técnicas utilizadas. O cerne do trabalho encontra-se no cap´ıtulo 4, o qual descreve o processo de desenvolvi-mento, bem como os resultados em consoante aos documentos dos apêndices. O cap´ıtulo 5 analisa aspectos referentes ao desenvolvimento do trabalho, concernente a dificuldades, escopo e trabalhos futuros. Por fim, o cap´ıtulo 6 discorre sobre as conclusões acerca do trabalho descrito nesta monografia, contribui¸cões e tópicos concernentes ao Projeto Brazil-IP/UEFS.

(20)

2 Fundamenta¸

c˜

ao Te´

orica

Esta se¸cão trata dos conceitos necessários para o desenvolvimento do projeto. Serão abordados a fam´ılia MPEG, o conjunto de padrões MPEG-2, o modelo psico-acústico e o padrão de codifica¸cão digital de áudio MPEG-2 – AAC. No decorrer das se¸cões serão descritos conceitos associados à codifica¸cão de sinais de áudio.

2.1 A Fam´ılia MPEG

O grupo MPEG, acrônimo para Moving Picture Experts Group, iniciou seus trabalhos em 1988 como um grupo de trabalho da ISO (Organiza¸cão Internacional de Padrões – International Standard Organization) com o objetivo de definir padrões de compressão digital de sinais de áudio e v´ıdeo (CASTRO; CASTRO, 2001). O nome MPEG também designa a fam´ılia de padrões desenvolvida pelo grupo, o qual é formado pelos subgrupos JTC1/SG29/WG11. O MPEG se tornou umas das mais populares técnicas de compressão de áudio e v´ıdeo, não só por causa da sua eficiência, mas também pela grande gama de aplica¸cões que consegue atender com base no mesmo princ´ıpio.

O MPEG define o modo como o decodificador deverá interpretar o bitstream (fluxo de dados) (WATKINSON, 2001). Assim, ele define um esquema de decodifica¸cão ou descom-pressão, mas não define um esquema para a codifica¸cão ou compressão, todavia, o fluxo de dados gerado pelo codificador deve seguir o padrão proposto. O sistema MPEG, isto é, o conjunto formado pelo codificador, canal de transmissão e o decodificador, vide Figura 4, é um sistema assimétrico, ou seja, o codificador é mais complexo que o decodificador, como apresenta a Figura 5.

Figura 4: Sistema MPEG composto pelo codificador, canal de transmiss˜ao e decodificador.

(21)

Figura 5: Sistema assim´etrico.

outros, na qual a quantidade de codificadores complexos e caros ´e pequena, enquanto a quantidade de decodificadores simples e baratos ´e grande.

A fam´ılia MPEG é composta por várias normas como o MPEG 1, 2, 4, 7 e 21. Con-forme a Figura 6, as normas 1, 2 e 4 são direcionadas para a compressão eficiente de dados, ou seja, a representa¸cão de conteúdos audiovisuais com o melhor custo x benef´ıcio (ISO/IEC, 1996)(ISO/IEC, 2000)(ISO/IEC, 2002b). A partir da norma 4, houve uma preo-cupa¸cão maior com a semântica (FARIA; ZUFFO, 2000). A norma 7 ou MPEG-7 trata da

descri¸cão semântica dos dados do conteúdo multim´ıdia, que suportem algum grau de in-terpreta¸cão do significado da informa¸cão (ISO/IEC, 2004). Por fim, o MPEG-21 padroniza um open framework para distribui¸cão e consumo de conteúdo multim´ıdia. A meta é gerar uma tecnologia que auxilie os usuários na troca, acesso, consumo, comércio e, portanto, a manipular de modo eficiente, transparente e interoperável o conteúdo multim´ıdia(ISO/IEC, 2002a).

(22)

2.2 O Padr˜

ao MPEG–2

O MPEG-2 ´e a 2a _{fase do MPEG, sendo um aprimoramento do MPEG-1. Ele ´}_e composto pelos seguintes padr˜oes:

ISO/IEC 13818-1 : Sistema (Systems)

ISO/IEC 13818-2 : V´ıdeo (Video)

ISO/IEC 13818-3 : ´Audio (Audio)

ISO/IEC 13818-4 : Teste de Conformidade (Compliance Testing)

ISO/IEC 13818-5 : Software

ISO/IEC 13818-6 : DSM-CC1

ISO/IEC 13818-7 : ´Audio NBC (AAC)

ISO/IEC 13818-8 : V´ıdeo 10-Bit (Abandonado)

ISO/IEC 13818-9 : Interface em Tempo real (Real-Time Interface)

ISO/IEC 13818-10 : Conformidade DSM-CC

O padrão do dispositivo em desenvolvimento Brasil-IP/UEFS, vide se¸cão 1.3, compõe o MPEG-2, especificamente a norma ISO/IEC 13818-7.

2.3 Modelo Psico-Ac´

ustico

O modelo psico-acústico é um modelo matemático que relaciona as propriedades f´ısicas dos sons, que podem ser medidas cientificamente, com as respostas fisiológicas e psi-cológicas geradas por elas. Esse modelo permite aos codificadores explorarem o fato que informa¸cões “irrelevantes” do sinal não são detectadas, até mesmo, por um ouvinte bem treinado(SPANIAS; PAINTER, 2000). Informa¸cões irrelevantes são identificadas durante a análise, ao incorporar ao codificador diversos princ´ıpios psico-acústicos, incluindo limiar

1_{E um conjunto de ferramentas para desenvolver os canais de controle associados a um stream MPEG-1}_´

(23)

absoluto de audi¸cão, análise de freqüência de banda cr´ıtica, mascaramento simultâneo, dispersão do mascaramento pela membrana basilar2 e mascaramento temporal.

Nos codificadores perceptivos, o modelo psico-acústico desempenha a fun¸cão mais im-portante. As informa¸cões geradas alimentam outros blocos do decodificador, responsáveis pela processo restante de codifica¸cão.

2.4 Codifica¸

c˜

ao Avan¸

cada de ´

Audio – AAC

O AAC, também conhecido como NBC Audio, é um padrão de codifica¸cão de áudio definido no documento ISO/IEC 13818-7 (MPEG, 1997). Ele e seus sucessores são, atual-mente, os membros mais poderosos na fam´ılia MPEG para compressão de áudio digital, multicanal e de alta qualidade. Devido a restri¸cões impostas pela compatibilidade com as versões anteriores, o MPEG-1 (Layer I, Layer II e Layer III ), o grupo MPEG desenvolveu dois padrões de compressão de áudio para a fam´ılia MPEG-2, o BC e o AAC. O primeiro mantém compatibilidade e por isso perde em eficiência, pois deixa de explorar certas técnicas avan¸cadas, as quais são exploradas pelo MPEG-2 ACC, que possui boas taxa de compressão e qualidade em rela¸cão aos demais. A Tabela 1 demonstra a superioridade técnica do AAC em rela¸cão ao MP3.

Tabela 1: Compara¸c˜oes entre o AAC e o MP3

Caracter´ıstica AAC MP3

Canais 48 5

Taxa de amostragem 96kHz 48kHZ Taxa de compress˜ao 15:1 11:1 Kilobytes/minuto 670kB 900kB

O ISO/IEC 13818-7 definiu três perfis para o padrão MPEG-2 AAC, descritos a seguir (veja informa¸cões sobre módulos adiante):

• Main Profile (MP) – Ideal quando o custo de recursos de memória for insig-nificante e houver substancial poder de processamento. Utiliza todos os módulos, exceto o controle de ganho. Gera a melhor compressão poss´ıvel.

2_{E uma fina membranana, presente no interior da c´}´ _{oclea (ouvido interno). Sua superf´ıcie ´}_{e formada} por cerca de 25.000 a 30.000 estruturas finas, conhecidas como fibras basilares, com a forma de palheta, as quais se projetam de um dos lados da membrana e aparecem ao longo de toda a sua extensão. Essa membrana possui uma frequência de ressonância que varia conforme a extensão da mesma, assim diferentes frequências de ondas sonoras estimulam (ressoam) diferentes por¸cões da membrana, ativando as fibras ali presentes.

(24)

• Low Complexity (LC) – Utilizado quando houver restri¸cões de poder de proces-samento, recurso de memória e compressão. O perfil low complexity não permite a utiliza¸cão do preditor e do controle de ganho, além disso a ordem do filtro TNS (Mo-delador de Ru´ıdo Temporal – Temporal Noise Shapping) é limitada, o que contribui para o menor consumo de memória e poder computacional.

• Scalable Sampling Rate (SSR) – A ferramenta de controle de ganho é obri-gatória. Não engloba o preditor e os canais acoplados, além de limitar a ordem do filtro TNS e a largura de banda.

Considerando o decodificador AAC, o mesmo utiliza um conjunto de módulos obri-gatórios e um conjunto de opcionais no processo de decodifica¸cão. A Tabela 2 demonstra os módulos e sua obrigatoriedade. Os módulos necessários são obrigatórios em qualquer perfil, enquanto a presen¸ca dos opcionais depende do perfil.

Tabela 2: M´odulos do decodificador AAC

M´odulos Obrigat´orio/Opcional

Deformatador de bitstream Obrigat´orio Decodificador sem Ru´ıdo Obrigat´orio

Quantizador Inverso Obrigat´orio

Reescalador Obrigat´orio

M/S Opcional

Preditor Opcional

Intensity Stereo Opcional

Acoplamento Chaveado Dependentemente Opcional TNS (Modelador de Ru´ıdo Temporal) Opcional Banco de Filtros/Chaveamento de Blocos Obrigat´orio

Controle de Ganho Opcional

Acoplamento Chaveado Independentemente Opcional

A Tabela 3 apresenta a compatibilidade de perfis entre um codificador e um decodi-ficador.

Tabela 3: Interoperabilidade entre perfis AAC Perfil do Codificador Perfil do Decodificador Main Profile LC SSR

Main Profile sim sim n˜ao

LC n˜ao sim n˜ao

SSR n˜ao n˜ao sim

O decodificador proposto, vide se¸cão 1.3, possui a estrutura interna ilustrada na Figura 3. Essa estrutura é composta por módulos com objetivos espec´ıficos que no conjunto

(25)

im-plementam o algoritmo de decodifica¸cão AAC LC, o qual decodifica um bitstream padrão ISO/IEC 13818-7, gerando valores PCM. Quando um módulo é opcional, todos os dados passam por ele sem ocorrer modifica¸cão nos mesmos. Todos os módulos propostos pelo padrão supracitado são analisados a seguir.

• Demultiplexador de bitstream – Recebe o fluxo de dados e separa as por¸cões de dados do fluxo MPEG-AAC em partes para cada módulo, além de fornecer a cada um informa¸cões de configura¸cão relacionadas ao próprio. As sa´ıdas do demultiplexador de bitstream são:

– Informa¸c˜oes da se¸c˜ao referentes aos espectros codificados sem ru´ıdo;

– Os espectros codificados sem ru´ıdo;

– Informa¸c˜oes de decis˜ao do M/S (opcional);

– Informa¸c˜oes de estado do preditor (opcional);

– Informa¸c˜oes do controle intensity stereo e de controle de canal acoplado (ambos opcionais);

– Informa¸c˜oes do TNS (Modelador de Ru´ıdo Temporal – Temporal Noise Shap-ping) (opcional);

– Informa¸c˜oes do controle do banco de filtros; e

– Informa¸c˜oes do controle de ganho (opcional).

• Decodificador sem ru´ıdo – Analisa a informa¸cão do demultiplexador, decodi-fica os dados codidecodi-ficados de Huffman, reconstrói o espectro quantizado e os fatores de escala de Huffman e do DPCM (Modula¸cão por Código de Pulso Diferencial – Differential Pulse Code Modulation). As entradas do decodificador sem ru´ıdo são:

– Informa¸c˜oes da se¸c˜ao referentes aos espectros codificados sem ru´ıdo; e

– Os espectros codificados sem ru´ıdo.

As sa´ıdas do decodificador sem ru´ıdo s˜ao:

– A representa¸c˜ao inteira decodificada dos fatores de escala; e

– Os valores quantizados dos espectros.

• Quantizador inverso – Obtém os valores quantizados do espectro e converte os valores inteiros para não escalados. Este quantizador é não uniforme. As entradas do quantizador inverso são:

(26)

– Os valores quantizados do espectro.

A sa´ıda do quantizador inverso ´e:

– Os espectros quantizados inversamente e n˜ao escalados.

• Reescalador – Converte a representa¸cão inteira dos fatores de escala para valores atuais, multiplica o espectro quantizado inversamente e não escalado pelos respec-tivos fatores de escala. As entradas do reescalador são:

– A representa¸c˜ao inteira decodificada dos fatores de escala; e

– Os espectros quantizados inversamente e n˜ao escalados.

A sa´ıda do reescalador ´e:

– Os espectros quantizados inversamente e escalados.

• M/S – Converte os pares de espectros de Mid /Side3_{para Left /Rigth (canais est´}_ereos) mediante informa¸cões de controle, no sentido de melhorar a eficiência da compressão. As entradas do M/S são:

– As informa¸c˜oes de controle do M/S; e

– Os espectros quantizados inversamente e escalados relacionados aos pares de canais.

A sa´ıda do M/S ´e:

– Os espectros quantizados inversamente e escalados relacionados aos pares de canais, depois da decodifica¸c˜ao de M/S.

• Preditor – Reverte o processo de predi¸cão executado no codificador. Ele reinsere os dados redundantes que foram extra´ıdos pelo preditor no codificador. Esse processo ocorre sob controle das informa¸cões de estado do preditor. As entradas do preditor são:

– Informa¸c˜oes de estado do preditor; e

– Os espectros quantizados inversamente e escalados.

A sa´ıda do preditor ´e:

(27)

– Os espectros quantizados inversamente e escalados, depois que a predi¸c˜ao ´e realizada.

• Intensity Stereo – Realiza a decodifica¸c˜ao intensity stereo nos pares do espectros. As entradas do intensity stereo s˜ao:

– Os espectros quantizados inversamente; e

– As informa¸c˜oes do controle intensity stereo.

A sa´ıda do intensity stereo ´e:

– Os espectros quantizados inversamente, ap´os decodifica¸c˜ao de intensidade dos canais.

• Acoplamento chaveado dependentemente – Adiciona dados pertinentes aos canais acoplados e chaveados dependentemente para o sinal de tempo, como direci-onado pelas informa¸c˜oes de controle de acoplamento. As entradas do acoplamento chaveado dependente s˜ao:

– As informa¸c˜oes de controle do acoplamento.

A sa´ıda do acoplamento chaveado dependente ´e:

– O sinal de tempo vinculado aos canais acoplados e chaveados dependentemente.

• Acoplamento chaveado independentemente – Adiciona dados pertinentes ao canais acoplados e chaveados independentemente para o sinal de tempo, como dire-cionado pelas informa¸c˜oes de controle de acoplamento. As entradas do acoplamento chaveado independente s˜ao:

– O tempo de sinal, o qual ´e sa´ıda do banco de filtros; e

– As informa¸c˜oes de controle do acoplamento.

A sa´ıda do acoplamento chaveado independente ´e:

– O sinal de tempo vinculado aos canais acoplados e chaveados independente-mente.

• Modelador de Ru´ıdo Temporal (TNS) – Realiza o controle fino da estrutura de tempo do ru´ıdo codificado. No codificador, o processo do TNS modela o envelope

(28)

temporal ao modificar informa¸cões estruturais do mesmo. Por outro lado, no deco-dificador, o processo inverso é utilizado para restaurar o(s) envelope(s) temporal(is) original(is), sendo realizado sob controle das informa¸cões do TNS. Isso é feito ao aplicar um processo de filtragem em por¸cões dos dados espectrais. As entradas do TNS são:

– As informa¸c˜oes TNS.

A sa´ıda do TNS ´e:

– Os espectros quantizados inversamente.

• Banco de Filtros/Chaveamento de Blocos – Aplica a inversa do mapeamento em frequˆencia que foi realizado no codificador. O filtro de bancos utiliza a IMDCT (Transformada Discreta Modificada Inversa de Cosseno – Inverse Modified Discrete Cosine Transform). Esta pode ser configurada para suportar tanto 1 conjunto de 128 ou 1024 coeficientes espectrais, quanto 4 conjuntos de 32 ou 256 coeficientes espectrais. As entradas do Banco de Filtros/Chaveamento de Blocos s˜ao:

– As informa¸c˜oes de controle do banco de filtros.

As sa´ıda do Banco de Filtros/Chaveamento de Blocos:

– Os sinais de ´audio reconstru´ıdos no dom´ınio do tempo.

• Controle de Ganho – Quando presente, aplica um controle de ganho no dom´ınio do tempo separado para cada uma das 4 bandas de frequências criadas pelo banco de filtros PQF (Filtro de Quadratura Polifásica – Polyphase Quadrature Filter )4 do controle de ganho no codificador. Então, ele reuni as 4 bandas de frequências e reconstrói a onda temporal através do banco de filtros do controle de ganho. É utilizado apenas no perfil SSR. As entradas do controle de ganho são:

– Os sinais de ´audio reconstru´ıdos no dom´ınio do tempo; e

– As informa¸c˜oes de controle de ganho.

4_{E um filtro que divide o sinal de entrada em um dado n´}_´ _{umero N (normalmente potˆ}_{encia de 2) de}

sub-bandas equidistantes. Essas sub-bandas s˜ao subamostras por um fator de N, sendo criticamente amostradas.

(29)

As sa´ıda do controle de ganho:

– Os sinais de ´audio reconstru´ıdos no dom´ınio do tempo.

2.5 Resumo

Este cap´ıtulo forneceu informa¸cões necessárias para a correta execu¸cão deste traba-lho. A fam´ılia MPEG apresenta padrões bastante conhecidos e explorados comercial-mente. Particularmente, o AAC é o mais poderoso algoritmo de compressão de áudio dessa fam´ılia. Ele possui técnicas complexas e avan¸cadas de compressão, as quais explo-ram tanto o modelo psico-acústicos, como outros algoritmos de compressão de dados, por exemplo, a codifica¸cão de Huffman.

(30)

3 Materiais e M´

etodos

3.1 Metodologia

Esta se¸cão trata das metodologias utilizadas nesse projeto, a saber, o ipProcess e a metodologia de verifica¸cão BVM (Metodologia de Verifica¸cão do Brazil-IP – Brazil-IP Verification Methodology), assim como a ferramenta eTBc utilizada no BVM.

3.1.1 ipProcess

O ipProcess é um processo para desenvolvimento de IP-Core com implementa¸cão em FPGA, elaborado pela rede Brazil-IP, como resultado do projeto Fênix (BARROS et al., 2005). A meta desse processo é garantir a qualidade do projeto de cada componente do sistema no decorrer do processo de desenvolvimento de um IP-Core.

Seus principais pilares s˜ao:

• Projeto iterativo e incremental, diagramas UML-RT (Linguagem de Modelagem Unificada para Tempo Real) (OMG, 2009);

• Uso de diretrizes (guidelines) de codifica¸c˜ao;

• Verifica¸c˜ao; e

• Programa¸c˜ao em pares5_.

A versão atual do ipProcess, conforme (BARROS et al., 2005), é definida por cinco principais fluxos de trabalho (workflow ), conforme Figura 7. Cada fluxo é descrito a seguir:

5_Pr´_{atica utilizada na metodologia ´}_{agil XP (eXtreme Programming – Programa¸}_c˜_{ao Extrema), a qual}

sugere que todo e qualquer c´odigo produzido no projeto seja sempre implementado por duas pessoas juntas.

(31)

Requisitos – Estabelece e documenta as necessidades do cliente e de outros usuários, consoante ao que o IP-Core deve fazer, de forma a fornecer à equipe de desen-volvimento melhor entendimento sobre os requisitos funcionais e não funcionais do sistema;

An´alise & Projeto – De acordo com os documento de requisitos, cria-se um projeto de IP-core, compatibilizando-o ao ambiente de implementa¸c˜ao;

Implementa¸cão – Define a organiza¸cão da codifica¸cão, implementa os elementos do projeto e, após, realiza teste de unidade nos módulos desenvolvidos;

Verifica¸cão – Avalia a qualidade do IP-Core no sentido de verificar se os requisitos foram implementados como especificado, além de procurar e descrever defeitos na implementa¸cão e validar as funcionalidades do mesmo; e

Prototipa¸c˜ao em FPGA – Sintetiza a implementa¸c˜ao em um FPGA e valida os requi-sitos como especificados no fluxo de trabalho Requirequi-sitos.

Figura 7: Fluxograma do ipProcess

Cada fluxo de trabalho mencionado acima é definido em termos de fun¸cões, atividades e cria¸cão de artefatos (diagramas UML, documentos, linhas de código, etc), estes artefatos podem ser reutilizados como entrada em um fluxo de trabalho subseqüente, respeitando a ordem das fases apresentadas na Figura 8, a qual também apresenta a evolu¸cão temporal de cada fluxo. Os artefatos são importantes, pois definem o escopo do projeto, fornecendo de forma clara o objetivo do projeto e como executá-lo, além de permitir que todo o desenvolvimento esteja de acordo com os anseios do cliente. Como não é escopo desse trabalho delinear minuciosamente o ipProcess, mais detalhes podem ser obtidos em (LIMA, 2005).

(32)

Figura 8: Fases do ipProcess

Esse processo tem sido utilizado no treinamento de estudantes de gradua¸c˜ao em pro-jetos de sistemas, aprovados pelo Brazil-IP. Uma vez que ao utilizar uma metodologia de projeto bem definida, em termos de atividades, facilita e acelera o aprendizado de projetos de IP para os estudantes.

3.1.2 Verifica¸

c˜

ao

Segundo Bergeron (BERGERON, 2003), verifica¸c˜ao ´e um processo usado para

demons-trar que o objetivo do projeto é preservado em sua implementa¸cão. Para Mintz e Ekendahl (MINTZ; EKENDAHL, 2007), verifica¸cão funcional é o emprego de software para assegurar que o DUT (Dispositivo sob Teste - Device Under Test ) opera como especificado, antes de ser montado e produzido em escala comercial. Para Spear (SPEAR, 2008), o propósito

de um engenheiro de verifica¸cão é ter a certeza que o dispositivo pode cumprir satisfato-riamente a tarefa, isto é, que o projeto reflete fielmente a especifica¸cão, de forma que a ocorrência de erros (bugs) significa a existência de discrepâncias. Portanto, pode-se con-cluir que o objetivo da verifica¸cão é comprovar se a implementa¸cão seguiu corretamente a especifica¸cão (ipProcess – ver subse¸cão 3.1.1).

A verifica¸cão é importante na redu¸cão dos custos e do tempo de projeto, como também ao assegurar a qualidade do mesmo, visto que o custo de corre¸cão de uma falha do sistema aumenta ao longo do fluxo do projeto - veja Figura 9. Com o aumento crescente da complexidade de projetos de circuitos integrados (basta verificar, na Figura 10, a validade da Lei de Moore (MOORE, 2000) nos circuitos atuais) a verifica¸cão desempenha papel

(33)

importante nesses projetos, despendendo, normalmente, cerca de 70% do esfor¸co total (BERGERON, 2003).

Figura 9: Evolu¸c˜ao do custo em um projeto de CI (BERGERON et al., 2005)

Figura 10: Lei de Moore (PRADO, 2007)

3.1.2.1 Tecnologias de Verifica¸c˜ao

De acordo com Bergeron (BERGERON, 2003) as principais tecnologias de verifica¸c˜ao s˜ao:

Linting – As ferramentas lint realizam análise sintática em busca de erros de pro-grama¸cão comuns, relatando potenciais problemas e práticas questionáveis. Essas ferramentas são limitadas, devido à natureza estática da análise, a qual não verifica o algoritmo ou o fluxo dos dados.

(34)

Simula¸cão – Tenta criar um universo artificial que imite o futuro universo real do projeto, portanto, é uma aproxima¸cão da realidade. O problema desta técnica reside na corretude funcional e precisão do modelo, já que não pode provar que erros não existam. Além disso há o problema do custo computacional e a inviabilidade, para circuitos complexos, de testar todos os padrões de entrada ao longo do tempo.

Diagramas de forma de ondas – Técnica bastante utilizada em conjunto com a si-mula¸cão. Permite a visualiza¸cão de diversas transi¸cões de sinais no tempo, além de suas rela¸cões com outras transi¸cões. É pratica para um conjunto de pouco sinais e transa¸cões, com a crescente complexidade dos projetos, seu uso torna-se desvanta-joso e pass´ıvel de erros.

Cobertura de código – Identifica qual código foi ou não executado na verifica¸cão. Co-leta um conjunto de métricas que objetiva facilitar a análise de verifica¸cão, dentre elas: cobertura de declara¸cões (bloco), cobertura de caminho, cobertura de ex-pressões e cobertura de MEF (Máquina de Estados Finitos).

Verifica¸cão funcional – Assegura que a verifica¸cão estimulou o projeto por uma faixa de valores mais vantajosa, quer dizer, de interesse da equipe de verifica¸cão. Enquanto a cobertura de código avalia o quanto da implementa¸cão foi exercitada, a verifica¸cão funcional examina o quanto da especifica¸cão do projeto original foi exercitado.

O termo testbench se refere ao código de simula¸cão usado para gerar est´ımulos para a verifica¸cão de funcionalidades espec´ıficas do projeto, o que permite criar cenário de verifica¸cão mais realistas (VIJAYARAGHAVAN; RAMANTHAN, 2005). Segundo o mesmo

autor, os testbenches são responsáveis por três tarefas:

1. Gera¸c˜ao de est´ımulos.

2. Mecanismos de auto verifica¸c˜ao.

3. Mensura¸c˜ao da cobertura funcional.

3.1.2.2 BVM

No contexto do Brazil-IP, foi desenvolvida a metodologia de verifica¸cão BVM, a qual é formada pelas melhores práticas da metodologia VeriSC unidas à metodologia OVM (Metodologia de Verifica¸cão Aberta - Open Verification Methodology).

(35)

O VeriSC é uma metodologia de verifica¸cão funcional, desenvolvida usando bibliotecas do SystemC, com o objetivo de reduzir o tempo do processo de verifica¸cão e encontrar erros, tão logo quanto poss´ıvel, nas fases iniciais do fluxo desse processo (SILVA et al., 2006). Ela permite a constru¸cão de um testbench completamente funcional, antes da implementa¸cão do DUV ( Projeto sob Verifica¸cão - Design Under Verification) iniciar. Desta forma, o testbench não precisa ser adaptado ao DUV, uma vez que enquanto este está sendo implementado, aquele já o foi. Além disso, essa metodologia permite o reúso dos elementos que compõem o testbench, para executar um auto-teste e assegurar que o mesmo não contenha erros. Para isso, utiliza-se um mecanismo para simular a presen¸ca do DUV unicamente com os elementos do testbench, sem usar nenhum artif´ıcio extra (MELCHER, 2008).

O OVM é uma metodologia de verifica¸cão funcional, não proprietária, baseada no padrão IEEE 1800 SystemVerilog. Foi criada pelas empresas Mentor Graphics e Cadence (desenvolvedoras de solu¸cões EDA - Automa¸cão de Projetos Eletrônicos - Eletronic Design Automation), com base em metodologias de verifica¸cão originárias das duas corpora¸cões (DOULOS LTDA, 2008), a saber: AVM (Metodologia Verifica¸cão Avan¸cada - Advanced Verification Methodology) e URM (Metodologia de Reúso Universal - Universal Reuse Methodology). Ambas corpora¸cões trabalham juntas para desenvolver o OVM.

A metodologia OVM é sofisticada, sendo capaz de criar testbenches de ponta, asse-gurar interoperabilidade e promover o reúso na verifica¸cão (MENTOR; CADENCE, 2007). Mais especificamente, ela fornece uma biblioteca de classes básicas, servi¸cos úteis e outra facilidades de suporte para concentrar os esfor¸cos na aplica¸cão do SystemVerilog ao pro-blema de verifica¸cão. Para facilitar o reúso de código dos componentes de verifica¸cão e do testbench, a OVM emprega uma arquitetura de verifica¸cão que fornece um consistente conjunto de interfaces bem definidas, através das quais componentes interagem uns com os outros e com o ambiente de verifica¸cão (FITZPATRICK; ANDERSON, 2008). Além disso, a comunica¸cão entre os componentes do testbench ocorre através do padrão de interface TLM (Modelagem em N´ıvel de Transa¸cões - Transaction-Level Modeling), enfatizando o aspecto do reúso de código. TLM é uma técnica de alto n´ıvel para modelar sistemas digitais, na qual os detalhes da comunica¸cão entre os módulos são separados dos detalhes da implementa¸cão das unidades funcionais ou da arquitetura de comunica¸cão. Nesse con-texto, uma transa¸cão é uma opera¸cão que se inicia num determinado momento no tempo e termina em outro. É caracterizada pelo conjunto de instru¸cões e dados necessários para realizar uma opera¸cão (MELCHER, 2008). Exemplos: transmissão de um pacote ethernet, recep¸cão de uma imagem, uma escrita num barramento, entre outros.

(36)

Figura 11: Metodologias BVM e OVM – Fluxo de projeto

Uma das principais mudan¸cas entre BVM e OVM ocorre no fluxo do projeto, conforme Figura 11: no fluxo da OVM a implementa¸cão do RTL ocorre antes da implementa¸cão do testbench; já no fluxo do BVM, originário do VeriSC, essa ordem foi invertida, de forma que a implementa¸cão do testbench é realizada antes da implementa¸cão do RTL. Por outro lado, a BVM utiliza o padrão IEEE 1800 SystemVerilog do OVM, uma vez que o VeriSC é baseado no SystemC.

3.1.2.3 eTBc

A metodologia BVM utiliza uma ferramenta para gerar templates6 _{para o processo de} verifica¸cão, reduzindo o esfor¸co, o tempo do processo de verifica¸cão e a taxa de erros. Essa ferramenta é o eTBc, a qual foi inicialmente criada para a metodologia VeriSC (SILVA et al., 2004), sendo posteriormente adaptada ao SystemVerilog, atual base da metodologia BVM. Tal ferramenta gera todos os templates dos módulos que compõe o testbench, adaptando-os ao DUV - tais módulos são apresentados na Figura 12, exceto o DUV que é o projeto a ser testado em si. Na sequência, são explicadas as funcionalidades de cada módulo, os quais são apresentados com o nomes originais do padrão, sem tradu¸cão.

Reference Model – Modela a funcionalidade do DUV, possuindo o mesmo comporta-mento que esse. Deve ser implementado pelo engenheiro de verifica¸c˜ao em uma

(37)

Figura 12: M´odulos do testbench gerados pelo eTBc.

abstra¸cão diferente do RTL, assim, tende a ser escrita em qualquer linguagem de alto n´ıvel. O n´ıvel RTL deve ser evitado, pois o engenheiro poderia cometer erros que cometeria com o DUV. O modelo de referência é indispensável para a execu¸cão da verifica¸cão.

Source – Envia transa¸c˜oes de entrada para o driver e para o reference model ;

Checker – Compara as transa¸c˜oes de sa´ıda recebidas do monitor com as de um reference model ;

Driver – Recebe transa¸c˜oes de entrada e as converte em transi¸c˜oes de sinais da interface de entrada do DUV;

Monitor – Observa sinais da interface de sa´ıda do DUV e gera transa¸c˜oes de sa´ıda que ele repassa para o checker ; e

Ator – Observa sinais da interface de sa´ıda do DUV e implementa, caso necessário, protocolo de handshake7. Não existe comunica¸cão entre o Ator e o Monitor.

Por produzir somente os templates, boa parte do trabalho ainda deve ser efetu-ada pelo engenheiro de verifica¸cão, como defini¸cões de handshake de sinal, métricas de cobertura e distribui¸cão dos sinais de entrada, dentre outras configura¸cões. Na metodologia BVM, o eTBc auxilia e acelera a produ¸cão do ambiente do testbench, inclusive na fase de teste dos seus componentes, auxiliando na gera¸cão de um am-biente de verifica¸cão livre de erros e já adaptado ao DUV.

(38)

4 Desenvolvimento e Resultados

Esta se¸cão apresenta o desenvolvimento e resultado de cada módulo proposto neste trabalho, como descrito na subse¸cão 1.4. Inicialmente será tratado o desenvolvimento conforme a metodologia ipProcess, no qual serão descritos os principais artefatos gerados pela fase de Requisitos, Análise & Projeto e Verifica¸cão Funcional. Em outra subse¸cão será analisado o processo de verifica¸cão funcional, segundo a metodologia BVM, com o suporte da ferramenta eTBc.

4.1 ipProcess – Requisitos

Os objetivos dos artefatos gerados pela fase de Requisitos s˜ao: definir limites do projeto, fornecer base para melhor entendimento e assegurar que o objetivo do projeto esteja de acordo com as necessidades do cliente ou de quem o solicitou.

4.1.1 Documento de Especifica¸

c˜

ao de Requisitos

O apêndice A apresenta os requisitos levantados para o Controlador Principal (CP) e o Controlador de Memória do Sistema (CMS), descritos no Documento de Especifica¸cão de Requisitos. Tanto a sigla CP, quanto a CMS referem-se aos módulos internos do decodificador, objetos deste trabalho. O principal objetivo deste documento é definir o escopo do IP-Core. Os requisitos são divididos em dois tipos:

• Funcionais – Especifica as a¸c˜oes que o IP-Core deve ser capaz de realizar.

• Não Funcionais – Descreve os atributos do IP-Core e do ambiente no qual o IP-Core está integrado. Esses atributos estão relacionados aos limites do IP-Core, restri¸cões sobre funcionamento (temporiza¸cão, clock, entre outros) e adequa¸cão à lei, interfaces ou padrão de mercado.

Primeiramente são expostos os requisitos do Controlador Principal, se¸cão A.1 do apêndice. Nos requisitos funcionais do CP, destacam-se o papel de gerenciamento dos

(39)

outros módulos, com foco no gerenciamento do CMS, além dos papéis de controle do fluxo de dados entre os módulos e da comunica¸cão com a interface externa. O requisito não funcional expõe restri¸cão referente à temporiza¸cão entre os módulos, já que determinados módulos devem ser alimentados com periodicidade precisa, pois erros de alimenta¸cão dos mesmos corromperiam os dados resultantes da decodifica¸cão.

Quanto ao CMS, boa parte dos requisitos tiveram como base o documento de especi-fica¸cão do padrão de memória DDR SDRAM (JEDEC, 2005). O principal objetivo deste módulo é o gerenciamento da memória do sistema e execu¸cão dos processos de escrita e leitura. O requisito não funcional aborda a restri¸cão da temporiza¸cão nos processos da memória do sistema, conforme a especifica¸cão supracitada.

4.1.2 Documento de Especifica¸

c˜

ao de Casos de Uso

A Figura 13 demonstra o diagrama dos casos de uso do projeto, enquanto o apêndice B descreve os casos de uso relativos ao CP e ao CMS, ou seja, aqueles casos de uso em que tais módulos são atores.

Os casos de uso fornecem modelos das fun¸cões que o sistema deve possuir, além de funcionarem como contrato sobre o projeto com quem solicitou o mesmo, assim, a equipe se assegura que está o desenvolvimento está de acordo com os anseios do “cliente” . Cada caso de uso representa uma unidade funcional coerente provida pelo sistema. O artefato Documento de Especifica¸cão de Casos de Uso descreve o fluxo de eventos de cada caso de uso, fornecendo uma análise minuciosa de cada fun¸cão do sistema, o que permite uma melhor percep¸cão do sistema pelo grupo encarregado do seu desenvolvimento.

A seguir s˜ao listados todos os atores8 _{do sistema, apresentados na Figura 13:}

1. Usu´ario: algum indiv´ıduo ou dispositivo externo ao IP-Core.

2. Controlador de Memória do Sistema (Externo): módulo responsável pelo controle de opera¸cões de leitura na memória externa do sistema, na qual encontra-se o arquivo de áudio MPEG-2 AAC-LC a ser reproduzido (extensão .aac).

3. Mem´oria do Sistema (Externo): dispositivo de armazenamento do arquivo de ´

audio MPEG-2 AAC-LC a ser reproduzido.

8_{Nesse contexto, o ator ´}_{e um humano ou entidade m´}_{aquina que interage com o sistema para executar}

uma unidade funcional, isto é, o ator desempenha um papel que estimula ou solicita a¸cões do sistema e recebe rea¸cões.

(40)

4. Controlador de Memória do Sistema (Interno): módulo responsável pelo controle de opera¸cões de leitura/escrita na memória do sistema. Objetivo deste trabalho.

5. Memória do Sistema (Interno): dispositivo de armazenamento de informa¸cões auxiliares/temporárias do processamento interno do IP-Core, do arquivo de áudio MPEG-2 AAC-LC (transferido da memória externa) e do resultado de processa-mento do IP-Core (amostras estéreo PCM de 16 bits). Objetivo deste trabalho.

6. Controlador Principal: módulo responsável pelo seqüenciamento de a¸cões no IP-Core.

7. Deformatador de Bitstream : módulo responsável pela identifica¸cão e separa¸cão das informa¸cões de bitstream compat´ıvel com o padrão MPEG-2 AAC-LC.

8. Decodificador de Huffman: módulo responsável pela decodifica¸cão de tamanho variável dos fatores de escala e dos dados espectrais quantizados e não-escalados.

9. Dequantizador: módulo responsável pela opera¸cão de quantiza¸cão inversa dos dados espectrais decodificados, quantizados e não-escalados.

10. Reescalador: módulo responsável pela aplica¸cão de fatores de escala aos dados espectrais decodificados, dequantizados e não-escalados, gerando os chamados coe-ficientes espectrais.

11. IMDCT: módulo responsável pela conversão de coeficientes espectrais no dom´ınio de freqüência para amostras PCM no dom´ınio de tempo.

12. Windowing/Block Switching : módulo responsável pela aplica¸cão de fun¸cões de janelamento (escolhidas entre seno e KBD 9 _{) sobre amostras PCM.}

13. Overlapping/Adding : módulo responsável pela sobreposi¸cão parcial (50%) de seqüências de amostras PCM, gerando a configura¸cão final de tais amostras, prontas para reprodu¸cão.

14. Sistema de Reprodu¸cão: sistema externo ao IP-Core, responsável pela reprodu¸cão de áudio digital stereo de 16 bits/canal, a 44.1 kHz.

9_{KBD (Kaiser-Bessel-Derived) ´}_{e uma fun¸}_c˜_{ao de janelamento utilizada para processamento digital de}

sinal. Ela foi projetada para se adequar `a MDCT. Para mais informa¸c˜oes ver (OPPENHEIM; SCHAFER; BUCK, 1999)

(41)

O apêndice B.1, discorre sobre os casos de uso referentes ao CP, o qual, por ser um módulo de controle geral, possui muitos requisitos, uma vez que está envolvido em muitas tarefas no processamento do fluxo de áudio. Os principais casos de uso são os acionamentos dos demais dispositivos, como também o fornecimento das amostras finais, prontas para reprodu¸cão.

A parte B.2 trata sobre o CMS. Os casos de uso abordam as fun¸c˜oes de leitura, escrita e gerenciamento da mem´oria (dispositivo f´ısico).

(42)

(43)

4.2 ipProcess – An´

alise & Projeto

A fase de Análise & Projeto objetiva transformar as informa¸cões levantadas na fase de Requisitos em um projeto de IP-Core - para isso cria-se um esbo¸co da arquitetura e define-se aspectos como ambiente de implementa¸cão, padrões de projeto entre outros.

Entre os artefatos mais importantes est˜ao o Documento de An´alise e o Documento de Arquitetura.

4.2.1 Documento de An´

alise

O Documento de Análise descreve realiza¸cões de casos de uso, com suas intera¸cões e modelos de análises. Ele caracteriza cada fluxo de caso de uso em um modelo final de classes. Assim, distribui comportamento, atributos, associa¸cões e responsabilidades para esses elementos. É um documento extenso com os modelos das classes, os quais foram criados para realiza¸cão dos casos de uso.

A figura 14 apresenta o diagrama geral, o qual é uma compila¸cão dos diagramas gerados para os casos de uso. Seu exame permite entender o fluxo dos dados entre os módulos e a sequência lógica de decodifica¸cão de uma unidade de áudio do AAC.

(44)

(45)

4.2.2 Documento de Arquitetura

O Documento de Arquitetura unifica e descreve todas as visões da arquitetura: casos de uso, lógica, implementa¸cão e processos. Essas visões são resultado dos documentos prévios. Uma arquitetura a ser proposta é baseada no Documento de Análise e na ex-periência de desenvolvimento de IP-Cores.

Na arquitetura, conforme a Figura 15, as classes do sistema são organizadas em três camadas: Comunica¸cão, Controle e Dados, as quais são descritas na sequência.

Comunica¸cão – A camada de comunica¸cão contém as classes responsáveis pela comu-nica¸cão entre o sistema e o reprodutor de áudio digital (PCM), assim como entre o sistema e seu dispositivo de memória de apoio. O processo de comunica¸cão se inicia com a solicita¸cão do usuário, a qual faz o Controlador Principal acessar a memória do sistema a partir de um dado endere¸co (definido pela interface do usuário, ex-terna ao IP-Core). Após o carregamento do arquivo .aac na memória do sistema, o Controlador Principal aciona os módulos internos do sistema, para obter o resul-tado da decodifica¸cão do arquivo .aac. As unidades de acesso de áudio (frames) são decodificadas, gerando amostras PCM, as quais são temporariamente armazenadas na memória do sistema, para disponibiliza¸cão ao sistema externo de reprodu¸cão, à taxa de 44.100 amostras PCM de 16 bits, por canal de áudio (o sistema decodifica até 2 canais de áudio).

Controle – A camada de controle contém as classes responsáveis pelo controle de todas as a¸cões desempenhadas pelo Decodificador MPEG-2 AAC-LC.

Dados – A camada de dados contém as classes que armazenam os dados necessários para a realiza¸cão das a¸cões do Decodificador MPEG-2 AAC-LC.

As Figuras 16, 17 e 18 representam, respectivamente, as classes do sistema para os casos de uso Acionar, Disponibilizar Amostras e Executar Opera¸cão. As classes expostas nessas figuras compõem, juntamente com outras, o diagrama de arquitetura (15) . As duas primeiras pertencentes ao CP e a última ao CMS.

(46)

(47)

(48)

Figura 17: Diagrama de arquitetura – Disponibilizar Amostras

(49)

4.3 ipProcess – Verifica¸

c˜

ao

O maior propósito da fase de verifica¸cão é assegurar que o projeto em RTL imple-menta as funcionalidades planejadas. Portanto, ela procura defeitos e, ao encontrá-los, os documenta. Essa fase gera dois principais artefatos, o Plano de Verifica¸cão e o Documento de Casos de Teste.

4.3.1 Plano de Verifica¸

c˜

ao

O Plano de Verifica¸cão reúne informa¸cões necessárias para um bom planejamento e controle do esfor¸co gasto com a verifica¸cão de um IP-Core. Ele descreve a abordagem usada para verificar os módulos, sendo o plano de mais alto n´ıvel gerado e usado pelos gerentes para direcionar o esfor¸co da verifica¸cão.

4.3.2 Documento de Casos de Teste

O Documento de Casos de Teste define e especifica os casos de teste que serão utili-zados na verifica¸cão funcional. Para isso, devem ser analisados os fluxos de trabalho dos casos de uso, tanto os principais como secundários, a fim de escolher os fluxos que serão testados e definir as entradas, as sa´ıdas, os procedimento da verifica¸cão, as condi¸cões, as pré-condi¸cões e as pós-condi¸cões. Além disso, ele aborda os critérios de cobertura, tanto a cobertura funcional, como a cobertura de código.

Os casos de testes s˜ao divididos pelo tipo de est´ımulo que geram, dentre os quais figuram:

Teste Direcionado (Compliance Testing) - Verifica situa¸c˜oes mencionadas na espe-cifica¸c˜ao.

Caso Extremo (Corner Case) - Verifica situa¸c˜oes cr´ıticas (extremas) do projeto.

Código Real (Real Code) - Utiliza est´ımulos reais da aplica¸cão. Como exemplo, para o decodificador de áudio um fragmento de um arquivo de áudio aac contem est´ımulos reais.

Aleatório (Random) - Cria situa¸cões “inusitadas”. Cobertura tipicamente melhor do que os outros tipos, já que pode gerar cenários que seriam esquecidos.

(50)

O Documento de Casos de Teste agrupa casos de teste que geram os seguintes est´ımulos: Teste de Direcionados, Casos Extremos e Aleat´orios.

4.3.2.1 Controlador Principal

A Tabela 4 evidencia a quantidade de tarefas executadas pelo CP - cada tarefa deve ser testada, levando em considera¸cão a sincroniza¸cão dos diversos módulos. O caso de teste apresentado nessa tabela é um teste direcionado, de acordo com a especifica¸cão (docu-mentos ipProcess - Apêndices Ae B) levantada previamente. A análise minuciosa do fluxo do teste, permite compreender todo o processamento, quer dizer, toda a decodifica¸cão de uma unidade de áudio, na perspectiva de controle.

Tabela 4: Caso de Teste Direcionado relacionado ao Con-trolador Principal

Nome: [CA 002] Teste de Acionar

Descri¸cão: O objetivo desse caso de teste é testar o fluxo principal dos casos de uso [UC 001], [UC 003], [UC 004], [UC 006], [UC 008], [UC 010], [UC 012], [UC 014], [UC 017] e [UC 018]. Para isso, streams de audio aac válidos são gerados como est´ımulos para verificar se o Controlador Principal apresenta os resultados esperados.

Casos de uso relacionados: [UC 001] Acionar Deformatador [UC 003] Acionar Huffman

[UC 004] Decodificar Fatores de Escala [UC 006] Acionar Dequantizador [UC 008] Acionar Reescalador [UC 010] Acionar IMDCT [UC 012] Acionar Janelamento [UC 014] Acionar Sobreposi¸c˜ao

[UC 016] Disponibilizar Amostras PCM [UC 017] Ler

[UC 018] Escrever

(51)

continua¸cão da página anterior Pré-condi¸cões:

• Stream armazenado e buffer de entrada do De-formatador sendo realimentado.

• Streams enviados devem ser streams aac v´alidos.

P´os-condi¸c˜oes:

• Posi¸cões da memória do sistema, corresponden-tes às amostras PCM reproduzidas, liberadas.

Procedimento de teste:

• O Controlador Principal envia parte do arquivo .aac para o buffer de entrada do Deformatador de Bits-tream.

• O Controlador Principal envia um sinal de ativa¸c˜ao de deformata¸c˜ao.

• O Deformatador de Bitstream identifica o sinal envi-ado e lê o buffer de entrada serialmente, até identificar um elemento sintático AAC válido.

• O Controlador Principal rep˜oe os bits consumidos pelo Deformatador de Bitstream, de acordo com a taxa de bits identificada.

• Ao encontrar o identificador correspondente ao fim da unidade de acesso de áudio (frame de áudio), o Deformatador informa o final da deformata¸cão de tal unidade ao Controlador Principal.

• O Decodificador de Huffman sinaliza o final da de-codifica¸cão dos coeficientes espectrais da unidade de acesso de áudio atual ao Controlador Principal. • O Controlador Principal envia um sinal de ativa¸cão para iniciar o processo de dequantiza¸cão de coeficien-tes espectrais quantizados e não-escalados.

(52)

continua¸c˜ao da p´agina anterior

• O Dequantizador recebe o sinal de ativa¸c˜ao e prepara-se para o processo de dequantiza¸c˜ao.

• O Controlador Principal repassa coeficientes espec-trais quantizados e não-escalados para o Dequantiza-dor. Repetindo o processo enquanto houver coeficien-tes espectrais quantizados e não-escalados na unidade de acesso de áudio.

• O Controlador Principal desabilita o sinal de ativa¸c˜ao.

• O Dequantizador envia coeficientes dequantizados e n˜ao-escalados para o Controlador Principal.

• O Controlador Principal envia um sinal de ativa¸c˜ao para iniciar o processo de aplica¸c˜ao de fatores de es-cala aos coeficientes espectrais dequantizados e n˜ ao-escalados.

• O Reescalador recebe o sinal de ativa¸c˜ao e prepara-se para o processo de reescalamento.

• O Controlador Principal repassa informa¸c˜oes de se-cionamento e de janelamento ao Reescalador.

• O Controlador Principal repassa um fator de escala e os correspondentes coeficientes espectrais dequanti-zados e n˜ao-escalados para o Reescalador. Repetindo o processo enquanto houver coeficientes espectrais de-quantizados e n˜ao-escalados na unidade de acesso de ´

audio.

• O Reescalador envia os coeficientes dequantizados e n˜ao-escalados para o Controlador Principal.

• O Controlador Principal envia um sinal de ativa¸cão para iniciar o processo de restaura¸cão de amostras PCM a partir dos coeficientes espectrais de uma ja-nela de áudio.

(53)

• A IMDCT recebe o sinal de ativa¸c˜ao e prepara-se para o processo restaura¸c˜ao de amostras.

• O Controlador Principal repassa grupos de coefici-entes espectrais `a IMDCT. Repetindo o processo en-quanto n˜ao forem repassados 1024 coeficientes espec-trais (correspondentes a uma janela longa ou a 8 jane-las curtas).

• A IMDCT envia valores das amostras PCM para o Controlador Principal.

• O Controlador Principal envia um sinal de ativa¸c˜ao para iniciar o processo de janelamento de amostras PCM.

• O Windowing/Block Switching recebe o sinal de ativa¸c˜ao e prepara-se para o processo de dequan-tiza¸c˜ao.

• O Controlador Principal repassa informa¸cões sobre o tipo de fun¸cão de janelamento a ser aplicada (seno ou KBD) e o tipo de seqüência de janelas para o Win-dowing/Block Switching.

• O Controlador Principal repassa grupos de amostras PCM para o Windowing/Block Switching. Repetindo o processo enquanto n˜ao forem repassadas 2048 amos-tras PCM (correspondentes a uma janela longa ou a 8 janelas curtas).

• Controlador Principal recebe valores das 2048 amos-tras PCM após a aplica¸cão da fun¸cão de janelamento. • O Controlador Principal envia um sinal de ativa¸cão para iniciar o processo de sobreposi¸cão de amostras relativas as janelas adjacentes.

(54)

• O Overlapping/Adding recebe o sinal de ativa¸c˜ao e prepara-se para o processo de sobreposi¸c˜ao.

• O Controlador Principal repassa dois grupos de amostras PCM janeladas, cada qual associado a uma das duas seqüências de janelas, para o Overlap-ping/Adding. Repetindo o processo enquanto não fo-rem repassadas 2048 amostras PCM janeladas (corres-pondentes a 50% de cada uma das duas seqüências de janelas consideradas).

• O Controlador Principal aguarda até que uma uni-dade de acesso de áudio seja inteiramente decodifi-cada, isto é, até que se obtenha os valores finais das amostras PCM para ambos os canais de áudio es-querdo (primeiro a ser decodificado) e direito (último a ser decodificado).

• O Controlador Principal envia simultaneamente duas amostras PCM de 16 bits, cada qual relacionada a um canal, de acordo com a temporiza¸cão necessária para a reprodu¸cão a 44.100 amostras/s por canal. • Repetir o procedimento acima para outros streams válidos.

4.3.2.2 Controlador de Mem´oria

O caso de teste do CMS, conforme Tabela 5, possui est´ımulos aleatórios. Nele são ve-rificadas todas as tarefas de gerenciamento e as opera¸cões de leitura e escrita na memória. A aleatoriedade na verifica¸cão permite maior seguran¸ca, pois permite que uma quantidade maior de cenários sejam verificados.