Esta Seção mostra resultados relativos ao desempenho da implementação proposta, em quesitos de elementos lógicos, frequência e velocidade de operação estimadas. Os resultados serão apresentados em função da resolução dos vídeos, que tem impacto direto nos recursos usados.
4.2.1 ELEMENTOS LÓGICOS
Primeiramente, serão mostrados resultados individuais para os nove blocos em que o código foi dividido, em número de recursos lógicos. A Tabela 11 apresenta resultados refe- rentes aos blocos mais simples: counter, lines_buffer, ABZh, ABZv, TI, MAD e accum, para as resoluções 320×240 e 768×432. Os blocos entre ABZh e accum incluem o bloco counter, necessário para sua correta sintetização.
Tabela 11: Número de elementos lógicos em função da resolução para os blocos simples.
Resolução counter lines_buffer ABZh ABZv TI MAD accum
320×240 22 30 96 94 73 44 553
768×432 19 32 91 91 78 42 535
O bloco responsável por armazenar um quadro inteiro é o mais dispendioso em recur- sos lógicos em toda a implementação, e também o limitador da frequência e resolução máximas de operação. Por isso, ele foi sintetizado apenas para resoluções menores, pois a compilação se torna inviável para vídeos maiores (levando dias para compilar ou não chegando a compilar). Também é mostrado a porcentagem de recursos da FPGA que são ocupados. Os resultados são
exibidos na Tabela 12. O outro bloco que usa grande quantidade de recursos é o bloco combina- cional combinational, responsável por calcular várias médias. No entanto, esse bloco não varia de acordo com a resolução, consumindo um valor fixo de recursos em todos os casos, 8243.
Tabela 12: Número de elementos lógicos em função da resolução para o bloco frame_buffer.
Resolução ELs ELs (%)
10×10 1422 1,23 50×50 28813 25,37 70×70 55785 49,20 100×100 112709 99,25 150×150 221892 195,40 200×200 396011 348,72 250×250 618815 544,92
Para complementar a Tabela 12, o gráfico da Figura 15 mostra a porcentagem de ele- mentos lógicos, do total do projeto, que é ocupada apenas pelo bloco frame_buffer, em função da resolução. Percebe-se que o crescimento é muito rápido, com tendência a ocupar a grande maioria dos recursos lógicos do circuito em resoluções elevadas.
0% 10% 20% 30% 40% 50% 60% 70% 80% 0 500 1000 1500 2000 2500 3000 3500 4000 El em en tos lógi cos Pixels Frame buffer
Figura 15: Porcentagem de elementos lógicos, no projeto completo compilado, que é ocupada pelo bloco frame_buffer, em função da resolução.
Fonte: Autoria própria.
Por fim, na Tabela 13 são mostrados os resultados para o circuito inteiro compilado, além da porcentagem de recursos utilizados da FPGA. A sintetização do projeto completo é
limitada pelo bloco mais custoso, neste caso, frame_buffer. Portanto, as resoluções em que o circuito inteiro foi compilado também são menores.
Tabela 13: Número de elementos lógicos em função da resolução para o projeto completo.
Resolução ELs ELs (%)
10x10 16750 14,75 20x20 20155 17,75 30x30 25624 22,56 40x40 33360 29,38 50x50 43483 38,29 60x60 55910 49,23 64x64 61234 53,92 75x75 78693 69,30
Percebe-se que o número de elementos lógicos é bastante elevado, mesmo nas resolu- ções baixas em que o projeto foi compilado. Isso, como visto na Tabela 12 e na Figura 15, é devido ao buffer de um quadro completo necessário para as características espaciais.
4.2.2 FREQUÊNCIA
Como neste trabalho não foi possível testar o algoritmo em uma FPGA, foi estimado o tempo necessário para o cálculo ser executado em um hardware, utilizando a ferramenta TimeQuest Timing Analizer do Quartus Prime. Essa ferramenta determina, após a análise e síntese do circuito, a frequência máxima que ele seria executado em determinadas condições de temperatura. Assim como na Seção anterior, os resultados serão divididos. Na Tabela 14 são apresentados os resultados referentes aos blocos simples. Nenhum dos blocos simples é um limitador, com todos atuando acima de 200 MHz.
Tabela 14: Frequência de operação em função da resolução para os blocos simples, em MHz.
Resolução counter lines_buffer ABZh ABZv TI MAD accum 320×240 352,49 271,96 204,67 212,54 246,00 277,93 271,15 768×432 380,23 264,69 214,41 215,05 232,99 316,06 266,38
Na Tabela 15 são exibidos os resultados para o bloco frame_buffer. Por ser um bloco combinacional, não há resultados de frequência para o bloco nrvqa. Por fim, a Tabela 16 mostra as frequências para o código completo sintetizado.
Tabela 15: Frequência de operação em função da resolução para o bloco frame_buffer. Resolução Fmax (MHz) 10x10 41,2 20x20 36,75 30x30 30,7 40x40 33,15 50x50 32,01 60x60 32,97 70x70 21,44 100x100 31,84
Tabela 16: Frequência de operação em função da resolução para o projeto completo.
Resolução Fmax (MHz) 10x10 3,36 20x20 3,37 30x30 3,39 40x40 3,35 50x50 3,4 60x60 3,29 64x64 3,59 75x75 3,39
Pode-se observar na Tabela 15 que, assim como nos blocos lógicos, o bloco frame_- buffer também gargala o projeto, com frequências bem abaixo das apresentadas para os demais blocos na Tabela 14. As frequências apresentadas na Tabela 16, como será visto na próxima Subseção, são suficientes para analisar os vídeos em tempo real.
4.2.3 TEMPO DE CÁLCULO
Por meio de um processo de contagem de clocks, foi medido o número de ciclos neces- sários para extrair as características e calcular o escore NRVQA-LM para diversas resoluções. A Tabela 17 sintetiza essas medidas.
Tabela 17: Ciclos de clock no cálculo do método NRVQA-LM.
Número de quadros Resolução Ciclos de clock
3 8×3 145 3 24×16 1.153 3 90×70 18.901 3 200×100 60.001 3 352×288 304.129 250 768×432 82.944.001
Observa-se que, nos casos da Tabela 17, a partir do segundo teste, o número de ciclos equivale ao número de pixels do vídeo, mais 1. Por exemplo, 3 × 90 × 70 = 18900, ou 250 × 768 × 432 = 82944000. Isso implica que os cálculos são feitos virtualmente à mesma taxa em que os pixels são recebidos, o que pode ser creditado à característica de processamento paralelo das FPGAs. Portanto, em um cenário de avaliação de um vídeo sendo recebido de alguma fonte, como entrada HDMI a partir de set-top box, a avaliação pode ser executada em tempo real.
A partir desses números de ciclos de clock e das frequências de operação mostradas anteriormente, pode-se estimar o tempo de cálculo em FPGA e compara-se com os necessá- rios para extrair as características no código original em MATLAB. A Tabela 18 apresenta o tempo dispendido para calcular o escore NRVQA-LM para vídeos de 217, 250 e 500 quadros, resolução 64×64 em máquinas de duas configurações diferentes:
• PC 1: Processador Intel Core 2 Quad Q6600 2,4 GHz (4 núcleos), 3,25 GB de Memória RAM DDR2 800 MHz;
• PC 2: 2x Processadores Intel Xeon E5-2650 2 GHz (2×8 núcleos, 2×16 threads), 128 GB de memória RAM DDR3 1600 MHz.
Tabela 18: Tempo de cálculo do método NRVQA-LM no MATLAB para vídeos 64×64.
Tempo (segundos) Quadros PC 1 PC 2 217 11,0165 6,6853 250 12,2949 7,8010 500 23,0311 14,1431
Para se fazer a comparação, não foram utilizados os quadros completos dos vídeos, pois não foi possível sintetizar o código na mesma resolução. Portanto, calculou-se o escore de qualidade no MATLAB utilizando a resolução 64×64, que foi a mais alta (múltipla de 8,
requisito do código original) em que o código completo foi sintetizado. A Tabela 19 mostra a diferença de velocidade entre as duas implementações.
Tabela 19: Comparação de velocidade entre as implementações em hardware (ponto fixo) e em software.
Quadros Tempo VHDL (s) Aumento de velocidade PC1 Aumento de velocidade PC2
217 0,2476 44× 27×
250 0,2852 43× 27×
500 0,5705 40× 25×
Pode-se perceber, portanto, que a implementação em VHDL proposta melhora em até 44 vezes a velocidade da obtenção do escore de qualidade NRVQA-LM. Mesmo em compa- ração com uma máquina de alto custo e desempenho, como o PC 2, ainda assim há um ganho significativo de mais de 20 vezes. No caso hipotético de um vídeo de 64×64 quadros, a ava- liação pode ser realizada em tempo real, uma vez que os tempos de cálculo são menores que o tempo de duração dos vídeos (dez segundos, exceto o vídeo bs). Ressalta-se, porém, que uma implementação em MATLAB não é o melhor parâmetro de comparação, por se tratar de uma linguagem interpretada. Independente de comparações, a implementação em hardware mostrou-se capaz de processar os vídeos em tempo real, o que é o desejado.