Descrição VHDL da arquitetura do upsampling

A descrição da arquitetura do upsampling está distribuída em total de 14 arquivos VHDL, conforme representado na Figura 4.32. Cerca de 2.300 linhas de código VHDL foram escritas para descrever o método de upsampling. A Figura 4.32 apresenta, de maneira simplificada, a estrutura de arquivos VHDL utilizada na implementação em hardware da arquitetura do upsampling. Como pode ser percebido, o arquivo VHDL topo é chamado UpsamplingCompleto.vhd, o qual instancia os filtros de crominância e luminância desenvolvidos (UpsamplingHVLuma.vhd e UpsamplingHVCroma), destacando que o uso de “HV” na nomenclatura desses arquivos diz respeito à filtragem vertical e horizontal utilizada em cada um deles. Analisando a Figura 4.32, pode-se notar, ainda, que existem arquivos que são compartilhados pelos filtros de luminância e crominância e, além disso, cada um desses filtros possui três arquivos independentes: uma para descrever as operações realizadas em seu núcleo (FilterLuma.vhd e

FilterCroma.vhd); um que realiza o controle interno (ControleLuma.vhd e ControleCroma.vhd) e um responsável pelas operações de clipping aplicadas na saída

da filtragem vertical (ClipLuma.vhd e ClipCroma.vhd).

Figura 4.32: Estrutura de arquivos VHDL utilizada na implementação em hardware do

upsampling.

A seguir serão apresentadas as entidades dos principais módulos VHDL que compõem a arquitetura desenvolvida para o método de upsampling.

Como o módulo UpsamplingCompleto.vhd somente instancia e realiza a comunicação entre os módulos UpsamplingHVLuma.vhd e UpsamplingHVCroma.vhd, sua entidade não está apresentada nesta seção do texto. No entanto, a descrição completa da sua entidade está apresentada no Apêndice B desta dissertação.

77

A Figura 4.33 apresenta a entidade do módulo UpsamplingHVLuma.vhd, responsável pela filtragem vertical e horizontal dos componentes de luminância. Esta entidade é composta pelos seguintes sinais de entrada: clk; inicio, o qual dispara o processo de filtragem; reset_filtro, que reseta o filtro de luminância para iniciar uma nova filtragem; dado_esc_memIN, que corresponde ao dado escrito na memória de entrada; we_mem_in, que habilita a escrita na memória de entrada; incr_rst_mems, representa o agrupamento de oito sinais de reset e incremento dos endereços das memórias memIN, memH1 e memH2; sel_incr_rst_mems que agrupa oito sinais que selecionam se os endereços das memórias serão resetados ou incrementados pelo controle. As saídas dessa entidade são as seguintes: quadro_out, que indica que existe um quadro pronto (filtrado) na saída da arquitetura de luminância; e saida1 e saida2, que correspondem as saídas dos filtros de índice 4 e 12 de luminância, respectivamente.

Figura 4.33: Entidade do módulo UpsamplingHVLuma.vhd.

O módulo UpsamplingHVCroma.vhd é responsável pela filtragem vertical e horizontal dos componentes de crominância e sua entidade possui sinais com os mesmos nomes dos sinais de entrada e saída que a entidade do módulo

UpsamplingHVLuma.vhd e, por isso, não será ilustrada. No entanto, os sinais de entrada

dessa entidade correspondem aos componentes de crominância e as saídas (saida1 e

saida2) correspondem às saídas dos filtros de índice 4 e 12 de crominância,

apresentados na subseção 4.2.2.2, desse capítulo. Mais detalhes sobre essa entidade podem ser encontrados no Apêndice B, dessa dissertação.

Na Figura 4.34 está apresentada a entidade do módulo FilterLuma.vhd. Este módulo é responsável por aplicar os filtros de luminância de índice 4 e 12, definidos através das equações apresentadas na subseção 4.2.2.1 deste capítulo. Os sinais de entrada dessa entidade são: clk; reset (rst); carga, que é responsável por indicar quando um novo valor de entrada pode ser carregado nos registradores e por deslocar os valores de entrada de um registrador para outro até que os quatro estejam preenchidos com valores válidos (lembrando que são quatro registradores, pois as operações de filtragem de luminância necessitam de quatro entradas (A, B, C e D) para serem realizadas); e o sinal entrada, que corresponde aos valores que serão filtrados.

As saídas dessa entidade são as saídas dos filtros de luminância de índice 4 e 12, representadas na Figura 4.34, por s4 e s12, que correspondem às saídas saida1 e saida2 da arquitetura completa de luminância (UpsamplingHVLuma.vhd) apresentada na Figura 4.33.

78

Figura 4.34: Entidade do módulo FilterLuma.vhd.

A entidade do módulo FilterCroma.vhd é bastante semelhante à entidade do

FilterLuma.vhd, o que muda são as operações de filtragem realizadas pelos filtros de

índice 4 e 12, sendo que essas operações de filtragem necessitam de duas entradas (A e B), ao invés de quatro, e as saídas s4 e s12, do módulo FilterCroma.vhd, correspondem às saídas: saida1 e saída2 do módulo UpsamplingHVCroma.vhd.

As entidades descritas acima são as entidades dos principais módulos que compõem a arquitetura do upsampling. Os demais módulos, não menos importantes, porém mais simples, descrevem registradores (reg.vhd, reg_incr.vhd, reg_incr_linha.vhd), multiplexadores (mux21.vhd), módulos de clipping (ClipLuma.vhd, ClipCroma.vhd), memórias (memória.vhd) (que é instanciada para a criação das memórias memIN, memH1 e memH2 das arquiteturas de luminância e crominância, apresentadas na Figura 4.28) e os módulos de controle ControleLuma.vhd e ControleCroma.vhd, os quais são responsáveis por controlar a escrita e a leitura das memórias, e por assegurar que as filtragens sejam realizadas corretamente. Essas entidades não foram ilustradas, porém sua descrição VHDL detalhada está apresentada no Apêndice B, juntamente com as entidades dos demais módulos desenvolvidos nesta dissertação.

A seguir, o capítulo cinco irá apresentar a validação das arquiteturas de hardware desenvolvidas, as quais foram descritas em detalhes no decorrer do corrente capítulo.

5 _{VALIDAÇÃO DAS ARQUITETURAS}

IMPLEMENTADAS

Este capítulo descreve como foi realizada a validação das arquiteturas desenvolvidas nesta dissertação, incluindo a obtenção dos casos de teste, a escrita do test bench e a simulação do VHDL descrito.

A primeira etapa de validação dos blocos desenvolvidos foi a definição de um modelo de referência (golden model). Para todas as arquiteturas desenvolvidas, o golden

model escolhido foi o próprio software de referência do padrão H.264/SVC, chamado

de JSVM (Joint Scalable Video Model), em sua versão 9.12.2 (JSVM, 2008). Foram inseridas funções no código fonte do software de referência para extração dos valores de entrada e saída de cada um dos módulos desenvolvidos neste trabalho. Os arquivos do software de referência onde foram inseridas as rotinas para extração de dados foram: (1)

SliceDecoder.cpp – para extrair os dados para a validação do compensador de

movimento escalável; (2) Loopfilter.cpp – para capturar os dados para a validação do filtro redutor de efeito de bloco e (3) o método xBasicIntraUpsampling do arquivo

Downconvert.cpp – para extrair os dados usados na validação do upsampling. Então

dados de vídeos reais foram usados como entrada para o software de referência e os valores extraídos foram salvos em arquivos texto. Os valores de entrada extraídos foram usados como estímulos para as arquiteturas desenvolvidas e os valores de saída foram comparados com as saídas destas arquiteturas para verificar se os resultados gerados estavam corretos.

A etapa seguinte de validação dos blocos desenvolvidos foi a análise das formas de onda diretamente no software de síntese ISE da Xilinx (XILINX, 2009). Esta análise foi realizada apenas para verificar o correto funcionamento de módulos mais simples que compunham as arquiteturas desenvolvidas. Após esta validação inicial, foi possível prosseguir o desenvolvimento arquitetural, integrando novos módulos que, posteriormente, foram validados de forma mais completa através de comparações entre resultados gerados pela arquitetura em relação aos resultados do golden model.

Para realizar as simulações mais completas foi escolhido o software ModelSim da

Mentor Graphics (MENTOR,2008), em sua versão “ModelSim SE 6.1c”. Este software

oferece grande facilidade em detecção de problemas nos módulos avaliados, uma vez que permite a visualização do comportamento de todos os sinais internos à arquitetura através de formas de onda. Além disso, utilizando ModelSim, pode-se realizar simulações não apenas comportamentais, mas também simulações da arquitetura já mapeada em diversas famílias de FPGA. Neste caso, o FPGA utilizado para simulação foi o XC4VLX200 da família Virtex 4 da Xilinx (XILINX, 2009).

Para utilizar os dados capturados do golden model nas simulações no ModelSim, foi escrito um test bench. Além de inserir os estímulos de entrada na arquitetura que está

80

sendo testada, o test bench foi escrito para capturar os resultados de saída das arquiteturas. Os resultados são, então, salvos em arquivos texto. Somente após esses processos de busca, conversão de dados e descrição do test bench foi possível executar as simulações que validariam as arquiteturas desenvolvidas.

Os resultados das simulações coincidiram com os dados gerados pelo software de referência para todos os casos de teste e, deste modo, as arquiteturas implementadas foram consideradas validadas.

5.1 Validação da Arquitetura para a Predição de Movimento entre