\chapter{Resultados}
    \label{chap:resultados}
    \epigraph{``Testes demonstram somente a \emph{presença} de erros em um programa, jamais sua ausência.''}
    {Edsger Wybe Dijkstra}

    \sigla{LUT}{Look-Up Table}

    O escalonador escrito em C++ foi sintetizado com várias combinações de diretivas e
    otimizações, buscando demonstrar uma importante vantagem da síntese de alto nível: a possibilidade
    de se obter várias microarquiteturas a partir de uma única descrição comportamental. A verificação
    funcional dos circuitos gerados foi feita com a execução de um testbench VHDL sobre os mesmos.

    Nas próximas seções detalhamos o testbench de verificação e todos os cenários de síntese.
    São também exibidas e analisadas as métricas resultantes da síntese (tanto pré como pós-RTL).
    A avaliação de nossa implementação é feita em comparação com uma implementação de referência
    do escalonador em nível RT.

    Em todos os cenários, o dispositivo-alvo para a síntese pós-RTL foi um FPGA da família
    Virtex6\textregistered , fabricado pela Xilinx\textregistered , conforme já detalhado na
    seção \ref{par:soc-validacao:fpga}.

    \section{Resultados da verificação funcional}
        \label{sec:verificacao-funcional}
        Todos os cenários de síntese escolhidos geram um bloco de hardware com a mesma interface e
        mesmo comportamento esperado. Assim, a execução de um único testbench sobre todos os
        blocos resultantes é suficiente para verificar sua corretude e equivalência.

        O testbench desenvolvido executa uma séria de operações em sequência. A sequência de
        operações realizadas, com as respectivas entradas fornecidas e saídas esperadas,
        está detalhada na tabela \ref{tab:scheduler-testbench}
        \input{tabelas/scheduler-testbench.tex}

        O código VHDL completo do testbench encontra-se no apêndice \ref{ap:escalonador:testbench}

    \section{Cenários de síntese}
        \label{sec:cenarios-sintese}
        Em geral, a escolha dos cenários de síntese para nossa proposta foi guiada pelo interesse
        em avaliar microarquiteturas que se situassem em extremos opostos do espectro de
        área/latência, ou seja, optamos por realizar a síntese de microarquiteturas que tivessem
        grande área e baixa latência e vice-versa. Uma descrição mais detalhada de cada um
        dos cenários de síntese segue:
        \begin{description}
            \item[Cenário 1] Neste cenário os arrays usados para armazenar os elementos da
                fila de escalonamento foram todos mapeados para memórias (RAMs) dedicadas no
                FPGA. Nenhuma paralelização de loops foi realizada. O script com as diretivas
                do cenário 1 constam do apêndice \ref{ap:diretivas1}
            \item[Cenário 2] Propositadamente, neste cenário de execução não houve qualquer
                intervenção do projetista no processo. Todas as diretivas de síntese foram
                mantidas em seus valores \emph{default}, visando avaliar uma espécie de caso
                ``otimista'', em que a ferramenta de síntese tem independência total para inferir
                a microarquitetura do bloco sendo sintetizado. Neste cenário os arrays acabaram
                sendo mapeados para registradores e os loops também foram mantidos intactos (sem
                nenhuma paralelização). As diretivas de síntese para este cenário estão no
                apêndice \ref{ap:diretivas2}
            \item[Cenário 3] Cenário com paralelismo total. Todos os loops foram paralelizados,
                o que diminuiu drasticamente o número de ciclos necessários (no pior caso) para
                realizar uma operação do escalonador. Naturalmente, tal paralelização acarretou
                um aumento correspondente na área consumida e também no atraso máximo do bloco.
                As diretivas do cenário 3 estão no apêndice \ref{ap:diretivas3}
        \end{description}

        É importante ainda citar que em todos os cenários a síntese pós-RTL foi realizada
        objetivando-se uma frequência de clock de 50 MHz, portanto o limite máximo de atraso
        era de 20 ns. Caso algum cenário tivesse uma atraso que ultrapassasse tal limite, sua
        implementação seria inviável.

        Algumas das mais importantes diretivas de síntese, comuns a todos os cenários, merecem comentários:
        \begin{description}
            \item[START\_FLAG e DONE\_FLAG] incluem no bloco um sinal de entrada que indica que todas
                as entradas já foram fornecidas e a computação pode começar, bem como um sinal de
                saída, o qual quando ativado pelo bloco significa que suas saídas estão estáveis.
                Tais sinais facilitam bastante o processo de verificação funcional.

            \item[CLOCKS] Essa diretiva especifica todos os parâmetros relativos ao clock do sistema,
                incluindo período, \emph{duty cycle} e tolerância. Além disso essa diretivas também define
                o tipo (síncrono/assíncrono) e a polaridade do sinal de reset.

            \item[TECHLIBS] Através dessa diretiva é especificada a \emph{biblioteca} de componentes
                a ser usada no design. As informações de atraso e área dependentes de tecnologia
                são importantes na determinação de um escalonamento adequado para o design. Existem
                bibliotecas para os mais diversos modelos de FPGAs, de vários fabricantes.

            \item[DESIGN\_GOAL] Essa diretiva tem dois valores possíveis: \emph{área} ou
                \emph{latency}, e define a principal grandeza a ser minimizada pelos algoritmos de
                otimização nas várias fases da síntese.
        \end{description}

    \section{Resultados de síntese}
        \label{sec:resultados-sintese}
        Dados de cada um dos três cenários definidos foram coletados em duas etapas do fluxo
        de projeto. A primeira delas, pré-RTL, corresponde ao resultado da síntese de alto
        nível, um arquivo VHDL que contém a descrição do bloco em nível de transferência de
        registradores. Já a segunda etapa, pós-RTL, corresponde ao resultado do mapeamento
        do modelo RTL para os blocos funcionais dispositivo FPGA utilizado. A tabela
        \ref{tab:results-pre-rtl} mostra os resultados na etapa pré-RTL.
        \input{tabelas/results-pre-rtl-synth.tex}

        A coluna ``Área ocupada'' se refere à pontuação de área dada pela ferramenta de síntese,
        sendo que tal pontuação leva em conta a quantidade de operadores de cada tipo usados no blocos,
        assim como o peso de cada um dos tipos de operadores.

        É notável a diferença entre a quantidade de ciclos necessários por operação nos cenários
        1 e 2. Essa diferença pode ser explicada pelo uso de uma memória para o armazenamento, resultando
        em um gargalo no sistema e impedindo a leitura paralela de dados que não possuem dependências
        entre si. Já no cenário 3 o consumo de área aumenta em mais de 2 vezes, porém o número de ciclos
        necessários por operação diminui em proporção bem maior. De fato, os 4 ciclos são provenientes
        sobretudo do bloco de controle do sistema (máquina de estados finitos).

        A tabela \ref{tab:results-post-rtl}, a seguir, mostra a utilização de recursos e os atrasos máximos
        para cada cenário na etapa de síntese pós-RTL.
        \input{tabelas/results-post-rtl-synth.tex}

        Salienta-se a utilização de blocos de memória RAM da FPGA no cenário 1. Com a utilização de memórias,
        o número de LUTs\footnote{LUT: Look-Up Table, o bloco funcional mais comum (numeroso) em FPGAs}
        ocupadas caiu significativamente.

        Outro ponto a ser destacado é que a diferença entre o número de LUTs ocupadas nos cenários 2 e 3 chega
        a quase 100\%. No entanto, quando se compara as porcentagens de utilização do FPGA, a diferença já não
        é tão significativa (2.25\% vs. 3.40\%). Isso nos leva a crer que em um futuro ainda próximo, à
        medida que os FPGAs ganharem mais blocos funcionais, a síntese de alto nível se tornará cada vez mais
        viável em termos de área.

        Como última observação sobre a etapa de síntese pós-RTL, gostaríamos de chamar a atenção para os
        atrasos máximos obtidos. Mesmo no cenário 3 o atraso máximo previsto ainda é bem menor do que nosso
        limite superior (20 ns), e portanto a frequência de clock do bloco poderia ser maior, caso fosse
        necessário.
    
        A comparação com a implementação RTL de referência foi realizada (como já mencionado) somente na
        etapa de síntese pós-RTL. O mesmo dispositivo-alvo e os mesmos níveis de otimização foram
        utilizados em todos os cenários. A tabela \ref{tab:results-compare-hls-rtl} demonstra essa
        comparação.
        \input{tabelas/results-compare-hls-rtl.tex}

