Desde a implementação original da arquitetura [Possa 2013], a quantidade de EPs é definida durante a síntese. Sendo assim, uma vez fixada esta quantidade a única ma- neira de alterá-la é sintetizar o projeto novamente e, consequentemente, gravar um novo bitstreamno FPGA.
Independentemente da quantidade, os EPs têm a mesma estrutura interna. Assim sendo, a depender da aplicação a ser executada é necessário ativar os blocos internos de cada EP, bem como as conexões entre eles. Isso é feito, por software, em tempo de execução.
3.3.1
Configurando Internamente um EP
Como mencionado anteriormente o mecanismo de configuração da arquitetura é ba- seado no CDT, que é uma estrutura de configuração genérica formada por uma série de decodificadores de configuração hierarquicamente organizados. O objetivo do CDT é fornecer acesso a todos os registradores de configuração localizados nos módulos e ope- radores. A Figura 3.14 mostra todos os níveis do CDT, desde a palavra de configuração da arquitetura (config_in, na Figura 3.14) até os registradores decodificadores de confi- guração (Reg-CDs, na Figura 3.14), que são os nós terminais do CDT, pertencentes aos blocos. Qualquer nó do CDT pode ser parametrizado em tempo de execução.
O P2IP-CD é o nó de entrada da estrutura do CDT. Ele extrai parâmetros globais da configuração de entrada, tais como tamanho do quadro a ser processado, e transfere o restante ao próximo nível, os EP-CDs. Cada EP (na Figura 3.14), e seus componentes internos, possui um número de identificação (ID). Esses IDs são usados para identificar operadores específicos na arquitetura. Para acessar um operador é necessário enviar atra- vés do barramento de configuração todos os IDs do caminho até o operador: ID do EP, ID do módulo e ID do operador.
As mensagens de configuração são divididas em chamadas de configuração globais e locais. As globais são direcionadas ao controlador da P2IP, e compreendem, por exemplo, global reset, configuration call3 e definições da resolução de vídeo a ser utilizada. Já 3Finaliza uma chamada de configuração local. Este recurso é necessário porque algumas chamadas de configuração locais, tais como a de configuração da IR, envolve mais de uma palavra de configuração.
CAPÍTULO 3. ARQUITETURA P2IP 34
(a) Imagem original. (b) Resultado após execução do Canny Edge Detection.
(c) Imagem original após execução do Edge Sharpening.
(d) Resultado após execução do Harris Corner Detection.
Figura 3.13: Exemplo de uma imagem processada pelas três aplicações mapeadas na P2IP. (a) Imagem original; (b) Canny Edge Detection - saída invertida para melhor visualização; (c) Edge Sharpening; (d) Harris Corner Detection. Fonte: [Possa 2013].
CAPÍTULO 3. ARQUITETURA P2IP 35
Figura 3.14: Arquitetura do CDT, destacando, em azul-escuro, os nós ativos durante a configuração de um operador. Fonte: [Possa 2013].
as chamadas de configuração locais são relacionadas à configuração interna dos EPs, e compreendem:
• os blocos internos que realizarão o processamento; • as entradas e saídas do EP;
• as conexões internas do EP.
3.4
Conclusão
O Capítulo apresenta uma breve descrição sobre o funcionamento da arquitetura P2IP. A fim de facilitar o entendimento sobre o funcionamento da arquitetura uma explicação detalhada sobre a composição e o funcionamento do Elemento de Processamento foi dada. Em seguida é abordado o mapeamento de três aplicações de processamento de vídeo, em
CAPÍTULO 3. ARQUITETURA P2IP 36 relação a quantos EPs são necessários a cada aplicação, e também que blocos internos (de cada EP) participam ativamente do processamento, bem como qual a configuração do datapath, para cada aplicação. Por último, o mecanismo de configuração é descrito, e também é mostrada uma tabela contendo todos os possíveis comandos de configuração da arquitetura.
Entretanto, dependendo da aplicação de processamento de vídeo, nem todos os EPs estão completamente em uso. Ainda assim, estes contribuem para o consumo estático de energia. Esta limitação é explorada nesta tese, e modificações do EP, a fim de atingir um consumo energético mais eficiente, são propostas. Além disto, também são propostas alterações no mecanismo de configuração da arquitetura: nesta nova versão a configuração é feita por um processador ARM. Tais modificações são mostradas no Capítulo 4.
Capítulo 4
Sistema Proposto
Conforme exposto na Seção 1.1 esta tese tem por objetivo investigar a utilização da RP a fim de obter um consumo energético mais eficiente. Como estudo de caso é proposta uma alteração na arquitetura P2IP. Este Capítulo discorre sobre as modificações feitas na arquitetura, detalhada no Capítulo 3, de maneira que seja possível ao leitor compreender os resultados mostrados no Capítulo 5.
As versões iniciais da arquitetura [Possa 2013, Possa et al. 2014, Possa et al. 2015] foram implementadas em FPGAs Altera. Entretanto, até o desenvolvimento deste traba- lho, as ferramentas de suporte à reconfiguração parcial são mais amplamente disponíveis na Xilinx do que na Altera. Portanto, a Xilinx foi escolhida para ser utilizada no desen- volvimento deste trabalho. Sendo assim, a primeira etapa de projeto foi migrar o projeto da Altera para a Xilinx. Tanto nas primeiras versões quanto na atual a linguagem de descrição de hardware utilizada foi Verilog.
A quantidade de EPs necessários é definida pela aplicação que demanda mais pro- cessamento. Dentre as três aplicações utilizadas para validação da arquitetura, citadas na Seção 3.2, Harris Corner Detection é a que apresenta o maior custo computacional, exigindo sete EPs e, portanto, esta é a quantidade definida antes da síntese. Entretanto, ao executar a aplicação Canny Edge Detection, apenas cinco EPs são ativamente utilizados1; no tocante à execução da aplicação Edge Sharpening, apenas três estão sendo utiliza- dos. Os EPs ociosos (em termos de processamento) ainda contribuem para o consumo estático, e não podem simplesmente ser removidos, pois são necessários para garantir a continuidade do fluxo de vídeo.
A fim de superar esta limitação a ideia deste trabalho é propor uma versão de baixo consumo, com a mesma funcionalidade, da arquitetura P2IP. Para isso uma versão modifi- cada do EP (chamada deste ponto em diante bypass) é proposta. Esta não contém nenhum 1O termo ativamente utilizados refere-se à operação dos blocos internos de processamento (ver Figura 3.3).
CAPÍTULO 4. SISTEMA PROPOSTO 38
bloco interno de processamento; apenas replica a entrada na saída. O EP bypass pode ser utilizado em substituição ao EP original, quando este estiver ocioso, contribuindo, desta maneira, para uma melhor eficiência energética [Avelino, Obac, Harb, Valderrama, Albu- querque e Possa 2017].
Apesar de a quantidade de EPs se manter inalterada em tempo de execução, como há duas variações de EP (padrão e bypass) a RP é utilizada, em tempo de execução, para alterar o tipo do EP.
Visando melhor entendimento o Capítulo está subdividido conforme explicitado a se- guir. A Seção 4.1 justifica a escolha da placa utilizada no trabalho. Dando continuidade, a Seção 4.2 discorre sobre a estratégia de medição de potência em tempo de execução. Em seguida, a Seção 4.3 explicita como a RP é aplicada à P2IP. Por último, a Seção 4.4 apresenta a conclusão do Capítulo.
4.1
Placa Utilizada
Como este trabalho se propõe a realizar medição da potência consumida em tempo de execução faz-se necessária a utilização de uma placa de desenvolvimento. Muitos trabalhos de pesquisa utilizam FPGAs de alto desempenho [Harb 2011, Ihsen 2016]; a família Virtex, no caso da Xilinx. Observando os resultados da síntese do projeto, expos- tos no Capítulo 5, e também baseando-se em versões inciais da arquitetura [Possa 2013], optou-se por utilizar nesta tese a família de baixo custo da Xilinx: Artix-7.
Esta família de FPGA é a que possui a menor quantidade de recursos (low-end) da sé- rie 7 da Xilinx, seguida pela Kintex-7 (mid-range) e Virtex-7 (high-performance). Todos os FPGAs da família 7 suportam RP2[Xilinx 2015a].
A placa de desenvolvimento ZC702 [Xilinx 2015d], da Xilinx, foi utilizada para testar a nova proposta. Esta placa contém um SoC, chamado Zynq [Xilinx 2015e], composto por um ARM Cortex A-9, chamado Processing System (PS), dual-core, e um FPGA Xilinx Artix-7, chamado Programmable Logic (PL). Esse mesmo modelo de FPGA é encontrado também na ZedBoard [Avnet 2014]. Apesar de ambas as placas compartilharem o mesmo modelo de FPGA, a ZC702 possui pontos de monitoramento de tensão e corrente, o que favoreceu a escolha desta para utilização neste trabalho.
A placa ZC702 inclui controladores PMBus, que consiste em um protocolo de ge- renciamento de energia que facilita a comunicação com conversores de potência e outros dispositivos, em um sistema de potência [PMBus 2016]. Isso permite acesso, por hard- 2Essa foi a primeira geração de FPGAs da Xilinx com essa característica. Até a 6ageração de FPGAs da Xilinx apenas algumas famílias suportavam RP.
CAPÍTULO 4. SISTEMA PROPOSTO 39
ware ou por software, aos controladores de potência da placa. A placa ZC702 utiliza três controladores PMBus UCD92xx, da Texas Instruments [Instruments 2012]. Estes contro- ladores permitem configurar, controlar e monitorar, utilizando o protocolo I2C, a tensão aplicada a onze pontos na placa, conforme mostrado na Figura 4.1.
A Tabela 4.1 descreve as onze variáveis monitoradas pelos três controladores PM- Bus, conforme mostrado na Figura 4.1. O primeiro, Power Controller 1, é responsável pelo monitoramento das variáveis VCCINT, VCCPINT, VCCAUX e VCCPAUX. Já o se- gundo, Power Controller 2, monitora VCCADJ, VCC1V5, VCCMIO e VCCBRAM. Por último, o Power Controller 3 gerencia VCC3V3, VCC2V5 e VTTDDR.
Figura 4.1: Os três reguladores de potência da ZC702. Cada um destes pode ser acessado, por hardware ou por software, através de um endereço PMBus. Fonte: [Xilinx 2015d].
4.2
Medição de Potência
Há duas maneiras de acessar a informação disponibilizada pelos controladores PMBus na placa ZC702. A primeira utiliza o software Fusion Digital Power Design [TI 2017].
CAPÍTULO 4. SISTEMA PROPOSTO 40
Tabela 4.1: Pontos de medição na placa ZC702. Fonte: [Xilinx 2015d].
VCCINT Tensão de 1V aplicada ao núcleo do FPGA
VCCPINT Tensão de 1V aplicada ao núcleo do ARM
VCCAUX Tensão de 1,8V aplicada aos circuitos auxiliares do FPGA VCCPAUX Tensão de 1,8V aplicada aos circuitos auxiliares do ARM
VCCADJ Tensão de 2,5V aplicada
VCC1V5 Tensão de 1,5V
VCCMIO Tensão de 1,8V aplicada aos bancos de pinos MIO VCCBRAM Tensão de 1V aplicada aos bancos de memória RAM
VCC3V3 Tensão de 3,3V
VCC2V5 Tensão de 2,5V
VTTDDR Tensão aplicada à memória DDR
Essa alternativa exige o uso do USB Interface Adapter EVM [TI 2006] para acessar os controladores UCD92xx na placa.
O segundo método consiste em utilizar a interface I2C, presente no ARM e/ou no FPGA3, e exige a utilização de código no padrão PMBus para ler e escrever comandos nos UCD92xx [Srikanth 2014].
Utilizar o FPGA para realizar tal medição não é uma boa solução, pois implica em utilizar mais recursos lógicos para definir em hardware a interface de comunicação com o I2C e, consequentemente, isso também contribuiria para a elevação do consumo de potência, já que a área ocupada é um pouco maior. Utilizar o adaptador USB externo é a maneira mais eficiente, pois os dados relativos à medição de potência são disponibilizados através do software Fusion Design, da Texas Instruments. Utilizar o ARM é uma boa alternativa, se o adaptador USB externo [TI 2006] não estiver disponível.
Para este trabalho foi escolhida a primeira alternativa, pois escolher a segunda implica em sintetizar circuitos de interface I2C e também de controle das mensagens PMBus no FPGA, acarretando em um consumo extra de energia [Nunez-Yanez et al. 2016].
A tensão aplicada ao núcleo do FPGA, VCCINT, de acordo com a Tabela 4.1, é de 1V . A Equação 4.1 mostra como é calculada a potência dissipada pelo núcleo do FPGA. Um resistor shunt de 5mΩ, 1%, 2W, é ligado em série com o núcleo do FPGA. Um am- plificador de instrumentação (que utiliza o protocolo I2C) mede a diferença de potencial nos terminais do resistor. A partir daí o valor de tensão pode ser adquirido através do protocolo I2C. A Figura 4.2 mostra o circuito de monitoramento, incorporado à placa de desenvolvimento.
3O ARM já possui, em sua arquitetura, a interface I2C. No caso do FPGA é necessário sintetizar um módulo que contenha a funcionalidade do protocolo I2C, assim como a lógica de controle para decodificar os comandos PMBus.
CAPÍTULO 4. SISTEMA PROPOSTO 41 Ganho 23,7 5m VCCINT 1V + - + - Núcleo FPGA Conversor I2C DC/DC Multiplexador I2C Regulador DC/DC ARM/hw externo
Figura 4.2: Circuito de medição da potência consumida pelo núcleo do FPGA e como esta informação é transmitida através do protocolo I2C. Fonte: adaptado de [Xilinx 2013b].
P= V
2
5mΩ (4.1)
O software Fusion Design permite definir quais parâmetros mensurar e a taxa de aqui- sição. A taxa mínima é de 10ms, mas é importante ressaltar que nem sempre essa taxa é respeitada, por dois motivos. O primeiro está relacionado à latência do controlador PMBus na placa ZC702. Para averiguar este valor foi criado um projeto para enviar os comandos I2C de leitura da potência pelo ARM. Um timer de 32 bits, de uso geral, do ARM (SCU Timer) foi utilizado para aferir a latência dos comandos I2C. A interface pode ser configurada para funcionar a 100 ou 400kHz4. O resultado pode ser visto na Tabela 4.2, através da qual é possível inferir que configurar a interface I2C para operar a 400kHz implica em uma resposta apenas 11,37% mais rápida.
Tabela 4.2: Latência dos comandos I2C. f Latência (ms)
100kHz 5,1377
400kHz 4,5536
Então, o alto valor da latência é devido aos atrasos inerentes às chamadas de função I2C.
O segundo motivo é que a comunicação entre o software e o circuito de monitoramento I2C na ZC702 é por polling e o sistema operacional5 sob o qual o software executa não 4O protocolo I2C permite taxas mais elevadas. No entanto, o UCD9240 só aceita um dos dois valores anteriormente mencionados.
5Até o momento da realização deste trabalho o software Fusion Design está disponível apenas para o sistema operacional Windows.
CAPÍTULO 4. SISTEMA PROPOSTO 42
é de tempo real. Sendo assim, durante os testes a taxa mínima obtida foi em torno de 100ms. Observando o arquivo de log gerado pelo software foi possível perceber que a quantidade de amostras por segundo variava entre nove e 11, e nem sempre o intervalo de 100ms entre as amostras era respeitado, fato explicado neste parágrafo.
A taxa de 100ms permite medir o consumo durante o funcionamento do FPGA, porém se mostra insuficiente para medir o consumo durante a reconfiguração parcial, tendo em vista que esta ocorre em um intervalo muito menor do que 100ms. O aumento no consumo durante a reconfiguração parcial deve-se, basicamente, ao acesso à memória (na qual está armazenado o bitstream parcial) e a utilização da interface de reconfiguração parcial.