uma abordagem meta-heurÍstica para o mapeamento … · 2019. 10. 25. · catalogação na fonte...

Max Santana Rolemberg Farias

UMA ABORDAGEM META-HEURÍSTICA PARA O

MAPEAMENTO DE TAREFAS EM UMA PLATAFORMA

MPSOC BASEADA EM NOC

Tese de Doutorado

Universidade Federal de [email protected]

www.cin.ufpe.br/~posgraduacao

RECIFE2014

www.cin.ufpe.br/~posgraduacao

Universidade Federal de Pernambuco

Centro de InformáticaCiência da Computação


UMA ABORDAGEM META-HEURÍSTICA PARA O MAPEAMENTODE TAREFAS EM UMA PLATAFORMA MPSOC BASEADA EM NOC

Trabalho apresentado ao Programa de Ciência da

Computação do Centro de Informática da Universidade

Federal de Pernambuco como requisito parcial para a

obtenção do grau de Doutor em Ciência da Computação.

Orientadora: Edna Natividade da Silva Barros

RECIFE2014

Catalogação na fonte

Bibliotecária Jane Souto Maior, CRB4-571

L747r Farias, Max Santana Rosemberg

Uma abordagem meta-heurística para o mapeamento de tarefas em uma plataforma MPSoC baseada em nos. / Max Santana Rosemberg Farias. – Recife: O Autor, 2014.

125 f.: il., fig., tab. Orientador: Edna Natividade da Silva Barros. Tese (Doutorado) – Universidade Federal de Pernambuco.

CIn, Ciência da Computação, 2014. Inclui referências e apêndices.

1. Engenharia da computação. 2. Sistemas embarcados. 3. Otimização. I. Barros, Edna Natividade da Silva (orientadora). II. Título. 621.39 CDD (23. ed.) UFPE- MEI 2014-186


Uma Abordagem Meta-Heurística Para o Mapeamento de Tarefas em uma Plataforma MPSoC Baseada em NoC

Tese apresentada ao Programa de Pós-Graduação em Ciência da Computação da Universidade Federal de Pernambuco, como requisito parcial para a obtenção do título de Doutor em Ciência da Computação.

Aprovado em: 11/09/2014

BANCA EXAMINADORA

___________________________________________ Prof. Abel Guilhermino da Silva Filho

Centro de Informática/ UFPE

________________________________________________ Prof. Aluizio Fausto Ribeiro Araújo

Centro de Informática / UFPE

__________________________________________________ Prof. Manoel Eusebio de Lima Centro de Informática / UFPE

____________________________________________________ Prof. Cesar Albenes Zeferino

Centro de Ciências Tecnológicas da Terra e do Mar / UNIVALI

____________________________________________________ Prof. Elmar Uwe Kurt Melcher

Departamento de Sistemas e Computação / UFCG

Eu dedico esta tese a minha esposa, Andréa, aos meus

filhos, Max Vinícius e Maria Eduarda, a toda minha família,

amigos e professores.

Agradecimentos

O sucesso deste Doutorado se deve ao auxilio de muitos, mas, em primeiro lugar,agradeço a minha esposa, que me apoiou nas horas mais difíceis e por suportar meus estressesquando as coisas pareciam fugir ao controle. Andréa, te amo muito. Agradeço aos meus filhos,Max Vinícius e Maria Eduarda por me motivarem durante todos estes anos de doutorado. MaxVinícius e Maria Eduarda, papai ama muito vocês. Também não posso esquecer de agradeceraos meus pais, Pedro e Maria Izabel, pelo grande apoio nesta longa caminhada da minha vida.

Uma pessoa teve uma participação muito significativa nesta minha conquista; por isso,não posso esquecer de agradecer a minha orientadora, uma das pessoas mais incríveis quetive o prazer de conhecer e conviver, que me ensinou muito durante estes anos. Agradeço asua paciência, as observações, os comentários, as críticas, as broncas, o incentivo e todo oconhecimento que adquiri durante o desenvolvimento deste trabalho, que contribuíram para omeu desenvolvimento pessoal e profissional. Profª. Edna agradeço-lhe a confiança e espero teratendido às suas expectativas.

Não poderia esquecer-me do pessoal do laboratório C23 do Centro de Informática daUniversidade Federal de Pernambuco (CIn/UFPE), onde encontrei a amizade e o companheirismode muitos outros estudantes (não tem como citar nomes). Não consigo imaginar o términodeste doutorado sem as discussões sobre diversos assuntos e, principalmente, sem as trocas deexperiências. Agradeço aos meus companheiros de publicações: André Aziz, André Olivinoe João Erick. Valeu pela força. Foi muito legal trabalhar com vocês. Também não poderiaesquecer de agradecer ao pessoal do Laboratório de Embarcados e Sistemas Distribuídos (LEDS)da Universidade do Vale do Itajaí (Univali), principalmente ao Prof. Cesar Zeferino que ajudouna infraestrutura deste trabalho. Valeu a força de todos vocês, agradeço de coração.

Agradeço ainda o suporte financeiro advindo do CNPq e o suporte operacional proporcionadopela FACEPE, que também foi muito imprescindível.

Posso todas as coisas naquele que me fortalece.

—APÓSTOLO PAULO

Resumo

O crescente número de tarefas em execução em plataformas Multiprocessor Systems-

on-Chips (MPSoC) exige mais e mais processadores e as plataformas MPSoC que utilizam omeio de comunicação tradicional (barramento) possui uma largura de banda limitada e não sãoescaláveis para projetos de alta performance. Nesse sentido, os MPSoC baseados em Network-

on-Chip (NoC) foram propostos para resolver estas limitações. Um dos principais problemas emplataformas MPSoC baseado em NoC é o custo de comunicação, pois esse custo de comunicaçãodepende do mapeamento de tarefas nos processadores. Este trabalho apresenta uma abordagemque utiliza uma meta-heurística para atribuir um conjunto de tarefas a um conjunto de Processing

Element (PE) em um MPSoC baseado em NoC. Esta abordagem proposta avalia e otimiza omapeamento de tarefas de aplicações e, em alguns experimentos, os resultados foram comparadoscom o pior e o melhor mapeamento do espaço de projeto. Os resultados encontrados durante osexperimentos mostram uma redução média de energia de 47% quando é utilizado o mecanismode agrupamento de tarefas e 44% quando o mecanismo de agrupamento é desligado.

Palavras-chave: Network on Chip. MPSoC. Mapeamento de Tarefas.

Abstract

The increasing number of tasks running on platforms MPSoC requires more and moreprocessors and platforms MPSoC using the traditional means of communication (bus) has alimited bandwidth and are not scalable to projects high performance. In this sense, the NoC-basedMPSoC been proposed to address these limitations. One of the main problems in platformsNoC-based MPSoC is the communication cost, since the cost of communication depends on themapping of tasks to processors. This work presents an approach that uses a meta-heuristic toassign a set of tasks to a set of PE on an NoC-based MPSoC . This proposed approach evaluatesand optimizes the mapping of tasks and applications, in some experiments, the results werecompared to the worst and the best mapping of the design space. The results obtained during theexperiments show an average energy reduction of 47% when using the grouping mechanism oftasks and 44% when the grouping mechanism is turned off.

Keywords: Network on Chip. MPSoC. Task Mapping.

Lista de Figuras

1.1 Evolução do processo de fabricação dos circuitos integrados. . . . . . . . . . . 241.2 Número de processadores por chip. . . . . . . . . . . . . . . . . . . . . . . . 25

2.1 Plataforma MPSoC genérica . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.2 Plataforma MPSoC baseada em barramento simples . . . . . . . . . . . . . . . 282.3 Plataforma MPSoC baseada em barramentos hierárquicos . . . . . . . . . . . . 282.4 Plataforma MPSoC baseada em NoC . . . . . . . . . . . . . . . . . . . . . . . 292.5 Fluxo Genérico do projeto de um MPSoC . . . . . . . . . . . . . . . . . . . . 292.6 Principais componentes de uma Plataforma MPSoC baseada em NoC . . . . . 312.7 Fluxo dos dados através da NoC . . . . . . . . . . . . . . . . . . . . . . . . . 322.8 Interface de rede Network Interface Controller (NIC) . . . . . . . . . . . . . . 322.9 Formato de uma mensagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342.10 Rede direta: (a) malha 2D (b) toróide 2D (c) hipercubo 3D (d) anel . . . . . . . 352.11 Rede indireta: (a) árvore (b) anel . . . . . . . . . . . . . . . . . . . . . . . . . 352.12 Mapeamento de tarefas em uma plataforma MPSoC . . . . . . . . . . . . . . . 382.13 Modelo de uma aplicação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392.14 Modelo de uma plataforma MPSoC 2x2 . . . . . . . . . . . . . . . . . . . . . 392.15 Plataforma Infinity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412.16 Visão Estrutural de uma Interface de Rede no Modelo OSI . . . . . . . . . . . 422.17 Organização da interface de rede . . . . . . . . . . . . . . . . . . . . . . . . . 432.18 Estrutura da mensagem da plataforma Infinity . . . . . . . . . . . . . . . . . . 45

3.1 Fluxo do projeto implementado por JENA; SHARMA (2007) . . . . . . . . . . 573.2 Algoritmo ACO implementado por WANG et al. (2011) . . . . . . . . . . . . . 603.3 Algoritmo PSO implementado por SAHU et al. (2014) . . . . . . . . . . . . . 62

4.1 Fluxo da Proposta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 664.2 Grafo de Características da Plataforma: (a) Plataforma MPSoC 2x2 (b) GCP da

Plataforma MPSoC 2x2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 674.3 Grafo de Dependências entre Tarefas de uma aplicação sintética: (a) Código

fonte da aplicação (b) GDT da aplicação . . . . . . . . . . . . . . . . . . . . . 674.4 Algoritmo para gerar o grafo inverso do GDT . . . . . . . . . . . . . . . . . . 684.5 Um exemplo de agrupamento de tarefas: (a) GDT, (b) GDT’ e (c) Grafo colorido 694.6 Algoritmo de coloração de vértices . . . . . . . . . . . . . . . . . . . . . . . . 704.7 Grafo de Comunicação de Tarefas . . . . . . . . . . . . . . . . . . . . . . . . 71

4.8 Comportamentos das Formigas: (a) Início aleatório e (b) Final com comprimentomínimo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

4.9 Algoritmo Colônia de Formiga . . . . . . . . . . . . . . . . . . . . . . . . . . 774.10 Fluxo de Construção de uma Solução pelo Ant Colony Optimization (ACO) . . 784.11 Demonstração dos parâmetros α e β : (a) α < β e (b) α > β . . . . . . . . . . 794.12 Grafos do exemplo de construção de uma solução: (a) GCP (b) GCT . . . . . . 804.13 Um exemplo de construção de uma solução . . . . . . . . . . . . . . . . . . . 81

5.1 Fluxo do projeto usando PowerPlay . . . . . . . . . . . . . . . . . . . . . . . 865.2 Placa DE2-70 com o filtro amplificador . . . . . . . . . . . . . . . . . . . . . 865.3 Prototipação e medição da potência da NoC . . . . . . . . . . . . . . . . . . . 865.4 GDT da aplicação MPEG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 885.5 GDT da aplicação SegImg . . . . . . . . . . . . . . . . . . . . . . . . . . . . 895.6 GDT da aplicação PIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 895.7 Mapeamento inicial para o cenário de teste 1 (a) MPEG, (b) SegImg e (c) PIP . 905.8 Amostra da aplicação MPEG para o cenário de teste 1 . . . . . . . . . . . . . . 925.9 Amostra da aplicação SegImg para o cenário de teste 1 . . . . . . . . . . . . . 925.10 Amostra da aplicação PIP para o cenário de teste 1 . . . . . . . . . . . . . . . 935.11 Espaço de projeto da aplicação MPEG para o cenário de teste 2 . . . . . . . . . 935.12 Espaço de projeto da aplicação SegImg para o cenário de teste 2 . . . . . . . . 945.13 Espaço de projeto da aplicação PIP para o cenário de teste 2 . . . . . . . . . . 945.14 Mapeamento inicial para o cenário de teste 2 (a) MPEG, (b) SegImg e (c) PIP . 955.15 Amostra da aplicação MPEG para o cenário de teste 2 . . . . . . . . . . . . . . 965.16 Amostra da aplicação SegImg para o cenário de teste 2 . . . . . . . . . . . . . 965.17 Amostra da aplicação PIP para o cenário de teste 2 . . . . . . . . . . . . . . . 975.18 Exploração do espaço de projeto da aplicação MPEG para o cenário 2 . . . . . 985.19 Exploração do espaço de projeto da aplicação SegImg para o cenário 2 . . . . . 985.20 Exploração do espaço de projeto da aplicação PIP para o cenário 2 . . . . . . . 995.21 Comparação do tráfego e energia da abordagem com o espaço de projeto das

aplicações para o cenário de teste 2 . . . . . . . . . . . . . . . . . . . . . . . . 995.22 Mapeamento inicial na seção de teste 3 (a) MPEG, (b) SegImg e (c) PIP . . . . 1005.23 Amostra da aplicação MPEG no cenário de teste 3 . . . . . . . . . . . . . . . . 1015.24 Amostra da aplicação SegImg no cenário de teste 3 . . . . . . . . . . . . . . . 1015.25 Amostra da aplicação PIP no cenário de teste 3 . . . . . . . . . . . . . . . . . 1025.26 Desempenho da abordagem proposta no experimento A para a aplicação MPEG 1025.27 Desempenho da abordagem proposta no experimento A para a aplicação SegImg 1035.28 Desempenho da abordagem proposta no experimento A para a aplicação PIP . . 1035.29 Espaço de projeto do experimento B . . . . . . . . . . . . . . . . . . . . . . . 1045.30 Mapeamento inicial para o experimento B . . . . . . . . . . . . . . . . . . . . 104

5.31 Amostra da abordagem para o experimento B . . . . . . . . . . . . . . . . . . 1055.32 Amostra do SA para o experimento B . . . . . . . . . . . . . . . . . . . . . . 1075.33 Exploração do espaço de projeto do experimento B . . . . . . . . . . . . . . . 1075.34 Comparação do tráfego e energia da abordagem com o espaço de projeto do

experimento B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1085.35 Mapeamento inicial para o experimento C . . . . . . . . . . . . . . . . . . . . 1085.36 Amostra da abordagem para o experimento C . . . . . . . . . . . . . . . . . . 109

Lista de Tabelas

2.1 Características de uma NoC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342.2 Descrição dos serviços que um pacote de rede pode carrega . . . . . . . . . . . 44

3.1 Variáveis utilizadas no subproblema de alocação de tarefas . . . . . . . . . . . 473.2 Atividades de uma tarefa da aplicação . . . . . . . . . . . . . . . . . . . . . . 483.3 Funções modeladas por GHOSH; SEN; HALL (2009) . . . . . . . . . . . . . . 503.4 Variáveis utilizadas por GHOSH; SEN; HALL (2009) . . . . . . . . . . . . . 503.5 Variáveis da formulação Integer Linear Programming (ILP) proposta por HUANG

et al. (2011) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523.6 Propriedades da aresta ai j do grafo de características da aplicação . . . . . . . 533.7 Propriedades da aresta ri j do grafo de características da plataforma . . . . . . . 543.8 Funções utilizadas pelo operador de mutação do Strength Pareto Evolutionary

Algorithm (SPEA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563.9 Aplicações e configurações da plataforma . . . . . . . . . . . . . . . . . . . . 623.10 Comparação do custo e desempenho . . . . . . . . . . . . . . . . . . . . . . . 623.11 Trabalhos relacionados baseados em métodos exatos . . . . . . . . . . . . . . 633.12 Trabalhos relacionados baseados em busca . . . . . . . . . . . . . . . . . . . . 633.13 Analise comparativa dos trabalhos baseados em métodos exatos . . . . . . . . 633.14 Analise comparativa das meta-heurísticas baseadas em busca . . . . . . . . . . 643.15 Analise comparativa dos algoritmos baseados em inteligência coletiva . . . . . 64

4.1 Tabela de feromônio inicial . . . . . . . . . . . . . . . . . . . . . . . . . . . . 804.2 Tabela de fluxo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 804.3 Passo 1 do exemplo de construção de uma solução . . . . . . . . . . . . . . . . 804.4 Passo 2 do exemplo de construção de uma solução . . . . . . . . . . . . . . . . 814.5 Passo final do exemplo de construção de uma solução . . . . . . . . . . . . . . 824.6 Soluções encontradas para o exemplo . . . . . . . . . . . . . . . . . . . . . . 824.7 Tabela de feromônio atualizada . . . . . . . . . . . . . . . . . . . . . . . . . . 824.8 Analise comparativa da abordagem proposta com os trabalhos relacionados . . 83

5.1 Configurações da NoC SoCIN . . . . . . . . . . . . . . . . . . . . . . . . . . 845.2 Configuração do mecanismo de mapeamento de tarefas . . . . . . . . . . . . . 855.3 Estimativas do PowerPlay Analyzer sobre uma NoC . . . . . . . . . . . . . . 875.4 Parâmetros de configuração do ambiente de medição . . . . . . . . . . . . . . 875.5 Potências dissipadas pela NoC . . . . . . . . . . . . . . . . . . . . . . . . . . 875.6 Valores críticos de Z . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

5.7 Informações do mapeamento inicial das aplicações para o cenário de teste 1 . . 915.8 Amostra inicial para o cenário de teste 1 . . . . . . . . . . . . . . . . . . . . . 915.9 Informações do mapeamento inicial das aplicações para o cenário de teste 2 . . 945.10 Valores de n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 955.11 Amostras para o cenário de teste 2 . . . . . . . . . . . . . . . . . . . . . . . . 955.12 O melhor e o pior mapeamento para o MPEG no cenário de teste 2 . . . . . . . 975.13 O melhor e o pior mapeamento para o SegImg no cenário de teste 2 . . . . . . 975.14 O melhor e o pior mapeamento para o PIP no cenário de teste 2 . . . . . . . . . 975.15 Informações do mapeamento inicial das aplicações na seção de teste 3 . . . . . 995.16 Amostra inicial da seção de teste 3 . . . . . . . . . . . . . . . . . . . . . . . . 1005.17 Resultados do mapeamentos do espaço de projeto . . . . . . . . . . . . . . . . 1045.18 Amostra do cenário de teste para o experimento B . . . . . . . . . . . . . . . . 1065.19 Informações do mapeamento inicial para o experimento C . . . . . . . . . . . 1085.20 Amostra do experimento C . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

A.1 Publicações realizadas durante o período do doutorado. . . . . . . . . . . . . . 117

Lista de Acrônimos

ACO Ant Colony Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

AMBA Advanced Microcontroler Bus Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

API Application Programming Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

ARM Acorn RISC Machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

ASIC Application Specific Integrated Circuit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

BOP Begin of Packet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .44

CWM Communication Eighted Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

DSP Digital Signal Processor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

DVS Dynamic Voltage Scaling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

E3S Embedded System Synthesis Benchmarks Suite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

ES Exhaustive Search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

BOP End of Packet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

E/S Entrada e Saída . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .71

flit flow control unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

FPGA Field Programmable Gate Array . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

GA Genetic Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

GCC GNU Compiler Collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

GCP Grafo de Características da Plataforma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

GCT Grafo de Comunicação de Tarefas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

GDT Grafo de Dependências entre Tarefas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

GDT’ Grafo Inverso do GDT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

GI Greedy Incremental . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

GSM Global System for Mobile Communications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

HLP High Level Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

ILP Integer Linear Programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

IP Intellectual Property . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

ITRS International Technology Roadmap for Semiconductors . . . . . . . . . . . . . . . . . . . . . 23

JPEG Joint Photographic Experts Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

LAPIC Local Advanced PIC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

LCF Largest Communication First . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

MPEG Moving Picture Experts GroInteger Linear Programmingup . . . . . . . . . . . . . . . . . . 51

MILP Mixed Integer Linear Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

M-JPEG Motion-Joint Photographic Experts Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

MMS Multi Media System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

MPEG Moving Picture Experts Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

MPSoC Multiprocessor Systems-on-Chips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

MWD Multi-Window Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

NIC Network Interface Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

NoC Network-on-Chip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

NP Non-deterministic Polynomial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

NSGA Non-dominated Sorting Genetic Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

OCP Open Core Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

OPD Object Plane Decoder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

OSI Open Systems Interconnection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

PCV Problema do Caixeiro Viajante . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

PE Processing Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

PIP Picture in Picture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

PLL Phase Locked Loops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

PSO Particle Swarm Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

QAP Quadratic Assigment Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

QAPLIB Quadratic Assignment Problem Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .74

QoS Quality of service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

RAM Random Access Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

RIB Routing Information Bits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

RISC Reduced Instruction-Set Computer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

RTEMS Real-Time Executive for Multiprocessor Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . .48

RTL Register Transfer Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

SA Simulated Annealing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

SAF Store-and-Forward . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

SA-TA Simulated Annealing with Timing Adjustment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

SegImg Segmentação de Imagens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

SHA Secure Hash Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

SoC Sytem-on-chip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

SoCIN SoC Interconnection Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

SPARC Scalable Processor Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

SPEA Strength Pareto Evolutionary Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

TGFF Traffic Graphs for Free . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .52

TLM Transaction-level modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

TS Tabu Search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

VCI Virtual Component Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32

VCT Virtual Cut-Through . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

VHDL VHSIC Hardware Description Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26

VOPD Video Object Plane Decoder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Sumário

1 INTRODUÇÃO 21

1.1 MOTIVAÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231.2 ORIGINALIDADE E OBJETIVOS DO TRABALHO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251.3 ORGANIZAÇÃO DO TRABALHO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2 CONCEITOS BÁSICOS 27

2.1 PLATAFORMA MPSOC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.1.1 Fluxo Genérico do Projeto de uma Plataforma MPSoC . . . . . . . . . . . . . . . . . . . . . . . . . 292.2 PLATAFORMA MPSOC BASEADA EM NOC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302.3 NETWORK-ON-CHIP (NoC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302.3.1 Arquitetura de uma NoC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312.3.1.1 Interface de rede (NIC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322.3.1.2 Roteador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332.3.1.3 Enlace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332.3.1.4 Mensagens e pacotes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332.3.2 Características Gerais de uma NoC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332.3.2.1 Topologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342.3.2.2 Roteamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362.3.2.3 Chaveamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362.3.2.4 Controle de fluxo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362.3.2.5 Arbitragem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372.3.2.6 Memorização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372.4 MAPEAMENTO DE TAREFAS EM UMA PLATAFORMA MPSOC . . . . . . . . . . . . . . . . . . . 372.4.1 Modelo da Aplicação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382.4.2 Modelo da Plataforma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382.4.3 Definição do Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392.5 A PLATAFORMA MPSOC INFINITY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402.5.1 Descrição da Plataforma Infinity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402.5.1.1 Núcleo infinity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412.5.1.2 Interface de rede (NIC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422.5.1.3 Modelo de mensagens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432.5.1.4 Formato da mensagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

3 TRABALHOS RELACIONADOS 46

3.1 BASEADOS EM TÉCNICAS EXATAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463.1.1 Uma Abordagem Exata para Alocar e Escalonar Tarefas . . . . . . . . . . . . . . . . . . . . . . . . 463.1.1.1 Etapa de alocação de tarefas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463.1.1.2 Etapa de escalonamento de tarefas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473.1.2 Uma Formulação MILP para o Mapeamento de Tarefas . . . . . . . . . . . . . . . . . . . . . . . . . 493.1.3 Uma Heurística para Alocação de Tarefas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513.2 MAPEAMENTO BASEADO EM BUSCA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533.2.1 Um Algoritmo Branch-and-Bound para o Mapeamento de Tarefas . . . . . . . . . . . . . . . 533.2.2 Uma Abordagem Multiobjetivo para o Problema de Mapeamento . . . . . . . . . . . . . . . . 553.2.3 Uma Abordagem Multiobjetivo para Alocação de Tarefas em PE . . . . . . . . . . . . . . . . . 563.2.3.1 Etapa de alocação de tarefas em PE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563.2.3.2 Etapa de alocação de PE em tiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 573.2.4 Algoritmos de Mapeamento para MPSoC Baseada em NoC . . . . . . . . . . . . . . . . . . . . . 583.2.5 Uma Abordagem ACO para o Mapeamento de Tarefas . . . . . . . . . . . . . . . . . . . . . . . . . 593.2.6 Uma Abordagem Particle Swarm Optimization (PSO) para o Mapeamento de Tarefas 613.3 ANALISE DOS TRABALHOS RELACIONADOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 623.3.1 Mapeamento Exato . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 633.3.2 Mapeamento Baseado em Busca . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

4 ABORDAGEM PROPOSTA 65

4.1 VISÃO GERAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 654.2 FASE DE EXTRAÇÃO DE GRAFOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 664.2.1 Grafo de Características da Plataforma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 664.2.2 Grafo de Dependências entre Tarefas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 674.3 FASE DE AGRUPAMENTO DE TAREFAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 684.3.1 Mecanismo de Agrupamento de Tarefas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 684.3.1.1 Algoritmo de coloração de grafos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 694.4 FASE DO MAPEAMENTO INICIAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 694.4.1 Grafo de Comunicação de Tarefas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 704.5 FASE DE OTIMIZAÇÃO DO MAPEAMENTO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 704.5.1 Modelo de Energia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 714.5.1.1 Medição de potência em FPGA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 714.5.1.2 Ambiente de medição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 724.5.1.3 Energia da NoC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 734.5.2 Mecanismo de Mapeamento de Tarefas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 744.5.2.1 Meta-heurística baseada em colônia de formigas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 754.6 CONCLUSÃO DA ABORDAGEM PROPOSTA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

5 EXPERIMENTOS E RESULTADOS 84

5.1 ORGANIZAÇÃO DA PLATAFORMA INFINITY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 845.2 EXPERIMENTOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 845.2.1 Mecanismo de Mapeamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 855.2.2 Ambiente de Medição de Potência . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 855.2.3 Análise Estatística . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 875.2.4 Experimento A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 885.2.4.1 Aplicação MPEG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 885.2.4.2 Aplicação de segmentação de imagens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 895.2.4.3 Aplicação PIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 895.2.5 Cenários de Teste do Experimento A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 905.2.5.1 Cenário de teste 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 905.2.5.2 Cenário de teste 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 935.2.5.3 Cenário de teste 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 985.2.6 Análise dos Resultados do Experimento A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1025.2.7 Experimento B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1035.2.8 Experimento C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1075.3 CONCLUSÕES SOBRE OS EXPERIMENTOS REALIZADOS . . . . . . . . . . . . . . . . . . . . . 110

6 Conclusões e Trabalhos Futuros 111

6.1 CONCLUSÕES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

REFERÊNCIAS 113

APÊNDICE A Publicações 117

APÊNDICE B Setup da Plataforma Infinity 118

B.1 Pré-requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118B.2 Preparação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118B.2.1 Diretório Raiz da Instalação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118B.2.2 Diretório de Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118B.2.3 Download das bibliotecas e Ferramentas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119B.2.4 Instalação das bibliotecas e Ferramentas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119B.2.4.1SystemC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120B.2.4.2TLM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120B.2.4.3SCML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121B.2.4.4ArchC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

B.2.5 Instalação do toolchain GNU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122B.2.5.1Binutils . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122B.2.5.2GCC (Parte 1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123B.2.5.3Newlib . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124B.2.5.4GCC (Parte 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124B.2.5.5GDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

212121

1INTRODUÇÃO

O avanço da tecnologia de fabricação de circuitos integrados permitiu o aumento donível de integralização entre os componentes em um circuito integrado, com a possibilidadede integrar um número cada vez maior de transistores em um Application Specific Integrated

Circuit (ASIC), permitindo, assim, o desenvolvimento de sistemas eletrônicos completos eextremamente complexos em um único chip. Esse tipo de sistema é chamado de Sytem-on-

chip (SoC). A principal vantagem de um sistema SoC diz respeito ao desempenho do sistemacom relação ao tempo de execução, já que as comunicações entre os componentes de um SoCpodem ocorrer mais rapidamente, pois os seus componentes encontram todos no mesmo circuito.Outra vantagem para utilização de SoC é o tempo reduzido de projeto, onde geralmente o projetoSoC é baseado no reuso de núcleos de hardware (Intellectual Property (IP)), que são módulospré-projetados e pré-validados. E o reuso desses núcleos pode garantir um tempo menor paraa chegada do produto ao mercado, ou seja, é possível amortizar os custos do projeto entre osdiversos projetos e cumprir assim o tempo de colocação no mercado, em inglês, Time-to-Market.Para atender a essa demanda do mercado, os SoC geralmente consistem de memória, processador,interface de comunicação, interface de entrada/saída, entre outras funções digitais/analógicas.

Quando um SoC requer vários Processing Element (PE), para suprir o aumento dacomplexidade das aplicações e seus requisitos de desempenho, chamamos esse SoC de Multiprocessor

Systems-on-Chips (MPSoC). Os MPSoC são utilizados em aplicações de sistemas embarcadosque precisam de uma plataforma com múltiplos elementos de processamento (multicores) comfuncionalidades específicas que refletem a necessidade da aplicação. O principal objetivo de umMPSoC é permitir uma maior utilização do paralelismo, ou seja, permite que seja executada umaaplicação paralela ou, até mesmo, várias aplicações em paralelo.

Atualmente, as aplicações para sistemas embarcados estão cada vez mais utilizandomúltiplos processos e threads, principalmente na área de telecomunicações (telefonia móvel,internet, HDTV, etc), processamento de sinais e multimídia. Com isso, os MPSoC são umarealidade e estão presentes em várias implementações comerciais e sendo amplamente utilizadosem projetos de sistemas embarcados (WOLF, 2004).

Um ponto importante, relacionado aos MPSoC, está relacionado à infraestrutura de

22

comunicação, ou seja, todos os componentes são ligados uns aos outros. Tradicionalmente, ainterconexão dos componentes de um SoC é realizada via barramento, que pode ser utilizando umúnico barramento ou, até mesmo, múltiplos barramentos, interligados por bridges ou organizadosde forma hierárquicas. No entanto, essa infraestrutura apresenta um baixo grau de escalabilidade,pelo fato de que apenas uma transação, de comunicação, pode ser realizada por vez, ou seja,quando o sistema tiver um número de componentes entre quatro e dez, pode rapidamente terum gargalo na comunicação (JANTSCH; TENHUNEN, 2003). Com isso, o grande desafio desistemas multicore está relacionado à infraestrutura de comunicação entre os vários núcleos,já que podemos concluir que a infraestrutura de comunicação baseada em barramento nãoatende completamente aos requisitos das aplicações atuais, que demandam dezenas a centenasde núcleos.

E para solucionar este problema de interconexão dos componentes de um MPSoC,foi proposto, no início dos anos 2000, o uso de redes intra-chip, para permitir uma maiorescalabilidade, reusabilidade e um bom grau de paralelismo nos MPSoC. Essas redes sãochamadas de Network-on-Chip (NoC) e são compostas basicamente por um conjunto de roteadores,onde cada roteador possui um conjunto de portas, que são utilizadas para conexão com seusroteadores vizinhos e com o seu elemento de processamento. Essa comunicação entre oscomponentes ocorrem por meio da troca de mensagens, ou seja, a comunicação ocorre pormeio do envio e recebimento de pacotes, seguindo os mesmos princípios que são aplicadosem projetos de rede de comunicação (GUERRIER; GREINER, 2000) (HEMANI et al., 2000)(DALLY; TOWLES, 2001) (WINGARD, 2001) (RIJPKEMA et al., 2001) (KUMAR et al., 2002)(MICHELI; BENINI, 2002).

Embora as NoC sejam consenso na literatura como uma ótima alternativa para interconectardiferentes blocos IP em MPSoC, esta infraestrutura de comunicação ainda apresenta algumasproblemas que têm sido alvo de investigações (MARCULESCU et al., 2009). Um dos problemasrelacionados por MARCULESCU et al. (2009) é o problema de alocação e agendamento detarefas. Esse problema é um dos tradicionais problemas da ciência da computação e mesmoexistindo vários algoritmos desenvolvidos para solucionar o problema de alocação, muitas vezes,eles não são adequados para aplicações embarcadas de tempo real, sendo um dos objetivos o deminimizar o consumo de energia sob restrições de desempenho. Outro problema relacionadopor MARCULESCU et al. (2009) é o de gerenciamento de energia. Esse problema é o queresolve algumas das restrições de projeto de sistemas embarcados devido às preocupações com avida da bateria, refrigeração e o custo de energia elétrica. Uma plataforma MPSoC baseada emNoC deve ter preocupações com energia, já que vários protótipos de MPSoC baseados em NoCdemonstraram que um porção substancial da energia consumida pelo sistemas é relacionada aNoC. Por exemplo, na NoC do MIT Raw, com 16 núcleos, consome quase 40% da energia total,no Alpha 21364, somente os roteadores e os links de comunicação consomem 20% da energiatotal (S. S. MUKHERJEE P. BANNON; WEBB, 2002) e no TERAFLOPS, da Intel, com 80núcleos, o consumo chega a quase 30% (VANGAL et al., 2007);

23

Para automatizar as atividades de um projeto de sistemas baseado MPSoC, de forma apermitir uma distribuição das funcionalidades dos sistemas entre os componentes de hardware

e software, que atenda aos requisitos e às restrições do projeto, e atender ao mercado, osprojetistas devem explorar ao máximo o espaço de projeto de um MPSoC para encontrar amelhor configuração possível que satisfaça as restrições do sistema, tais como: desempenho,custo e consumo de energia. Mas essa exploração do espaço de projeto de uma plataformamulticores é muito complexa e de difícil exploração, e esse problema de exploração é classificadocomo um problema de otimização combinatória NP-hard.

Neste trabalho de doutorado, foi proposta uma técnica de otimização do mapeamentode tarefas de uma aplicação, ou várias aplicações em PE de uma plataforma MPSoC. Paraisso, levamos em consideração os requisitos e as restrições, que determinam a natureza doscomponentes, como, por exemplo, o consumo de energia, que é importantíssimo em sistemasembarcados.

Inicialmente, foi proposto um mapeamento em tempo de projeto (mapeamento estático),já que é possível utilizar algoritmos mais complexos de otimização que podem avaliar um númeromaior de alternativas de mapeamento, sem afetar o tempo de execução da aplicação, já queo tempo computacional do algoritmo de mapeamento não interfere no tempo de execução daaplicação. Mas a desvantagem em utilizar o mapeamento estático está relacionada às cargasdinâmicas, que não são tratadas, como, por exemplo, a inserção de novas tarefas em tempo deexecução.

1.1 MOTIVAÇÃO

O International Technology Roadmap for Semiconductors (ITRS) aponta que as tendênciasde projetos de SoC terão dezenas de bilhões de transistores com dimensões cada vez menores ecom frequência de operação cada vez maior, nas próximas décadas. Essas tendências geram novosdesafios de projeto, como dissipação de potência durante projetos de sistemas eletrônicos. O ITRStambém prevê que o consumo de energia global deve crescer nos SoC futuros, principalmente nacomunicação intra-chip, já que a redução da tensão de alimentação não é mais suficiente parabalancear os sistemas complexos demandados pelo mercado e alimentados por baterias. E ocrescimento do mercado para sistemas embarcados (sistemas alimentados por bateria) reforça aimportância da redução de potência durante a exploração do espaço de projeto, que, antes, eravoltado principalmente para área, desempenho e testabilidade. Só que o consumo de potência estádiretamente relacionado ao tempo de vida da bateria, bem como aos requisitos de encapsulamentoe dissipação de calor. E para garantir que o sistema final esteja de acordo com os requisitosfuncionais, térmicos e de custo desejados, a questão do consumo de potência deve ser levada emconsideração durante o projeto, incluindo a estrutura de interconexão.

A Figura 1.1 mostra dois gráficos que demonstram a evolução dos chips nas últimas duasdécadas com relação à quantidade de transistores em um único chip e a frequência de relógio

24

(ISSCC, 2013).

Figura 1.1 Evolução do processo de fabricação dos circuitos integrados.

Fonte: ISSCC (2013)

E, para minimizar a potência consumida em plataforma SoC, é necessário reduzir afrequência do relógio, mas a redução da frequência leva à diminuição do desempenho dosistemas. Então, a solução para tentar reduzir a potência de um SoC sem perda de desempenhoé aumentando o paralelismo do sistema, desenvolvendo sistemas MPSoC. Por essa razão, atendencia atual é termos sistemas embarcados com mais PE, como mostra o gráfico da Figura 1.2(ISSCC, 2013). Seguindo essa tendência, tanto a Intel quanto a Tilera desenvolveram protótiposde MPSoC com 80 e 64 núcleos respectivamente, utilizando uma NoC como infraestrutura decomunicação (VANGAL et al., 2007) (TILERA, 2007).

Então a principal motivação para o desenvolvimento desse trabalho é o fato de quecerca de quase 40% do consumo de energia dos MPSoC atuais está relacionado à comunicaçãointrachip, e esse consumo tende a aumentar para os futuros sistemas a serem implementados.Por isso existe uma grande necessidade de desenvolvimento de novas técnicas para minimizara comunicação entre os componentes de uma arquitetura MPSoC, enquanto uma aplicaçãoestá sendo executada (MARCULESCU et al., 2009), já que o consumo de potência em umaNoC cresce linearmente com a quantidade de transações de sinais ocasionadas pelos pacotestransmitidos pela NoC (PALMA et al., 2005).

25

Figura 1.2 Número de processadores por chip.

Fonte: ISSCC (2013)

Uma forma de solucionar esse problema é por meio do mapeamento de tarefas, poisesse problema de mapeamento é similar ao Quadratic Assigment Problem (QAP). O QAP é umdos problemas fundamentais de otimização combinatória, sendo um problema NP-completo, ouseja, não existe uma solução para resolvê-lo em tempo polinomial. Para pequenas instâncias doproblema, como, por exemplo, mapeamento de tarefas em uma NoC de tamanho 2x2, o tempopara encontrar a melhor solução usando métodos exaustivos deve ser relativamente baixo; maspara, uma NoC 5x5, o tempo pode ser inaceitável para o projeto. Por isso este trabalho propõereduzir o consumo de potência da NoC por meio do posicionamento das tarefas comunicantes,que trocam muitas mensagens, no mesmo PE ou em PE próximos.

1.2 ORIGINALIDADE E OBJETIVOS DO TRABALHO

A originalidade do trabalho consiste na proposta de uma abordagem de mapeamentoque visa, inicialmente, agrupar as tarefas comunicantes para, em seguida, mapear as tarefas naplataforma MPSoC. E, com somente duas simulações, essa abordagem explora o espaço deprojeto para encontrar uma solução que diminui o consumo de energia mediante a redução dacomunicação na NoC. Para isso a abordagem, inicialmente, agrupa as tarefas comunicantes, ouseja, agrupa as tarefas que trocam mensagens com bastante frequência, utilizando um algoritmode agrupamento baseado no algoritmo de coloração de grafos e por fim, faz o mapear das tarefasna plataforma, utilizando uma meta-heurística baseada em colonia de formigas.

Portanto, este trabalho se aprofunda nos aspectos do desenvolvimento de uma abordagemque permite mapear tarefas de uma aplicação ou várias aplicações em uma plataforma MPSoC,otimizando assim a energia de comunicação entre os seus elementos. Os objetivos específicosdeste trabalho são:

1. Definir uma plataforma MPSoC factível de implementação, para exploração do espaço deprojeto;

26

2. Definir a organização da abordagem (como, por exemplo, os componentes básicos);

3. Definir a arquitetura da abordagem (como, por exemplo, as interfaces com as aplicações);

4. Modelar o comportamento para verificar o funcionamento do sistema.

5. Propor e avaliar mapeamentos de tarefas;

O presente trabalho tem como objetivo principal minimizar a energia de comunicaçãoda NoC, por meio da otimização do mapeamento de tarefas nos PE da plataforma MPSoC. Osresultados foram obtidos a partir de simulações de uma plataforma MPSoC composta por umaNoC descrita em VHSIC Hardware Description Language (VHDL) e os PE são simulados pormeio de threads SystemC. As métricas utilizadas para a validação da abordagens são as seguintes:

1. Tempo de execução da aplicação;

2. Volume de mensagens em cada roteador durante a execução da aplicação;

3. Energia consumida pela NoC durante a execução da aplicação.

1.3 ORGANIZAÇÃO DO TRABALHO

Este trabalho está organizado como segue: No capítulo 2, são apresentados os conceitosbásicos para o entendimento do trabalho. No capítulo 3, são apresentados os trabalhos relacionadosao problema de mapeamento de tarefas em MPSoC. No capítulo 4, é apresentada a abordagemde mapeamento de tarefas proposta. No capítulo 5, são apresentados os resultados iniciais dosprimeiros experimentos, que faz uma avaliação do funcionamento da plataforma e a viabilidadeda abordagem de mapeamento. E, no capítulo 6, finalmente, são apresentadas as conclusões etrabalhos futuros. E, por fim, são apresentadas as referências bibliográficas do trabalho.

272727

2CONCEITOS BÁSICOS

Neste capítulo, apresentamos o referencial teórico utilizado neste trabalho. Inicialmente,iremos caracterizar as plataformas MPSoC, as redes-em-chip (NoC), para, então, apresentarmosa definição do problema de mapeamento de tarefas para um MPSoC baseado em NoC.

2.1 PLATAFORMA MPSOC

Uma plataforma MPSoC é um SoC que apresenta mais de um núcleo de processamentoem um único chip. As plataformas MPSoC são a tendência nos projetos de sistemas embarcados,pois permitem atender à crescente demanda por desempenho. Um MPSoC, normalmente, écomposto de diversos componentes, como múltiplos PE (CPUs), módulos de hardware, memóriase um meio de interconexão no mesmo chip, como pode ser visto na Figura 2.1 (WOLF, 2004).

Figura 2.1 Plataforma MPSoC genérica

Fonte: O Autor (2014)

Para um MPSoC, a comunicação entre os componentes internos é dada através de ummeio de comunicação. Existem diferentes meios de interconexão, que podem ser utilizadosem uma plataforma MPSoC, como por exemplo: barramento, barramentos hierárquicos e redeintra-chip (NoC).

Em um MPSoC, o meio de interconexão tradicional é o barramento, devido a suasimplicidade e eficiência, mas as grandes limitações do barramento estão em sua escalabilidade

28

e na ausência de paralelismo, ou seja, em um MPSoC baseado em barramento só se permiteuma comunicação por vez (GUERRIER; GREINER, 2000). A Figura 2.2 apresenta um MPSoCbaseado em barramento simples.

Figura 2.2 Plataforma MPSoC baseada em barramento simples


Alguns projetistas utilizam hierarquia de barramento (barramentos hierárquicos) paraaumentar a escalabilidade de um MPSoC baseado em barramento. Mas, a utilização de hierarquiade barramento só aumenta a complexidade de implementação do MPSoC. Na Figura 2.3, éapresentado um MPSoC baseado em barramentos hierárquicos.

Figura 2.3 Plataforma MPSoC baseada em barramentos hierárquicos


Conforme já foi descrito, o MPSoC baseado em barramento apresenta algumas limitaçõesde escalabilidade que podem afetar o desempenho do sistema e, para solucionar esse problema,foi desenvolvido um modelo de interconexão para MPSoC chamado de rede intra-chip (NoC).Em uma plataforma MPSoC baseada em NoC, todos os componentes são interligados porum meio de comunicação simples e direto. Nesse meio de comunicação, os componentes daplataforma são interligados a um roteador, que é responsável por gerenciar todo o tráfego demaneira mais adequada, realizando a troca de informações de forma paralela e independente,totalmente diferente dos meios de comunicação baseados em barramentos. Essa plataformaMPSoC baseada em NoC é apresentada na Figura 2.4.

29

Figura 2.4 Plataforma MPSoC baseada em NoC


2.1.1 Fluxo Genérico do Projeto de uma Plataforma MPSoC

Um projeto de uma plataforma MPSoC permite a reutilização de componentes IP eespecificação da comunicação de forma estruturada. A Figura 2.5 mostra uma visão geral dofluxo de projeto de uma plataforma multicores baseada em NoC, e os passos necessários paraexplorar o espaço de projeto de uma aplicação especifica.

Figura 2.5 Fluxo Genérico do projeto de um MPSoC


Esse fluxo se inicia com as descrições dos componentes de hardware (PE e NoC) e dosoftware (aplicação). A descrição da aplicação pode ser feita em uma linguagem de programaçãode alto nível, como C/C++ e a descrição do hardware pode ser em uma linguagem de descrição dehardware, como VHDL, ou podemos também utilizar uma linguagem específica para descriçãode projeto de hardware e software, como SystemC, que permite descrever o hardware e software

de uma plataforma MPSoC. O passo seguinte, apresentado na Figura 2.5, é o mapeamento

30

das tarefas de uma aplicação ou de um conjunto de aplicações nos núcleos (PE) da plataforma.Já no terceiro passo, são feitas as configurações na NoC, como topologia, controle de fluxo,roteamento, etc. Na etapa de simulação, são extraídos os valores de consumo de energia,desempenho, latência, etc, para avaliar a qualidade do mapeamento das tarefas de uma aplicaçãoou de um conjunto de aplicações.

Em um projeto de plataforma, existem muitas restrições de projeto como redução doconsumo de energia, minimização da área do chip e maximização do desempenho. Como já foimencionado, o consumo de energia é muito importante, especialmente em projetos de sistemasembarcados que dependem do tempo de vida da bateria. E, em geral, a maioria dessas restriçõesde projeto podem ser conflitantes, como, por exemplo, minimizar o consumo de energia afetadiretamente o desempenho do sistema. Então, a questão principal em um projeto de plataformaMPSoC é encontrar o melhor compromisso entre as restrições de projeto. E uma das formas paraencontrar esse compromisso entre as restrições de projeto é utilizar o mapeamento de tarefas,que pode facilmente ser direcionado para uma ou mais restrições do projeto da plataforma, taiscomo, consumo de energia, área do chip e desempenho, ou, até mesmo, a combinação deles.

2.2 PLATAFORMA MPSOC BASEADA EM NOC

Uma plataforma MPSoC baseada em NoC é uma solução promissora que permite atenderà crescente exigência das aplicações complexas dos sistemas embarcados atuais. Esse tipo deplataforma é dividida em tiles, e cada tile contém um núcleo de IP, que pode ser um processador,um módulo de memória ou, até mesmo, uma plataforma com processador e memória local, e umroteador. A Figura 2.6 apresenta os principais componentes de um MPSoC baseado em NoCe também é possível visualizar nove tiles (0, 1, 2, 3, 4, 5, 6, 7 e 8) interligadas por meio deroteadores (R0, R1, R2, R3, R4, R5, R6, R7 e R8). O modelo de roteador ilustrado na Figura2.6 possui cinco portas bidirecionais conectadas a um núcleo crossbar, sendo uma das portasconectada a Network Interface Controller (NIC) (DALLY; TOWLES, 2004).

Dessa forma, uma plataforma MPSoC baseada em NoC pode solucionar alguns dosproblemas associados a uma plataforma baseada em barramento (modelo de plataforma tradicional)como escalabilidade e paralelismo. Em um MPSoC baseado em NoC, existe uma maior largurade banda nos enlaces, permitindo, assim, conectar mais núcleos IP na plataforma e comoexistem mais de um canal de comunicação é possível o tráfego de mensagens de forma paralela(menos colisões de mensagens na plataforma) e com isso um aumento do desempenho global daplataforma (HEMANI et al., 2000) (RIJPKEMA et al., 2003).

2.3 NETWORK-ON-CHIP (NoC)

Uma NoC é uma infraestrutura de comunicação em rede, constituída basicamente porroteadores e enlaces (links), e utilizada em chips. Os enlaces são utilizados para interconectar os

31

Figura 2.6 Principais componentes de uma Plataforma MPSoC baseada em NoC


roteadores entre si e aos núcleos IP de uma plataforma. Os núcleos IP são conectados ao roteadorpor meio de uma NIC. O modelo de comunicação geralmente utilizado por uma plataformasMPSoC baseada em NoC, é o baseado em troca de mensagens, ou seja, as comunicações entreos núcleos IP são feitas mediante o envio e recebimento de mensagens de requisição e resposta.Essas mensagens são geralmente divididas em unidades menores chamadas de pacote antes deserem transmitidas pela rede.

A NoC pode ser caracterizada pela sua topologia e por um conjunto de mecanismosque definem a forma como ocorrerá a transferência das mensagens pela rede (controle de fluxo,memorização, roteamento, arbitragem e chaveamento). Essas características têm um impactodireto no desempenho de uma NoC, e esse desempenho pode ser avaliado por meio de algumasmétricas, como a largura de banda, a vazão e a latência.

2.3.1 Arquitetura de uma NoC

A arquitetura de uma NoC é dividida em quatro camadas, sendo uma para cada componenteprincipal da NoC. A Figura 2.7 faz uma relação entre as camadas da arquitetura NoC e o modelode referência Open Systems Interconnection (OSI), além de apresentar o fluxo dos dados pormeio da NoC. A camada sistema da NoC engloba a plataforma (aplicação e arquitetura). Nessacamada a maior parte da rede permanece oculta. A camada interface de rede controla o fluxode dados e transmite as mensagens geradas pelo núcleo IP para o roteador da rede. A camadade rede é composta por roteadores e enlaces. É nessa camada que são definidas a topologiae o protocolo de comunicação entre os roteadores. Já a camada de enlace é responsável pelacodificação, sincronização e confiabilidade (BJERREGAARD; MAHADEVAN, 2006).

32

Figura 2.7 Fluxo dos dados através da NoC


2.3.1.1 Interface de rede (NIC)

Uma NIC é a unidade que realiza a comunicação de forma transparente entre o núcleo IPe a infraestrutura de comunicação (NoC), ou seja, adaptando sinais de sincronismo e dados esendo responsável por traduzir as solicitações dos núcleos IP para o formato da mensagem darede (DALLY; TOWLES, 2004). De uma forma geral, uma interface de rede pode ser estruturadaem um bloco de hardware com dois submódulos front-end e o back-end, conforme ilustrado naFigura 2.8.

Figura 2.8 Interface de rede NIC


O módulo front-end permite o reuso de núcleos IP, implementando um protocolo decomunicação. Na prática, esse módulo permite a compatibilidade com outros protocolos decomunicação existentes, tais como: Open Core Protocol (OCP), Virtual Component Interface

(VCI) entre outros. Como a camada de sessão do modelo OSI representa a interface da aplicaçãocom a rede, determinando o início da sessão, o tempo necessário e o fechamento da sessão, então,podemos concluir que o módulo front-end da interface de rede de uma plataforma MPSoC éuma implementação da camada de sessão do modelo OSI. Já o módulo back-end implementaos serviços de comunicação de alto nível da camada de transporte, tais como: transferênciasde dados confiáveis, sequenciais e orientadas à Quality of service (QoS). E os serviços de

33

transferência entre as interfaces de redes são representados na camada de rede e implementadosnos roteadores da NoC (BENINI; MICHELLI, 2006) (KUROSE; ROSS, 2009),

2.3.1.2 Roteador

Um roteador é responsável pela transmissão dos dados pela NoC e implementa osmecanismos de comunicação necessários para a transferência das mensagens pela rede. Essesmecanismos são constituídos por um conjunto de filas, multiplexadores, controladores e portasde entrada e saída para comunicação com outros roteadores e/ou núcleo IP. Essas portas deentrada e saída podem possuir buffer (memórias para armazenamento temporário) e aindacontroladores de enlace, que regulam o tráfego das informações no roteador (DALLY; TOWLES,2004) (ZEFERINO; SANTO; SUSIN, 2004).

2.3.1.3 Enlace

Um enlace é responsável por ligar um roteador a outro roteador ou a um núcleo IP.Tipicamente, os enlaces são full-duplex, sendo constituídos por dois canais unidirecionais opostos,sob a forma de um cabo elétrico. Por ser full-duplex, é possível transferir simultaneamentemensagens nas duas direções do enlace. Em outras palavras o enlace é responsável pelo transporte,enquadramento e regulação de tráfego de uma mensagem (ZEFERINO; SANTO; SUSIN, 2004).

2.3.1.4 Mensagens e pacotes

As mensagens trocadas entre os núcleos IP, em geral, possuem três partes: cabeçalho(header), carga útil (payload) e um terminador (trailer); o cabeçalho e o terminador envelopama carga útil, como pode ser visto na Figura 2.9. É no cabeçalho que são incluídas as informaçõesde roteamento e de controle que serão utilizadas pelos roteadores para transferir a mensagempela NoC. Já o terminador inclui a sinalização do final da mensagem e, ainda, pode incluirinformações usadas para a detecção de erros. Geralmente, as mensagens são quebradas empacotes antes de serem transmitidas. Um pacote é sempre constituído por uma sequência depalavras com largura igual a largura física do canal (n) e, em alguns casos, pode incluir sinais deenquadramento e de controle de integridade (ZEFERINO; SANTO; SUSIN, 2004).

2.3.2 Características Gerais de uma NoC

Uma NoC pode ser caracterizada por meios de diversos atributos, tais como: topologia eestratégias utilizadas para roteamento, chaveamento, controle de fluxo, arbitragem e memorização,conforme definido na Tabela 2.1 (ZEFERINO; SUSIN, 2003).

34

Figura 2.9 Formato de uma mensagem


Tabela 2.1 Características de uma NoCCaracterísticas DefiniçãoTopologia Define a conexão dos roteadores, ou seja, o layout físico e as conexões

entre os roteadores, e pode ser representada em forma de um grafo.Roteamento Define o caminho a ser utilizado por uma mensagem para atingir o seu

destino.Chaveamento Define como e quando um canal de entrada de um roteador é conectado

a um canal de saída que foi selecionado pelo mecanismo de roteamento.Controle de Trata da alocação dos recursos necessários para uma mensagem avançarfluxo pela NoC.Arbitragem Responsável por resolver conflitos internos da NoC, quando duas

ou mais mensagens competem por um mesmo recurso.Memorização Utilizada pelos roteadores para armazenar pacotes destinados a canais

de saída que estão ocupados (utilizados por outros pacotes).

2.3.2.1 Topologia

Uma NoC pode ser caracterizada pela forma como os seus roteadores são interligados.Essa forma de interligação é chamada de topologia, e a topologia pode ser representada por umgrafo G(R,E), onde cada vértice ri ∈ R representa um roteador na topologia da NoC e a arestaei j ∈ E representa o enlace que liga os roteadores ri e r j. As topologias de uma NoC podem serclassificadas em duas classes principais: as redes diretas e as redes indiretas.

Nas redes diretas, cada roteador possui um PE, e eles podem ser representados como umúnico elemento da rede, ou seja, cada elemento possui ligações diretas ponto a ponto para umdeterminado número de vizinhos e as mensagens trocadas entre dois elementos não vizinhosdevem passar por um ou mais elementos intermediários, mas toda essa comunicação só envolveos roteadores da rede. As topologias de redes diretas mais utilizadas são a malha 2D, a toroide2D, a hipercubo 3D e anel, exemplificadas na Figura 2.10. E, nas redes indiretas, os roteadoresnão são acoplados aos PE, nesse tipo de topologia, cada roteador possui um conjunto de portas

35

bidirecionais para ligações com outros roteadores e somente alguns roteadores possuem conexãocom os PE. A Figura 2.11 mostra duas redes indiretas: árvore e estrela (FERNANDEZ-ALONSOet al., 2012).

Figura 2.10 Rede direta: (a) malha 2D (b) toróide 2D (c) hipercubo 3D (d) anel


Figura 2.11 Rede indireta: (a) árvore (b) anel


36

2.3.2.2 Roteamento

O roteamento é o método usado para definir o caminho a ser utilizado por uma mensagempara atingir o seu destino. O desempenho da NoC está diretamente ligado ao algoritmo deroteamento utilizado, já que o roteamento visa atender a alguns objetivos específicos da NoC,como: capacidade de rotear pacotes de qualquer núcleo, capacidade de garantir que nenhumamensagem ficará bloqueada ou circulando pela rede sem atingir o destino, capacidade de rotearpacotes por meio de caminhos alternativos quando ocorrer congestionamento e capacidade derotear mensagens mesmo com falhas em algum componente da rede. Um exemplo de algoritmode roteamento geralmente utilizado em NoC é o algoritmo XY (BENINI; MICHELLI, 2006).

2.3.2.3 Chaveamento

O chaveamento é o mecanismo utilizado para determinar como uma mensagem étransferida da entrada de um roteador para uma de suas saídas. Os mecanismos de chaveamentopodem ser classificados em dois tipos principais de chaveamento: chaveamento por circuitoou chaveamento por pacote. O chaveamento por circuito é baseado no estabelecimento de umcaminho completo entre a origem e o destino, por onde a mensagem será enviada. Esse caminhosó será liberado depois que o terminador da mensagem passa pelo caminho (sinalizando queo recurso pode ser liberado). Já no chaveamento por pacote, nenhum caminho é reservadoentre a origem e o destino da mensagem; em vez disso, os pacotes são encaminhados para osroteadores, usando as informações contidas no pacote. Os roteadores que utilizam chaveamentopor pacote armazenam os pacotes antes de serem encaminhados para o próximo roteador.Existem alguns chaveamento por pacotes, como, por exemplo, Store-and-Forward (SAF), Virtual

Cut-Through (VCT) e Wormhole (FERNANDEZ-ALONSO et al., 2012).

2.3.2.4 Controle de fluxo

O mecanismo de controle de fluxo é responsável por tratar da alocação de canais e buffers

(recursos) necessários para uma mensagem avançar em direção ao seu destinatário. Essa alocaçãoé necessária para evitar a perda indesejada de dados enviados de um emissor a um receptor, jáque, em geral, uma NoC não descarta pacotes, ou seja, é uma rede lossless. O controle de fluxode uma NoC é feito em nível de enlace, e para cada roteador da rede deve existir um buffer parao armazenamento do dado que esta sendo transferido. Dessa forma, o mecanismo de controlede fluxo deve ser usado para bloquear a saída de dados do transmissor, e o receptor deve enviaruma informação de controle ao transmissor para informar que está pronto para receber novosdados. As técnicas básicas de controle de fluxo são: handshake, slack buffer, baseado em créditoe canais virtuais (JANTSCH; TENHUNEN, 2003).

37

2.3.2.5 Arbitragem

O mecanismo de arbitragem ao contrário do mecanismo de roteamento, que determinaqual canal de saída deve ser usado pela mensagem que entra no roteador, é responsável porresolver conflitos internos, quando duas ou mais mensagens competem pelo mesmo canal, ouseja, a arbitragem define qual canal de entrada poderá utilizar um determinado canal de saída(JANTSCH; TENHUNEN, 2003).

2.3.2.6 Memorização

O mecanismo de memorização deve ser utilizado por todos os roteadores com chaveamentopor pacote, pois eles devem ser capazes de armazenar as mensagens destinadas a uma saída que,por algum motivo, já está sendo utilizada por outra mensagem e, então, devem aguardar pelaliberação da saída para evitar a perda de dados recebidos (JANTSCH; TENHUNEN, 2003).

2.4 MAPEAMENTO DE TAREFAS EM UMA PLATAFORMAMPSOC

O mapeamento de tarefas ou alocação de tarefas é semelhante ao problema de atribuiçãoquadrática e como já foi dito, é um problema computacionalmente difícil (NP-hard). Dessa forma,encontrar uma solução ótima que satisfaça todas as restrições é muito difícil e demorado, masque pode ser resolvido, utilizando abordagens heurísticas para encontrar uma solução quase ideal.(MARCULESCU et al., 2009) (SAHU; CHATTOPADHYAY, 2013). Para o mapeamento depoucas tarefas, podem ser utilizados métodos determinísticos para encontrar uma solução ótima,mas, à medida que aumenta o número de tarefas a serem mapeadas, fica inviável analisarem-setodos os casos (SINGH et al., 2013). O problema de mapeamento de tarefas pode ser divididoem duas classes: mapeamento estático e mapeamento dinâmico.

O mapeamento estático é realizado em tempo de projeto (off-line), ou seja, antes daexecução da aplicação. Ele utiliza as informações da infraestrutura de comunicação e da aplicaçãopara escolher o mapeamento das tarefas. E o mapeamento dinâmico (on-line) atribui as tarefasdurante a execução da aplicação (tempo de execução). Esse tipo de mapeamento sempre tentadetectar um gargalo e busca distribuir a carga de trabalho entre os núcleos da plataforma e, comisso, encontrar a melhor solução.

Para plataformas MPSoC, o mapeamento estático é geralmente recomendado já queo mapeamento dinâmico gera uma sobrecarga de comunicação que afeta significativamenteo desempenho da plataforma, aumentando o atraso da aplicação e o consumo de energia daplataforma (SAHU; CHATTOPADHYAY, 2013).

O problema de mapeamento de tarefas em uma plataforma MPSoC visa mapear astarefas de uma aplicação em diferentes núcleos de um MPSoC, otimizando certos parâmetros da

38

plataforma, como, por exemplo: latência, largura de banda, consumo de energia, etc. A Figura2.12 apresenta o mapeamento das tarefas de uma aplicação em plataforma MPSoC baseada emNoC (WANG et al., 2011) (SINGH et al., 2013).

Figura 2.12 Mapeamento de tarefas em uma plataforma MPSoC


Para solucionar o problema de mapeamento de tarefas em uma plataforma MPSoC,é necessário modelar a especificação da aplicação e a especificação da plataforma. Essasmodelagens são definidas por meio de um grafo, onde o modelo da especificação da aplicaçãorepresenta as tarefas e suas respectivas comunicações, e o modelo da especificação da plataformarepresenta as características da plataforma.

2.4.1 Modelo da Aplicação

O modelo da aplicação é geralmente especificado como um grafo acíclico dirigidoGCT (T,C), que representa a forma como as tarefas de uma aplicação se comunicam, onde cadavértice ti ∈ T representa uma tarefa da aplicação, e cada aresta ci j ∈C, representa a comunicaçãoentre ti e t j com o volume da comunicação associado à aresta ci j. A Figura 2.13 apresenta umexemplo de um modelo de uma aplicação especifica com oito tarefas comunicantes.

2.4.2 Modelo da Plataforma

O modelo da plataforma é geralmente especificado como um grafo GCP(N,D), querepresenta a topologia da plataforma, onde cada vértice n ∈ N representa um tile na topologia e aaresta di j ∈ D representa a distância em hops entre os vértices ni e n j. A Figura 2.14 apresentaum exemplo de um modelo de plataforma de tamanho 2x2.

39

Figura 2.13 Modelo de uma aplicação


Figura 2.14 Modelo de uma plataforma MPSoC 2x2


2.4.3 Definição do Problema

O objetivo deste trabalho é reduzir o consumo de energia de uma plataforma por meiodo problema de mapeamento de tarefas, que ajuda a minimizar a quantidade de comunicaçãoentre os tiles de uma plataforma MPSoC baseada em NoC, e a redução da comunicação visaeconomizar a energia dinâmica gasta pelos elementos da NoC.

A energia dinâmica de um roteador da NoC é calculada levando em consideração aatividade de chaveamento dos seus componentes, ou seja, é calculada quando os bits mudam devalor de um ciclo para o outro. E com base nessa definição é possível formular um modelo deenergia dinâmica dos roteadores de uma plataforma, usando a definição da energia de bit (Ebit).

A Ebit é a energia consumida quando um bit de dados é transferido por meio da NoC e écalculado levando em consideração a energia consumida pelos roteadores (ER), pelos buffers

(EB) e pelos enlaces (EL). Dessa forma, a energia consumida para transferir um bit de dados deum tile da plataforma para outra, com d roteadores no caminho, pode ser calculada da seguinte

40

forma:

E i jbit = d× (ER +EB)+(d +1)×EL

� �2.1

Dado o modelo da aplicação (GCT (T,C)), o modelo da plataforma (GCP(N,D)) e omodelo de energia para avaliar a qualidade do mapeamento das tarefas, é possível formular oproblema em uma função map : T → N, tal que ∀ ti ∈ T,∃ n j ∈ N e map(ti) = N j, ou seja, ummapeamento do grafo GCT (T,C) no grafo GCP(N,D), de forma a reduzir o consumo de energia.E esse mapeamento só pode ser realizado se |T | ≤ |N|, onde |T | é o número total de tarefas e |N|é o número total de tiles da plataforma MPSoC. Um possível exemplo de função objetivo quepode minimizar o consumo de energia de comunicação é apresentado na Equação 2.2

min∑i

∑j

E i jbit

� �2.2

2.5 A PLATAFORMA MPSOC INFINITY

A plataforma Infinity é uma plataforma MPSoC baseada em NoC desenvolvida emSystemC e que simula o comportamento de um sistema embarcado distribuído, onde os seuselementos são implementados em nível Transaction-level modeling (TLM) e a NoC em nívelRegister Transfer Level (RTL). A NoC foi implementada em RTL para garantir a extração dosdados de potência dissipada com maior precisão. A potência dissipada pela NoC é estimadausando a ferramenta PowerPlay Power Analyzer, que vem acoplada ao software Quartus II. Pormeio da ferramenta PowerPlay Powe Analyzer, é possível obter uma estimativa bastante precisado consumo de potência de um projeto em nível RTL.

2.5.1 Descrição da Plataforma Infinity

A Plataforma Infinity é composta por n x n tiles homogêneas interconectadas por meiodos roteadores da NoC SoC Interconnection Network (SoCIN) (ZEFERINO; SUSIN, 2003). ANoC SoCIN foi escolhida principalmente devido à disponibilidade da descrição em VHDL eSystemC.

Cada tile da Infinity possui os seguintes componentes: núcleo Infinity (processadorScalable Processor Architecture (SPARC), interface de rede, dois níveis de cache, mecanismo decoerência de cache baseado em diretório, banco de memória e dois barramentos exclusivos decomunicação) e roteador. A Figura 2.15 apresenta a arquitetura de uma plataforma Infinity com2x2 tiles e a estrutura interna do núcleo Infinity.

41

Figura 2.15 Plataforma Infinity


2.5.1.1 Núcleo infinity

O núcleo Infinity representa o PE da plataforma Infinity; é um processador de arquiteturaReduced Instruction-Set Computer (RISC) de 32 bits, de arquitetura aberta, desenvolvida pelaSun Microsystem, e que possui uma vasta gama de ferramentas disponíveis, como, por exemplo,o compilador C (GNU Compiler Collection (GCC)), que facilita a compilação de aplicações. Onúcleo Infinity apresenta as seguintes características:

(i) Arquitetura de comunicação independente entre os núcleos, ou seja, suporta todas asarquiteturas de NoC ou barramentos;

(ii) Interrupções independentes por núcleo, por meio de um barramento exclusivo parainterrupção, com suporte a interrupções entre os núcleos. Cada núcleo possui um Local

Advanced PIC (LAPIC), com 16 registradores de prioridade e registador de máscara,ligado ao I/O Advanced PIC. Com essa configuração, é possível ter habilitação de IRQindividual para cada LAPIC;

(iii) Suporte a periféricos, por meio de um barramento de periféricos conectado direto aonúcleo, e um I/O Advanced PIC como o controlador central de interrupções;

(iv) Suporte a sistemas operacionais, com região crítica (lock) por hardware e gerenciamentode memória;

42

(v) Novas Instruções de Load e Store. As instruções foram modificadas para que elas possamsalvar o estado da cache após a leitura ou escrita do dado;

(vi) O modelo de coerência de cache baseada em diretório; esse modelo foi desenvolvido combase no modelo descrito por HENNESSY; PATTERSON (2012).

2.5.1.2 Interface de rede (NIC)

A interface de rede da plataforma Infinity foi desenvolvida para realizar a comunicaçãoentre os núcleos Infinity e os roteadores da rede SoCIN. A Figura 2.17 ilustra a arquitetura dainterface de rede da plataforma Infinity, que possui dois submódulos: front-end (nível TLM) eback-end (nível RTL).

O front-end implementa um protocolo de comunicação baseado em transações e éresponsável por iniciar as transações emitindo requisições que, posteriormente, podem serseparadas em transações de serviços e transações de dados. Dessa forma, o front-end podeser visto como uma implementação da camada de sessão do modelo de referência OSI, ondea camada de sessão representa a interface do usuário com a rede, determinando quando umasessão é aberta, o tempo necessário e quando deverá ser fechada. Já o back-end implementa ascamadas de transporte, rede, enlace e física, conforme ilustrado na Figura 2.16. O back-end éresponsável por manter o fluxo controlado da chegada dos dados provenientes de um núcleo daplataforma (BENINI; MICHELLI, 2006).

Figura 2.16 Visão Estrutural de uma Interface de Rede no Modelo OSI


Resumidamente, podemos afirmar que a interface de rede da plataforma Infinity (Figura2.17) é responsável por enviar mensagens, do controlador da cache, para a NoC, e receber ospacotes da NoC e montar a mensagem antes de enviar para o controlador da cache. As threads

43

CacheIN e DirectoryIN são responsáveis por segmentar as mensagens de 136 bits, enviadas pelocontrolador de cache, em pacotes de 34 bits, e para garantir o controle de fluxo foi implementadoo Traffic Merger. Já a thread SoCIN tem a responsabilidade de montar a mensagem antes deenviar para o controlador da cache.

Figura 2.17 Organização da interface de rede


2.5.1.3 Modelo de mensagens

As mensagens, que trafegam na plataforma Infinity, são mensagens de coerência decache, e essas mensagem devem ser quebradas em pacotes, chamados de (flits), como já foimencionado, antes de ser enviado para a NoC. Essas mensagens são constituídas da seguinteforma: < service >< serviceparameters >, onde service é o serviço de coerência de cachesolicitado e serviceparameters são os parâmetros necessários para o serviço. Esses parâmetrospodem ser:

(i) Source component: É o componente do controlador da cache, que está enviando amensagem, que pode ser a Cache L1;

(ii) Destination component: É o componente do controlador (Cache L1 ou Diretório), que iráreceber a mensagem;

(iii) Address: É o endereço físico do dado;

44

(iv) Data: É o dado propriamente dito;

(v) Owner: É o endereço de rede do dono do dado;

(vi) Shared number: Informa em quantos núcleos o dado está compartilhado.

Os serviços implementados na plataforma Infinity devem refletir a ação a ser tomada pelocontrolador da cache depois de ter recebido as mensagens. Os serviços implementados e quepodem ser transportados em um pacote de rede são mostrados juntamente com o seu código naTabela 2.2.

Tabela 2.2 Descrição dos serviços que um pacote de rede pode carregaServiços CódigoError 0000Get shared 0001Get modified 0010Invalidate 0011Invalidate ack 0100Invalidate started 0101Put modified 0110Put modified and shared 0111Put modified ack 1000Forward get shared 1001Forward get modified 1010Data 1011Unknow message 1100

2.5.1.4 Formato da mensagem

Para oferecer os serviços previstos pela plataforma Infinity foram realizadas modificaçõesno formato da mensagem da rede SoCIN, com o objetivo de oferecer suporte aos serviçosprevistos pela plataforma. A nova estrutura da mensagem apresenta uma extensão do cabeçalhopor meio de um bit ((header extension) para informar se o próximo flit é uma continuação docabeçalho. Essa funcionalidade foi incluida para suportar a inclusão de novos serviços.

A Figura 2.18 ilustra o novo formato da mensagem, onde podemos visualizar os flow

control unit (flit) (pacotes) enviados para a NoC. Em cada flit, existem dois bits de propósitoespecífico (Begin of Packet (BOP) e End of Packet (BOP)), que são utilizados para sinalizaro início da mensagem (cabeçalho), a carga útil (payload) e o fim da mensagem (trailer). Épossível também visualizar que o início da mensagem é constituída pelo cabeçalho, que pode serconstituido por um ou mais flit, devido ao bit específico (header extension), que é responsávelpor informar se o próximo flit ainda faz parte do cabeçalho. No cabeçalho, constam os seguintesdados: High Level Protocol (HLP), Routing Information Bits (RIB), o código do serviço

45

Figura 2.18 Estrutura da mensagem da plataforma Infinity


solicitado pelo mecanismo de coerência de cache e os parâmetros do serviço (Source component,Destination component, Owner e Shared number).

O HLP é utilizado em níveis acima da camada de rede e o RIB são informações para oroteamento, como coordenadas x e y da origem da mensagem e do destinatário da mensagem. Osúltimos dois pacotes da mensagem (payload e trailer) são utilizados pelos parâmetros Address eData respectivamente.

A Plataforma Infinity não foi desenvolvida neste trabalho. Mas este trabalho contribuiupara a Plataforma Infinity no que refere-se, principalmente, à integração dos núcleos da Infinity àrede SoCIN, desenvolvendo uma interface de rede, que é responsável pelo envio e recebimentodas mensagens de coerência da cache, e para viabilizar o funcionamento da técnica proposta,também foi implementado, dentro das interfaces de rede, um monitor responsável por monitoraros pacotes (mensagens) que passam pelas interfaces.

464646

3TRABALHOS RELACIONADOS

Neste capítulo, são apresentados os trabalhos relacionados que buscam reduzir a energiade comunicação de uma plataforma MPSoC, em tempo de projeto, por meio do problema demapeamento de tarefas. Para facilitar a leitura, os trabalhos estudados serão apresentados emordem cronológica de publicação e classificados conforme a técnica utilizada para encontrar asolução. As técnicas podem ser classificadas como exata ou baseada em busca.

3.1 BASEADOS EM TÉCNICAS EXATAS

Os trabalhos que utilizam técnicas exatas para minimizar a energia de uma plataformaMPSoC geralmente utilizam Integer Linear Programming (ILP) ou Mixed Integer Linear

Program (MILP). Alguns dos trabalhos que utilizam ILP para otimizar a energia, buscamtambém minimizar a energia de comunicação por meio do problema de gerenciamento deenergia dos enlaces da NoC (rede), ou seja, usam a ILP para desligar determinados enlaces decomunicação e/ou para selecionar tensão e frequência de operação dos enlaces utilizados pelaplataforma.

3.1.1 Uma Abordagem Exata para Alocar e Escalonar Tarefas

RUGIERO et al. (2006), neste trabalho, apresentaram uma abordagem exata para alocare escalonar tarefas em uma plataforma MPSoC mediante a decomposição do problema em doissubproblemas ou etapas, criando, assim, uma abordagem híbrida. Os subproblemas ou etapassão: alocação de tarefas em processadores e escalonamento de tarefas.

3.1.1.1 Etapa de alocação de tarefas

Durante essa etapa, é feita a alocação de n tarefas da aplicação em m processadoresda plataforma, de modo que a quantidade total de memória alocada para as tarefas em cadaprocessador não exceda o tamanho da memória local. Mas, para aplicações com dados extremamente

47

grandes, a abordagem proposta possui um controlador de memória que permite o aumento docusto de acesso às memórias remotas.

A função objetivo desse subproblema é minimizar a quantidade total de dados transferidospelo barramento. E, para solucionar este problema de alocação de tarefas, os autores utilizaramuma técnica de programação inteira com quatro variáveis de decisão, que são apresentadas naTabela 3.1.

Tabela 3.1 Variáveis utilizadas no subproblema de alocação de tarefasVariáveis ExplicaçãoTi j Variável inteira que recebe o valor 1 se a tarefa i é executada no processador j,

e 0 caso contrárioYi j Variável inteira que recebe o valor 1 se a tarefa i aloca os dados do programa

na memória local do processador j, e 0 caso contrárioZi j Variável inteira que recebe o valor 1 se a tarefa i aloca o estado interno na

memória local do processador j, e 0 caso contrárioXi j Variável inteira que recebe o valor 1 se a tarefa i é executada no processador j

e a tarefa i+1 não, e 0 caso contrário

Usando a definição das variáveis descritas na Tabela 3.1, a função objetivo do subproblemaé descrita na Equação 3.1

minn

∑i=1

m

∑j=1

(Memi(Ti j−Yi j)+2Statei(Ti j−Zi j)+(DataiXi j)/2)� �3.1

onde Memi, Statei e Datai são coeficientes que representam a quantidade de dado usadopela tarefa i para armazenar respectivamente o dado do programa, o estado interno e a fila decomunicação.

As restrições para o subproblema são as seguintes: cada tarefa só pode ser executada emum processador e impedir a alocação de um conjunto consecutivo de tarefas onde a soma dotempo de execução não exceda o tempo real requerido para o processador.

3.1.1.2 Etapa de escalonamento de tarefas

O objetivo desta etapa é solucionar o subproblema de escalonamento das tarefas alocadasem cada processador, em outras palavras, será definida a ordem de execução das tarefas.RUGIERO et al. (2006) dividiram cada tarefa da aplicação em diferentes atividades, que sãodescritas na Tabela 3.2.

As restrições introduzidas no modelo são as seguintes: cada tarefa só pode começar a lera fila de comunicação apenas após o final da sua iteração anterior (Equação 3.2); cada tarefa develer a fila de comunicação, pouco antes da execução, ou se existe, antes de ler o estado interno(Equações 3.2 e 3.4), cada tarefa pode ler os dados da fila de comunicação apenas quando a tarefaanterior gerar a fila (Equação 3.5); cada tarefa deve ler o estado interno pouco antes da execuçãoe escrevê-lo apenas depois (Equações 3.6 e 3.7); uma tarefa pode ler a fila de comunicação

48

Tabela 3.2 Atividades de uma tarefa da aplicaçãoAtividades ExplicaçãoAi j Atividade computacionalIni j Atividades de entrada de dados de leituraRSi j Atividade de leitura do estado internoWSi j Atividade de escrita do estado interno

apenas se a tarefa seguinte estiver pronta para ler (Equação 3.8) e as iterações de cada tarefadevem ser executadas em ordem (Equação 3.9).

Ai( j−1) ≺ Ini j,∀i, j� �3.2

Ini j � Ai j,∀i, j� �3.3

Ini j � RSi j,∀i, j� �3.4

A(i−1) j ≺ Ini j,∀i, j� �3.5

RSi j � Ai j,∀i, j� �3.6

Ai j �WSi j,∀i, j� �3.7

A(i+1)( j−1) ≺ Ini j,∀i, j� �3.8

Ai( j−1) ≺ Ai j,∀i, j� �3.9

A plataforma MPSoC usada nos experimentos realizados pelo autores, utiliza memóriadistribuída com troca de mensagens e com todos os processadores iguais (homogêneos) e cominfraestrutura de comunicação baseada em barramento. Cada elemento de processamento daplataforma consiste de um processador Acorn RISC Machine (ARM), que inclui cache deinstrução e dados e, para a comunicação entre os elementos de processamento, a plataformautiliza um barramento Advanced Microcontroler Bus Architecture (AMBA). A plataformautilizada ainda apresenta suporte ao sistema operacional de tempo real Real-Time Executive for

Multiprocessor Systems (RTEMS) além de um conjunto de Application Programming Interface

(API) de alto nível, que garante o acesso as memórias remotas e ao desenvolvimento de aplicaçõescom suporte a troca de mensagens. Essa abordagem proposta por RUGIERO et al. (2006)funciona de maneira que as soluções de cada etapa ou subproblemas interagem uma com a outra,

49

convergindo para uma boa solução e atendendo assim ao objetivo geral do trabalho, que é reduziro tráfego no barramento.

Para validar as etapas de alocação e escalonamento de tarefas, os autores utilizamaplicações sintéticas. Segundo os autores, é possível fazer alterações nos parâmetros dasaplicações sintéticas (tamanho da memória local, tempos de execução, tamanho dos dados, etc)para encontrar uma solução ideal (prevista). Fazendo esses ajustes, os autores mostraram que aabordagem proposta tem um nível de precisão alto, ou seja, a diferença média entre os valoresmedidos e o previstos é 4,7%, com um desvio padrão de 0,08. E para provar a viabilidade daproposta, os autores utilizam a aplicação Global System for Mobile Communications (GSM).Esse experimento com o GSM apresentou um rendimento de 4,1%.

Mesmo apresentando resultados próximos da solução prevista, essa abordagem aindaapresenta uma limitação com relação à plataforma MPSoC, que utiliza barramento comoinfraestrutura de comunicação. Outro ponto que não ficou claro, mesmo a abordagem conseguindoresolver o problema de escalonamento, é se é possível modelar o problema para permitirflexibilizar o uso dos recursos, ou seja, se é possível minimizar o uso de processadores para umaaplicação especifica.

3.1.2 Uma Formulação MILP para o Mapeamento de Tarefas

Neste trabalho, GHOSH; SEN; HALL (2009) apresentam uma técnica que buscaminimizar o consumo de energia de uma plataforma MPSoC heterogênea por meio do mapeamentodas tarefas da aplicação e também selecionando vários níveis de voltagem de operação. Osautores propuseram a utilização de uma técnica de programação matemática para resolver oproblema de mapeamento da aplicação. Os autores formularam o problema utilizando umaformulação MILP para minimizar o consumo de energia de uma plataforma baseada em NoC. Odestaque dessa abordagem, está relacionado ao fato de que os autores buscaram unificar em umaúnica formulação quatro problemas de otimização para minimizar a energia de uma plataformaMPSoC. Os problemas modelados na formulação MILP são:

(i) Mapeamento de tarefas em PE;

(ii) Mapeamento de PE em roteadores;

(iii) Atribuição do nível de tensão ao PE;

(iv) Mapeamento das arestas na NoC.

Para modelar tais problemas na formulação MILP GHOSH; SEN; HALL (2009), utilizamuma função para cada problema. Essas funções são descritas e explicadas na Tabela 3.3, e naTabela 3.4 são explicadas as entradas do problema e as variáveis da formulação MILP.

A função objetivo utilizada na abordagem proposta por GHOSH; SEN; HALL (2009) éapresentada na Equação 3.10.

50

Tabela 3.3 Funções modeladas por GHOSH; SEN; HALL (2009)Funções ExplicaçãoM1(ti) = p j Significa que a tarefa ti deve ser mapeada para o PE p jM2(pi) = r j Significa que o PE pi deve ser mapeada para o roteador r jM3(pi) = v j Significa que para o PE pi deve ser atribuído um nível de tensão v jM4(ti, tx) Se eix ∈ ET ,M1(ti) = p j,M2(p j) = rk e M1(tx) = py,M2(py) = rz, então

M4(ti, tx) = rk −→ rπ(1) −→ rπ(2) −→ ...−→ rz, onde{r1,rπ(1)},{rπ(1),rz},{rπ(q),rπ(q+1)} ∈ ER

Tabela 3.4 Variáveis utilizadas por GHOSH; SEN; HALL (2009)Variáveis ExplicaçãoG(VT ,ET ) Grafo de tarefas, onde cada vértice ti ∈VT representa uma tarefa e

cada aresta ei j = (ti, t j) ∈ ET representa a dependência entre as tarefa t j e tiGR(VR,ER) Grafo da arquitetura NoC, onde cada vértice ri ∈VR representa um roteador e

cada aresta ei j = (ri,r j) ∈ ER representa o enlace entre os roteadores ri e r jwi j Representa o volume de comunicação (em Mbps) entre as tarefas ti e t jD Deadline da aplicaçãok Número máximo de ilhas de tensão criadasP O conjunto de PE P = {p1, p2, ..., pk}Pt ⊆ P Conjunto de PE que pode executar a tarefa tVp Conjunto de níveis de tensão que o PE p ∈ P pode operarτt pv Tempo de execução da tarefa t ∈VT sobre o PE p ∈ Pt com nível de tensão v ∈Vpεt pv Consumo de energia da tarefa t ∈VT sobre o PE com nível de tensão v ∈V pψi Consumo de energia da taxa de comunicação nas portas de entrada do roteadorψo Consumo de energia da taxa de comunicação nas portas de saída do roteadorψl Consumo de energia da taxa de comunicação nos enlaces do roteadorLi j Tamanho da aresta ei j ∈ ERαv1v2 Consumo de energia da transição de tensão entre dois PE operando com v1 e v2ς v

t p Se t ∈VT , p ∈ Pt ⊆ P,v ∈Vp e M1(t) = p e M3(p) = v então ς vt p = 1 senão ς v

t p = 0ζrv Se r ∈VR operando com tensão v então ζrv = 1 senão ζrv = 0f i jxy Se ei j ∈ ET ,exy ∈ ER e exy ∈M4(ei j então f i j

xy = 1 senão f i jxy = 0

minE = Ec +Er +El +Evt� �3.10

onde Ec é a energia consumida na computação, Er e El são as energias consumidas nosroteadores e nos enlaces respectivamente e Evt é a energia consumida na transação da tensão, esão calculadas como:

Ec = ∑t∈VT

∑p∈Pt

∑v∈V p

(ς vt pεt pv)

� �3.11

Er = ∑∀exy∈ER

∑∀ei j∈ET

( f i jxywi j)(ψi +ψo)

� �3.12

51

El = ∑∀exy∈ER

∑∀ei j∈ET

(( f i jxywi j)Lxy)ψl

� �3.13

Evt = ∑v1∈V

∑v2∈V

∑∀exy∈ER

(ζxv1ζyv2)αv1v2

� �3.14

Para validar a formulação proposta, os autores utilizaram as aplicações do Embedded

System Synthesis Benchmarks Suite (E3S) e mais três aplicações reais (Moving Picture Experts

Group (MPEG), Multi-Window Display (MWD) e Object Plane Decoder (OPD)). Os testesforam realizados utilizando seis cenários de teste, e para cada cenário foi usado um nível detensão diferente. E para os experimentos com a aplicação industrial do E3S a plataforma foiconfigurada com uma rede de tamanho 4x4 e para as outras três aplicações do E3S com tamanho3x3. Já para os experimentos com as aplicações reais, a plataforma foi configurada da seguinteforma: 3x3 para as aplicações MPEG-4 e MWD e 4x4 para a aplicação OPD.

Em média, essa abordagem produz soluções boas para minimizar o consumo de energiade uma plataforma MPSoC, para as quatro aplicações do E3S (indústria, consumo, rede eautomação de escritório), conseguindo economizar 18% do consumo de energia. E para as trêsaplicações reais (MPEG-4, MWD e OPD), a abordagem MILP proposta por GHOSH; SEN;HALL (2009) consegue economizar na média 11% do consumo de energia.

Em geral essa abordagem demonstrou certa eficiência em minimizar a energia consumidade uma plataforma MPSoC por meio de uma abordagem que unifica em uma única formulaçãoquatro problemas de otimização. Mesmo com tal eficiência, a abordagem proposta utiliza umroteamento estático e fixo, ou seja, não apresenta possibilidade de flexibilidade de roteamento.Outra coisa que a abordagem não modela é a possibilidade de minimizar o uso de recursos(processadores).

3.1.3 Uma Heurística para Alocação de Tarefas

Os autores desta heurística, inicialmente, estenderam uma formulação ILP que minimizaa energia consumida pelo processador, por meio do problema de mapeamento, para umaformulação ILP que encontra um trade-off entre a energia consumida pela computação ecomunicação, ou seja, um função objetivo para minimizar a soma da energia consumida pelosprocessadores e pela NoC (HUANG et al., 2011).

O objetivo deste trabalho é minimizar o consumo de energia em nível de sistemas, comomostra a função objetivo apresentada na Equação 3.15

minE = Ep +Ec� �3.15

onde Ep é a energia consumida pelo processador e Ec é a energia consumida pelacomunicação. Essas energias são calculadas conforme as Equações 3.16 e 3.17 respectivamente.

52

Ep = ∑ti∈T

∑pm∈P

xi,mEi,m� �3.16

Ec = ∑e∈E

∑pm∈P

∑pn∈P

εWeDm,nxsrc(e),mxtgt(e),n

� �3.17

As variáveis utilizadas na formulação são explicadas na Tabela 3.5.

Tabela 3.5 Variáveis da formulação ILP proposta por HUANG et al. (2011)Variáveis ExplicaçãoP Conjunto de processadoresT Conjunto de tarefas da aplicaçãoxi,m Representa se a tarefa ti ∈ T está alocada ao processador pm ∈ Ppi, j Denota a prioridade de execução entre as tarefas ti e t j,Ei,m Denota a energia necessária para executar a tarefa ti no processador pmWe Representa o tamanho do token na aresta eDm,n Representa a distância entre o processador pm e pnε Quantidade de energia necessária para transferir um token ao longo de um caminho

Segundo os autores, a técnica Dynamic Voltage Scaling (DVS), que atribui tensãodinamicamente aos processadores, pode ser facilmente incorporado ao modelo ILP, propostopelos autores, mas, como a complexidade computacional de um modelo ILP cresce rapidamenteà medida que aumenta no número de variáveis, eles resolveram propor uma abordagem heurísticabaseada em Simulated Annealing (SA) para acelerar o processo de mapeamento de tarefas. Essaaceleração do mapeamento foi possível mediante de uma abordagem baseada em um SA comajuste de tempo (Simulated Annealing with Timing Adjustment (SA-TA)), sendo o objetivo dessaheurística explorar o espaço de busca perto de um mapeamento viável e assim possa minimizar aenergia do processador e da NoC, em outra palavras, tentar explorar o espaço de busca próximode um mapeamento aceitável para que seja possível encontrar um mapeamento que minimize aenergia global. Essa função objetivo é apresentada na Equação 3.15.

Para comparar os resultados, HUANG et al. (2011) utilizaram três abordagens: somenteo SA para encontrar um mapeamento alternativo, SA-TA com um mapeamento aleatório comoponto de partida e SA-TA com um mapeamento viável como ponto de partida. Os resultadosforam comparados com a solução encontrada por uma formulação ILP.

Para avaliar o desempenho da heurística, as aplicações foram geradas pelo Traffic Graphs

for Free (TGFF), que gera grafos de tarefas, e, ao todo, foram utilizados dez grafos de tarefascom 10 a 20 tarefas. A plataforma MPSoC utilizada nos experimentos foi configurada com umarede de tamanho 3x3.

Os números apresentados pelos autores mostraram um resultado médio quando se aplicamalguns ajustes de configuração, tipo o aumento de passos; a heurística mostra um desempenhobem próximo do ótimo global, ou seja, com um erro de menos de 5% em relação ao ótimo global,mostrando um desempenho interessante em comparação com a abordagem ILP.

53

Mesmo com esses resultados, os autores poderiam ter incorporado a heurística SA-TAuma técnica para minimizar os recursos da plataforma e/ou, até mesmo, ter modelado a técnicaDVS para tentar reduzir ainda mais a energia consumida pela plataforma. Em geral, essaabordagem mostrou um desempenho interessante em comparação com a abordagem ILP.

Com o estudo deste trabalho, é possível concluir que existe uma vantagem em utilizaruma abordagem heurística para minimizar a energia de uma plataforma através do problema demapeamento„ já que a complexidade computacional de um modelo ILP é fatorial ao tamanho daplataforma (número de PE)

3.2 MAPEAMENTO BASEADO EM BUSCA

Os trabalhos que utilizam a técnica de mapeamento baseado em busca para minimizar aenergia em plataforma MPSoC, geralmente, utilizam algoritmos determinísticos (branch-and-

bound) ou heurísticas transformadoras (que transforma algumas das soluções existentes doproblema para tentar chegar a uma solução melhor). As heurísticas transformadoras, geralmente,utilizam técnicas evolutivas, tais como, Genetic Algorithm (GA), Particle Swarm Optimization

(PSO), Ant Colony Optimization (ACO) entre outras (SAHU; CHATTOPADHYAY, 2013).

3.2.1 Um Algoritmo Branch-and-Bound para o Mapeamento de Tarefas

HU; MARCULESCU (2005) propõem uma abordagem baseada no algoritmo branch-

and-bound. O algoritmo branch-and-bound é um algoritmo determinístico que busca umasolução mediante uma pesquisa em árvore, árvore essa que representa o espaço de soluções.

Os objetivos da abordagem proposta por HU; MARCULESCU (2005) são mapear cadaIP na plataforma MPSoC e decidir como os pacotes de comunicação devem ser encaminhadospela NoC, de tal forma que o consumo total de energia seja minimizado com restrições dedesempenho. Os autores utilizaram como restrição de desempenho a largura de banda.

Para formular o problema, os autores precisaram definir dois grafos: um grafo decaracterística da aplicação G(C,A), onde cada vértice ci ∈C representa uma tarefa em um IP ecada aresta ai j ∈ A caracteriza a comunicação de ci para c j, onde as propriedades de cada arestaai j são apresentadas na Tabela 3.6. E um grafo de característica da plataforma (arquitetura)G(T,R), onde cada vértice ti ∈ T representa um tile da plataforma, e cada aresta ri j representa oparâmetro de roteamento de ti para t j, e as propriedades de cada aresta ri j são apresentada naTabela 3.7.

Tabela 3.6 Propriedades da aresta ai j do grafo de características da aplicaçãoPropriedade Descriçãov(ai j) Volume de comunicação (bits) do vértice ci para o vértice c jb(ai j) Largura de banda requerida do vértice ci para o vértice c j

54

Tabela 3.7 Propriedades da aresta ri j do grafo de características da plataformaPropriedade DescriçãoPi j Conjunto de caminhos candidatos do tile ti para a tile t j. ∀pi j ∈ Pi j,

L(pi j) dado o conjunto de enlaces usados por pi je(ri j) Representa o consumo médio de energia para enviar um bit de dado do tile ti

para o tile t j (Custo)

Usando essas definições, os autores formularam o problema de mapeamento eficiente deenergia e desempenho e a alocação de caminho de roteamento sobre a restrição de desempenho.A função objetivo é apresentada na Equação 3.18, onde dados os grafos G(C,A) e G(T,R)

encontra um mapeamento (map()) do G(C,A) para o G(T,R) e uma função de roteamentomínimo (R()).

minE = ∑∀ai j

v(ai j)e(rmap(ci),map(c j))� �3.18

tal que:

∀ci ∈C,map(ci) ∈ T� �3.19

∀ci 6= c j ∈C,map(ci) 6= map(c j)� �3.20

∀lk,B(lk)≥ ∑∀ai j

b(ai j) f (lk,R(rmap(ci),map(c j)))� �3.21

onde B(lk) é a largura de banda do enlace lk e f (lk, pm,n) =

{0, lk /∈ L(pm,n)

1, lk ∈ L(pm,n)Para avaliar a eficiência e a robustez da abordagem proposta por HU; MARCULESCU

(2005), foram criados quatro categorias de benchmark aleatórios, que foram gerados utilizandoo TGFF. Cada categoria contém dez aplicações com 9, 16, 25 e 36 tarefas, respectivamente.Cada tarefa foi mapeada em um tile da plataforma, e os experimentos foram realizados em umaplataforma MPSoC homogênea com os seguintes tamanhos 3x3, 4x4, 5x5 e 6x6.

Os resultados encontrados nos experimentos foram comparados com o SA, e, para aprimeira categoria (aplicação com 9 tarefas), a abordagem encontrou uma solução melhor que asolução encontrada pelo SA e de uma forma mais rápida. E para as outras categorias a abordagemfoi somente 3%, 6%, e 10% maior comparada com o SA, respectivamente. Para avaliar apotencialidade do algoritmo, os autores empregaram a técnica em aplicações reais. A abordagemfoi aplicada no Multi Media System (MMS), que é um sistema integrado de vídeo/áudio queinclui um codificador e decodificador de vídeo H263 e um codificador e decodificador de áudioMP3. Inicialmente, foi necessário particionar o MMS em 40 tarefas concorrentes para, então,alocar em uma plataforma 4x4 (16 PE) heterogênea. E os resultados gerados reduziram a energia

55

em 12% quando comparados com o SA.Este trabalho, além de gerar bons resultados para o problema de otimização de energia,

ele também permite modificar a heurística para roteamentos diferentes, em outras palavras,apresenta uma flexibilidade de roteamento, mas não apresenta a possibilidade de adaptação paraflexibilizar o uso de recursos, como, por exemplo processador.

3.2.2 Uma Abordagem Multiobjetivo para o Problema de Mapeamento

Na abordagem proposta por ASCIA; CATANIA; PALESI (2006), foi desenvolvida umatécnica heurística baseada em algoritmos evolucionários para explorar o espaço de mapeamentomultiobjetivo. Para isso, os autores utilizaram duas funções objetivo, que devem ser otimizadaspara encontrar a fronteira do Pareto. Para encontrar essa fronteira do Pareto, utilizaram o Strength

Pareto Evolutionary Algorithm (SPEA).Como em todos os algoritmos genéticos, as soluções do SPEA também são representadas

por cromossomo. E para cada tile da plataforma tem um gene associado o qual codifica aidentificação do processador mapeado no tile. O SPEA gera uma nova solução (mapeamento)Ms mediante do cruzamento entre dos cromossomos M f e Mm. O operador de cruzamentoimplementado na abordagem proposta por ASCIA; CATANIA; PALESI (2006) constrói umasolução da seguinte maneira: O cromossomo dominante entre M f e Mm é escolhido, e oprocessador hot-spot é então remapeado em um outro tile da plataforma de maneira aleatória.Esse remapeamento é feito utilizando a função Swap(M, i, j), simplesmente, trocando i-ésimotile com o j-ésimo tile do cromossomo dominante M. Dessa forma é criada uma nova solução.

Além do operador genético de cruzamento, o SPEA também implementa o operadorgenético de mutação, o qual é aplicado sobre um único cromossomo M para obter um ocromossomo multante M′. A mutação é feita da seguinte forma: Um tile Ts do cromossomo M éescolhida de forma aleatória, e o processador do tile Ts é identificado como cs e o processadorcom o qual o processador cs mais se comunica também é identificado (cl) e assim o operadorremapeia o processador cs para um tile adjacente ao tile Ts de modo a reduzir a distância em hop

entre os processadores cs e cl , obtendo assim o cromossomo multante M′. Na Tabela 3.8, sãoapresentadas as funções que são utilizadas pelo operador de mutação.

As funções objetivo utilizadas pelo autores nessa abordagem são: a quantidade total deenergia consumida e o tempo de execução, em outras palavras, esse abordagem busca otimizarenergia e desempenho.

Para avaliar a abordagem proposta, os autores utilizaram inicialmente dois cenáriosde tráfego diferente. No primeiro cenário, eles buscaram avaliar a abordagem em um cenáriototalmente sintético, onde o tráfego é gerado estatisticamente, sem referência especial a umaaplicação específica. Segundo os autores, o cenário sintético foi utilizado para avaliar a propostaporque, com esse tipo de aplicação, é possível identificar o mapeamento ideal (em alguns casos)e, assim, compará-lo com a solução encontrada. Já no segundo cenário, os autores utilizaram a

56

Tabela 3.8 Funções utilizadas pelo operador de mutação do SPEAFunções DescriçãoRandomTile(M) Função que retorna aleatoriamente um tile do cromossomo MMaxCommunication(c) Função que retorna o processador que mais se comunica

com o processador cRow(M,T ) Função que retorna a linha de um tile T do cromossomo MCol(M,T ) Função que retorna a coluna de um tile T do cromossomo MNorth(M,T ) Função que retorna o tile norte do tile T no cromossomo MSouth(M,T ) Função que retorna o tile sul do tile T no cromossomo MEast(M,T ) Função que retorna o tile leste do tile T no cromossomo MWest(M,T ) Função que retorna o tile oeste do tile T no cromossomo M

aplicação MPEG-4, que é uma aplicação real.Os experimentos foram realizados em uma plataforma MPSoC com tamanho 2x2 e

4x4 para o primeiro cenário de teste e com tamanho 4x4 para o segundo cenário de teste. Osexperimentos realizados nos dois cenários de teste mostraram uma melhora de desempenho euma economia em média de 20% e, em alguns casos, chegando a 50%, como foi o caso daaplicação real MPEG-4.

Mesmo apresentando bons resultados, os autores sugerem uma melhoria nos operadosgenéticos (cruzamento e mutação) do algoritmo, já que esses ajustes têm um grande impactosobre os resultados da otimização e, assim, é possível melhorar os resultados (ASCIA; CATANIA;PALESI, 2006). Essa abordagem também não utiliza nenhuma técnica para minimizar o uso dosrecursos como o processador.

3.2.3 Uma Abordagem Multiobjetivo para Alocação de Tarefas em PE

JENA; SHARMA (2007) propõem encontrar a fronteira do Pareto que minimiza a energiaconsumida e a largura de banda requerida sobre a restrição de desempenho, por meio do problemade alocação. Para isso, os autores propõem dividir o problema de alocação em dois subproblemasou etapas de alocação, como apresentado no fluxo da Figura 3.1. Os dois subproblemas ou etapasde alocação são: alocação de tarefas em PE e alocação de PE em tiles da plataforma.

Para resolver os dois subproblemas multiobjetivo, JENA; SHARMA (2007) utilizaram,em cada etapa da abordagem, uma algoritmo genético multiobjetivo baseado no Non-dominated

Sorting Genetic Algorithm (NSGA).

3.2.3.1 Etapa de alocação de tarefas em PE

Os objetivo principal desta etapa da abordagem é atribuir as tarefas de um grafo de tarefasem PE disponíveis, a fim de minimizar a energia computacional, ou seja, reduzir o consumode energia e minimizar o custo total dos recursos. Para resolver essa etapa, JENA; SHARMA(2007) usaram o NSGA-II para encontrar a fonteira do Pareto.

57

Figura 3.1 Fluxo do projeto implementado por JENA; SHARMA (2007)

Fonte: JENA; SHARMA (2007)

Geralmente, em algoritmos genéticos, o cromossomo representa a solução para oproblema, mas, neste, o comprimento de cada cromossomo é proporcional ao número de nósdo grafo de tarefas, onde o i-ésimo gene do cromossomo identifica o PE em que está alocadoo i-ésimo nó do grafo de tarefas, ou seja, cada gene do cromossomo contém um inteiro querepresenta o PE.

Nessa etapa, os autores consideram somente um simples ponto de cruzamento para gerara prole. E, para o operador de mutação, eles consideram a mutação por substituição, ou seja,cada vez que um gene no cromossomo for escolhido com base em uma probabilidade aleatória,o valor do gene será substituído por um valor melhor desde que esse valor seja admissível para ogene, onde o objetivo é atribuir mais tarefas a um determinado PE para que seja possível reduzira comunicação entre os PE.

3.2.3.2 Etapa de alocação de PE em tiles

O objetivo desta etapa é alocar os PE que foram utilizados na etapa anterior (alocação detarefas em PE) em tiles da plataforma MPSoC. Esta etapa também é uma etapa multiobjetivoonde JENA; SHARMA (2007) buscam minimizar a distância média de comunicação entre osPE, ou seja, reduzir o número de roteadores entre os PE e maximizar o throughput, ou seja,minimizar a largura de banda nos enlaces. Para resolver esse subproblema, os autores utilizaramo mesmo algoritmo genético multiobjetivo utilizado na etapa anterior NSGA-II para encontrar afronteira do Pareto. Nesta etapa, o cromossomo é a representação da solução do problema; nestecaso o cromossomo descreve o mapeamento, onde cada tile da plataforma tem associada a elaum gene com a identificação do PE mapeada nela.

Uma nova solução C3 é gerada através do cruzamento entre dois cromossomos C1 e C2

da seguinte maneira: O cromossomo dominante entre C1 e C2 é escolhido, e o PE que requermais comunicação é remapeado aleatoriamente para outro tile da plataforma, criando, assim, um

58

novo cromossomo C3. O operado de cruzamento utiliza para isso a função Swap(C, i, j), que,simplesmente, substitui o i-ésimo gene pelo j-ésimo gene no cromossomo C. E o operador demutação é aplicado sobre um simples cromossomo C para obter um cromossomo multante C′ daseguinte forma: Um tile Ts de um cromossomo C é escolhida aleatoriamente e são identificadoso PE do tile Ts (cs) e o PE com o qual o processador cs mais se comunica (cl) e, assim, cs

é remapeado para um tile adjacente do tile Ts reduzindo a distância entre os elementos deprocessamento cs e cl , e com isso o cromossomo multante C′ é criado. O operador de mutaçãoutiliza nesta etapa da abordagem, as mesmas funções apresentadas na Tabela 3.8

Para validar a abordagem, JENA; SHARMA (2007) utilizaram uma plataforma MPSoCbaseada em NoC, de tamanho 3x3, pois eles utilizaram benchmark que não necessitava de maisdo que 9 PE. E, para avaliar o desempenho da abordagem, os autores utilizaram trêsbenchmark

gerados aleatoriamente com 16, 18 e 14 tarefas, e, para verificar a viabilidade da proposta, foramrealizados experimentos utilizando a aplicação real Joint Photographic Experts Group (JPEG)((encoder) que foi modificada pelos autores e é chamada de Motion-Joint Photographic Experts

Group (M-JPEG). A abordagem mostrou eficiência, precisão, economizando em média 15% a20% da energia para os três benchmarks aleatórios e para a aplicação real M-JPEG.

Esta abordagem como outras estudadas utilizam roteamento estático e fixo, isso porqueé necessário minimizar o número de roteadores entre os PE. Mas, em compensação, essaabordagem apresenta uma diferença em relação às outras abordagens, ela permite otimizaçãodos recursos, ou seja, busca minimizar o uso do PE da plataforma.

3.2.4 Algoritmos de Mapeamento para MPSoC Baseada em NoC

MARCON et al. (2008) comparam diferentes algoritmos de mapeamento que buscamminimizar a energia de uma plataforma MPSoC baseada em NoC e que utilizam o Communication

Eighted Model (CWM). O modelo CWM foi proposto por HU; MARCULESCU (2003) e ébaseado sobre o grafo de característica da aplicação, onde o peso de uma aresta corresponde aovolume das mensagens transmitidas através desta aresta. O uso desse modelo permite reduzir oconsumo de energia em 60%, quando comparado com outras soluções de mapeamento ad-hoc

(MARCON et al., 2005).Neste trabalho, os autores avaliam cinco algoritmos de mapeamento: Exhaustive Search

(ES), dois algoritmos de busca estocástica (SA e Tabu Search (TS)) e duas heurísticas chamadasLargest Communication First (LCF) e Greedy Incremental (GI). E desses algoritmos ainda foramgeradas três abordagens mistas: SA como mapeamento inicial para a LCF (HSO), TS comomapeamento inicial para a LCF (HT) e uma versão do SA com um simples laço de iteraçãousando o mapeamento LCF como mapeamento inicial (HSM).

Para avaliar esses algoritmos, MARCON et al. (2008) utilizaram um framework, que ébaseado em uma plataforma MPSoC e que permite modelar aplicações, algoritmos de mapeamentoe geração de aplicações sintéticas e, além disso, suporta simular aplicações para avaliar o

59

seu comportamento e estimar o tempo de execução e consumo de energia. Os experimentosforam realizados em uma plataforma com várias configurações, como, por exemplo, o grau deconectividade, o peso da comunicação e o tamanho da NoC. Esses experimentos realizados nestetrabalho mostraram que a escolha do algoritmo de mapeamento pode influenciar diretamente noconsumo de energia de uma plataforma MPSoC, onde a economia de energia pode variar de 15%a 40% dependendo do algoritmo de mapeamento utilizado (MARCON et al., 2008).

3.2.5 Uma Abordagem ACO para o Mapeamento de Tarefas

WANG et al. (2011) utilizaram uma abordagem baseada no ACO para mapear tarefasem uma plataforma MPSoC com o objetivo de minimizar a largura de banda requerida pelaplataforma, ou seja, eles propõem uma abordagem que minimiza a largura de banda totalnecessária em uma NoC por meio do problema de mapeamento.

Neste trabalho, os autores levam em consideração a aplicação e a topologia da NoC paraformular o problema. A aplicação é representada mediante de um grafo de tarefas A(T,F), ondevértice ti ∈ T representa a tarefa ti e a aresta fi j ∈ F representa o fluxo entre as tarefas ti e t j; eci j o volume de comunicação entre as tarefas ti e t j; e a topologia da NoC é representada por umgrafo N(P,L), onde o vértice pi ∈ P representa um PE utilizado na plataforma e a aresta li j ∈ L

representa o enlace que liga os processadores pi e p j; e bi j representa a largura de banda doenlace li j.

O objetivo é minimizar a largura de banda total. Essa largura de banda é representadapela soma do volume de comunicação de todos os enlaces utilizados depois do mapeamento deuma aplicação especifica. A função objetivo utilizada é representada na Equação 3.22.

minB = ∑∀(i, j)

(ci j×dist(i, j))� �3.22

onde dist(i, j) representa o número de saltos necessários para a comunicação entre astarefas ti e t j.

O ACO implementado por WANG et al. (2011), e apresentado na Figura 3.2, buscaencontrar a melhor solução para o problema de mapeamento. Essa metaheurístca é inspiradano comportamento das formigas, que se movem simultaneamente de forma independente,construindo um caminho entre o formigueiro (colonia) e a comida, utilizando como base atrilha de feromônios deixada pelas outras formigas. Em outras palavras, o ACO é uma técnicaprobabilística de otimização que encontra uma solução de forma estocástica com base na trilha deferomônios para encontrar o caminho do formigueiro (colonia) e a comida. Esse tipo de algoritmo,frequentemente, é utilizado para resolver problemas Non-deterministic Polynomial (NP) (WANGet al., 2011).

Inicialmente, o ACO utilizado nessa abordagem inicializa os valores das variáveis(número de iteração, número de formigas, número de tarefas e a trilha de feromônios). Já, no

60

segundo passo, é feito o mapeamento das tarefas nos processadores. Esse mapeamento é feitopelas formigas (agentes) do ACO que alocam cada tarefa da aplicação em um processador daplataforma, e a escolha do processador é feita com base na probabilidade apresentada na Equação3.23.

pki j =

{τi j

∑i/∈Tabu τi j, Se i /∈ Tabu

0, Se i ∈ Tabu

� �3.23

onde τi j é a quantidade de feromônios na aresta que liga os tiles i e j na plataforma, e

∑i/∈Tabu τi j representa a soma das quantidades de feromônios das arestas não utilizados pelo tile i.E depois que todas as formigas distribuem seu conjunto de tarefas, o algoritmo escolhe a

melhor solução de cada iteração para atualizar a trilha de feromônios, ou seja, a formiga queencontrou a melhor solução em cada iteração é usada como base para atualizar o caminho deferomônios. E, depois de todas as iterações o algoritmo escolhe a melhor solução.

Figura 3.2 Algoritmo ACO implementado por WANG et al. (2011)


Para avaliar a abordagem, os autores utilizaram uma plataforma virtual baseada em NoCcom algoritmo de roteamento XY, de tamanho 4x4, onde cada pacote trafegado na NoC possui32 flits e cada flit 16 bits. Os experimentos para validação foram realizados utilizando dezbenchmarks gerados aleatoriamente pela TGFF e duas aplicações reais (decodificador MPEG-4e Video Object Plane Decoder (VOPD)). E os resultados obtidos foram comparados somentecom mapeamentos aleatórios, conseguindo encontrar para as aplicações reais uma redução dalargura de banda de 48,6% e 12% para o decodificador MPEG-4 e o VOPD respectivamente.

Analisando o ACO porposto por WANG et al. (2011), é possível verificar que os autoresnão utilizam nenhuma informação heurística na Equação 3.23 para decidir qual o próximo tile,

61

ou seja, os autores só levam em consideração a trilha de feromônios para escolher o próximo tile

da plataforma. A tilha de feromônios só reflete a experiência obtida pelas formigas durante abusca. Já a informação heurística pode refletir o problema especifico a ser resolvido.

3.2.6 Uma Abordagem PSO para o Mapeamento de Tarefas

SAHU et al. (2014) propõem utilizar uma meta-heurística baseada em PSO para mapearaplicações em uma plataforma MPSoC baseada em NoC 2D e 3D. O PSO é uma meta-heurísticaestocástica baseada em população, que é inspirada no comportamento social dos pássaros oudos peixes. Uma abordagem baseada em PSO tem múltiplas soluções candidatas, convivendoe colaborando simultaneamente, e essas soluções são chamadas de partículas e elas voam noespaço de projeto de acordo com sua própria experiência, ou de acordo com a experiência daspartículas vizinhas. Esse tipo de meta-heurística tem sido aplicada com sucesso em alguns dosproblemas de otimização, como por exemplo o problema de mapeamento (SAHU et al., 2011).

Para minimizar o custo de comunicação de uma plataforma MPSoC por meio do problemade mapeamento, o PSO deve ser implementado de forma que a partícula tenha a estrutura deum vetor de tamanho igual ao número de PE presentes na plataforma P. E a entrada i-ésima dovetor identifica o PE alocado com i-ésimo roteador da plataforma. E, para avaliar a qualidade deuma partícula, é utilizada uma função de aptidão. No trabalho de SAHU et al. (2014), a funçãode aptidão é igual ao custo total da comunicação. Essa função pode ser vista na Equação que édefinida como,

∑u,v∈P

Bandwidth(u,v)×hopcount(u,v)� �3.24

onde hopcount(u,v) é o menor número de saltos entre o PE u e o PE v depois domapeamento, e Bandwidth(u,v) e a largura de banda entre o PE u e o PE v. Quanto menor ovalor da função de aptidão, melhor será a partícula e consequentemente a solução.

O algoritmo PSO implementado por SAHU et al. (2014), e apresentado na Figura 3.3,possui duas variáveis para representar a melhor solução. A variável pbest, que representa amelhor partícula local (melhor solução local) e gbest, que representa a melhor partícula dageração (melhor solução global). Inicialmente, o ACO cria a população aleatoriamente e calculaa aptidão de cada partícula para, em seguida, atualizar os valores das variáveis (pbest e gbest).Para gerar a próxima geração, o algoritmo simplesmente troca de maneira aleatória alguns PEdas partículas de posição. Isso é feito por meio do operador chamado swap. E sempre que umanova geração é criada, as variáveis pbest e gbest são atualizadas (SAHU et al., 2011).

Para avaliar e validar a abordagem PSO, SAHU et al. (2014) utilizaram as aplicaçõesMPEG-4, VOPD, Picture in Picture (PIP) e MWD em uma plataforma MPSoC configuradacomo mostra a Tabela 3.9

Os resultados encontrados durante os cenários de teste foram comparados com outras

62

Figura 3.3 Algoritmo PSO implementado por SAHU et al. (2014)

Fonte: O Autor

Tabela 3.9 Aplicações e configurações da plataformaAplicações NoC 2D NoC 3DVOPD 4x4 2x4x2MPEG-4 4x4 2x4x2PIP 4x2 2x2x2MWD 4x4 2x4x2

técnicas de mapeamento, conforme é mostrado na Tabela SAHU et al. (2014) . Em geral, ascomparações mostraram que a abordagem baseada em PSO proposta por SAHU et al. (2014)consegue encontrar boas soluções em relação ao custo da comunicação e do desempenho.

Tabela 3.10 Comparação do custo e desempenhoVOPD MPEG-4 PIP MWD

Algoritmos Custo Des. Custo Des. Custo Des. Custo Des.NMAP 2D 4265 0,024 3672 0,016 640 0,010 1184 0,016PSMAP 2D 4119 0,260 3567 0,040 640 0,010 1120 0,020

PSO 2D 4119 3,340 3567 3,080 640 0,590 1120 3,010ILP 2D 4119 4474,730 3567 21,530 640 1,280 1120 200,510

NMAP 3D 4199 0,020 3672 0,012 640 0,010 1184 0,016PSMAP 3D 4119 0,330 3567 0,040 640 0,010 1120 0,180

PSO 3D 4119 2,510 3567 3,150 640 0,450 1120 1,880ILP 3D 4103 14109,060 3567 88,310 640 1,3400 1120 953,120

3.3 ANALISE DOS TRABALHOS RELACIONADOS

Durante essa seção, é feita uma analise comparativa das abordagens que utilizammapeamentos exatos e baseados em busca que foram apresentadas nesse capítulo, conforme é

63

mostrado nas Tabela 3.11 e Tabela 3.12.

Tabela 3.11 Trabalhos relacionados baseados em métodos exatosILP MILP

RUGIERO et al. (2006) GHOSH; SEN; HALL (2009)HUANG et al. (2011)

Tabela 3.12 Trabalhos relacionados baseados em buscaMeta-heurística Evolucionário Inteligência coletiva

HUANG et al. (2011) ASCIA; CATANIA; PALESI (2006) SAHU et al. (2011)HU; MARCULESCU (2005) JENA; SHARMA (2007) WANG et al. (2011)

SAHU et al. (2014)

3.3.1 Mapeamento Exato

Os mapeamentos exatos são baseados em fundamentações matemáticas (ILP/MILP)que garante encontrar a solução ótima. Essa é a principal vantagem do mapeamento exato. Eas desvantagens dos mapeamentos exatos são: modelagem mais complexas, podem gastar umtempo proibitivo para gerar a solução ótima e nem sempre consegue produzir uma "boa" soluçãoviável rapidamente.

Os trabalhos relacionados apresentados nesse capitulo fazem mapeamento/escalonamentosde tarefas e ajuste do nível de tensão para minimizar a energia. RUGIERO et al. (2006) fazmapeamento e escalonamento de tarefas em uma plataforma MPSoC baseada em barramentoutilizando ILP, mas não agrupa as tarefas comunicantes e não apresenta um modelo preciso decomunicação. Já GHOSH; SEN; HALL (2009) e HUANG et al. (2011) fazem mapeamentode tarefas e ajuste do nível de tensão utilizando ILP/MILP, mas também não agrupam astarefas comunicantes e o modelo de comunicação também não é preciso. A Tabela 3.13 mostraum comparativo entre os trabalhos relacionados que utilizam fundamentação matemática paraencontrar uma solução que minimize energia através do mapeamento de tarefas.

Tabela 3.13 Analise comparativa dos trabalhos baseados em métodos exatosRUGIERO et al. (2006) GHOSH; SEN; HALL (2009) HUANG et al. (2011)

O que faz? Mapeamento Mapeamento MapeamentoEscalonamento Nível de tensão Nível de tensão

Como? ILP MILP ILP/SAInterconexão Barramento NoC NoCAgrupamento Não Não Nãode tarefasPrecisão do modelo Não Não Nãode comunicação

64

3.3.2 Mapeamento Baseado em Busca

Os mapeamentos baseados em busca são baseados em meta-heurística, algoritmosevolucionários ou inteligência coletiva. Esse tipo de mapeamento são fáceis de implementar eproduzem "boas" soluções rapidamente. Mas a desvantagem é que não garante a otimalidade dasolução encontrada.

Os trabalhos relacionados, baseados em busca, apresentados nesse capitulo fazemmapeamento de tarefas e ajuste do nível de tensão para minimizar a energia. ASCIA; CATANIA;PALESI (2006) e JENA; SHARMA (2007) fazem mapeamento de tarefas multiobjetivo utilizandoalgoritmos genéticos multiobjetivo para garantir um baixo custo computacional, mas também nãoapresenta um modelo preciso de comunicação e não agrupam as tarefas comunicantes. E SAHUet al. (2014) e WANG et al. (2011) utilizam inteligência coletiva (ACO/PSO) para mapear tarefas,e como nos outros trabalhos também não apresenta modelo de comunicação preciso e tambémnão agrupam tarefas comunicantes. A Tabela 3.14 e a Tabela 3.15 mostram um comparativoentre os trabalhos relacionados que utilizam, respectivamente, meta-heurísticas e algoritmosbaseados em inteligência coletiva.

Tabela 3.14 Analise comparativa das meta-heurísticas baseadas em buscaASCIA; CATANIA; PALESI (2006) JENA; SHARMA (2007)

O que faz? Mapeamento MapeamentoMultiobjetivo Multiobjetivo

Como? GA GAInterconexão NoC NoCAgrupamento Não Nãode tarefasPrecisão do modelo Não Nãode comunicação

Tabela 3.15 Analise comparativa dos algoritmos baseados em inteligência coletivaWANG et al. (2011) SAHU et al. (2014)

O que faz? Mapeamento Mapeamento

Como? ACO PSOInterconexão NoC NoCAgrupamento Não Nãode tarefasPrecisão do modelo Não Nãode comunicação

656565

4ABORDAGEM PROPOSTA

Neste capítulo, é apresentada a abordagem proposta, baseada em uma meta-heurística,que tem como objetivo principal fazer uma busca no espaço de projeto de uma plataforma MPSoCbaseada em NoC para encontrar, em tempo de projeto, um mapeamento eficiente das tarefas, deuma aplicação especifica ou o mapeamento de um conjunto de aplicações (multiaplicação), sobreos PEs da plataforma, de forma que todas as tarefas ou aplicações sejam mapeadas próximasdos PEs com que elas se comunicam com maior volume de dados, para reduzir o consumo deenergia.

A principal vantagem de utilizar essa abordagem é que, com somente duas simulaçõesda plataforma, é possível explorar o espaço de projeto e encontrar uma solução viável. Outravantagem dessa abordagem está no tipo de mapeamento utilizado (mapeamento estático), já esteestático não produz um overhead na rede de comunicação durante a execução, comparado comos mapeamentos dinâmicos que produzem um overhead (ALMEIDA et al., 2010).

4.1 VISÃO GERAL

A abordagem proposta busca encontrar um mapeamento que minimize a energia da NoC,mediante a redução do tráfego da rede. Para encontrar esse mapeamento, tal abordagem necessitade três grafos. O Grafo de Características da Plataforma (GCP), o Grafo de Dependências entreTarefas (GDT) e o Grafo de Comunicação de Tarefas (GCT), que são extraídos da descriçãoda plataforma, do código da aplicações e da simulação inicial, respectivamente. E, no finaldo processo, a abordagem faz uma estimativa do consumo de energia da rede, levando emconsideração o mapeamento encontrado pela meta-heurística.

A Figura 4.1 apresenta os fluxos da abordagem proposta. E, para facilitar o entendimentoda abordagem, ela foi dividida em quatro fases (extração de grafos, agrupamento de tarefas,mapeamento inicial e otimização do mapeamento).

66

Figura 4.1 Fluxo da Proposta


4.2 FASE DE EXTRAÇÃO DE GRAFOS

Esta fase é responsável por extrair, em tempo de projeto, o GCP e o GDT. Esses grafossão extraídos da descrição da plataforma e da especificação da aplicação. É também durante essafase que a plataforma virtual Infinity é configurada, por meio da descrição da plataforma.

A Figura 4.1 apresenta os fluxos que são utilizados durante a primeira fase da abordagem(fase de extração de grafos). No fluxo 01 e 03, são extraídos estaticamente o GCP e o GDT dadescrição da plataforma e do código fonte da aplicação respectivamente. E, no fluxo 02, sãofeitas as devidas configurações na plataforma virtual Infinity.

4.2.1 Grafo de Características da Plataforma

O grafo de características da plataforma é um grafo composto por um conjunto de tiles einformações de interconexão que são necessárias para a otimização. Esse grafo é representadocomo GCP = (L,A), onde cada vértice li ∈ L, representa uma tile da plataforma. E cada arestaai j ∈ A representa a distância em hops entre as tiles i e j. A Figura 4.2 apresenta uma plataformaMPSoC de tamanho 2x2 e o GCP dessa plataforma MPSoC.

67

Figura 4.2 Grafo de Características da Plataforma: (a) Plataforma MPSoC 2x2 (b) GCP da PlataformaMPSoC 2x2


4.2.2 Grafo de Dependências entre Tarefas

Como já foi dito, uma aplicação pode ser considerada como um conjunto de tarefascomunicantes e, assim, é possível representar a dependência entre as tarefas por meio de umgrafo, que é definido como GDT = (T,A), onde cada vértice ti ∈ T representa uma tarefa ecada arco ai j ∈ A representa a dependência de dados entre a tarefa ti e a tarefa t j. A tarefa ti édependente da tarefa t j, quando há comunicação ou troca de informações mediante uma memóriacompartilhada. A Figura 4.3 apresenta um grafo de dependência entre tarefas para uma aplicaçãocom quatro tarefas.

Figura 4.3 Grafo de Dependências entre Tarefas de uma aplicação sintética: (a) Código fonte da aplicação(b) GDT da aplicação


68

4.3 FASE DE AGRUPAMENTO DE TAREFAS

Para reduzir o custo de comunicação na plataforma, esta abordagem inclui um mecanismode agrupamento (clustering) de tarefas, que visa ao agrupamento de tarefas com dependências,ou seja, tarefas que acessam a mesma variável compartilhada.

O problema de agrupamento é classificado como NP-difícil, ou seja, uma solução ótimanão é conhecida. Existe uma variedade de heurísticas na literatura que visam encontrar umasolução aproximada para o problema com instâncias de grande porte, com centenas ou milharesde vértices. Mas a qualidade do agrupamento encontrado por uma heurística é altamentedependente do conjunto de dados de entrada. Assim, os dados serão agrupados da melhormaneira se o método de agrupamento for adequado ao problema.

Esta abordagem utiliza um algoritmo de agrupamento baseado em coloração de grafospara agrupar as tarefas com dependências de dados. Na Figura 4.1 é possível visualizar osfluxos 04 e 05, que são utilizados nesta fase. E também é possível verificar que o mecanismo deagrupamento tem como dado de entrada o grafo GDT.

4.3.1 Mecanismo de Agrupamento de Tarefas

Este mecanismo primeiramente gera o Grafo Inverso do GDT (GDT’), onde o GDT’ éum grafo com os mesmos vértices do GDT tais que dois vértices do GDT’ são adjacentes se esomente se eles não são adjacentes no GDT. A Figura 4.4 apresenta o algoritmo utilizado nestemecanismo para gerar GDT’.

Figura 4.4 Algoritmo para gerar o grafo inverso do GDT


Somente depois de gerar o GDT’ é que o mecanismo de agrupamento pode utilizar oalgoritmo de coloração de grafos para encontrar r grupos de cores. O algoritmo de coloraçãoimplementado neste mecanismo leva também em consideração o número máximo de tarefas porgrupo (cor).

Para exemplificar o funcionamento do mecanismo de agrupamento utilizado nestaabordagem, vamos utilizar o GDT mostrado na Figura 4.5 (a). Como já foi dito, primeiramente,

69

o mecanismo precisa gerar o grafo inverso do GDT, que é mostrado na Figura 4.5 (b). Depois deter gerado o GDT’, o mecanismo, finalmente, utiliza o algoritmo de coloração para agrupar astarefas dependentes. Os grupos de tarefas deste exemplo podem ser visualizados na Figura 4.5(c), que mostra o GDT’ colorido da forma como o conjunto de tarefas devem ser agrupadas.

Figura 4.5 Um exemplo de agrupamento de tarefas: (a) GDT, (b) GDT’ e (c) Grafo colorido


Para esse exemplo o mecanismo agrupou as tarefas em dois grupos de cores, onde astarefas B e C foram agrupadas no primeiro grupo e as tarefas A e D no segundo grupo.

4.3.1.1 Algoritmo de coloração de grafos

Em sua formulação mais simples, o algoritmo de coloração de grafos é caracterizadopela atribuição de uma cor ci ∈C para cada vértice vi ∈V , de um grafo G(V,A), de tal modo quea dois vértices adjacentes sejam atribuídos cores diferentes, ou seja, o processo de coloração degrafos é uma função f : V →C tal que para cada par de vértices (vi,v j) ∈ A→ f (vi) 6= f (v j).

A Figura 4.6 apresenta o algoritmo de coloração de grafos utilizado no mecanismo deagrupamento. Esse algoritmo particiona o conjunto de vértices em conjuntos independentes,de forma que dois vértices adjacentes recebem cores diferentes e também considera o númeromáximo de vértice por cor.

4.4 FASE DO MAPEAMENTO INICIAL

Esta fase é responsável pela geração do GCT, que representa o volume de transaçõesentre cada conjunto de tarefas/aplicações e as tiles da plataforma virtual.

A Figura 4.1 apresenta os fluxos (05, 06, 07 e 08) que são utilizados durante a fase domapeamento inicial. Os dados de entrada (grupo de tarefas de uma aplicação ou conjunto deaplicações) são representados pelo fluxo 05. Já o fluxo 06 carrega a plataforma virtual, visto que,durante essa fase, é necessário simular uma aplicação ou um conjunto de aplicações. O fluxo07 é responsável por carregar a aplicação/aplicações na plataforma virtual, e o fluxo 08 tem aresponsabilidade de gerar o GCT (objetivo principal dessa fase).

70

Figura 4.6 Algoritmo de coloração de vértices


4.4.1 Grafo de Comunicação de Tarefas

O GCT representa a comunicação entre o conjunto de tiles e o conjunto de tarefas ouaplicações. O GCT pode ser formalizado como: GCT = (T,L,A), onde cada vértice ti ∈ T éuma tarefa, grupo de tarefas ou aplicação e cada vértice l j ∈ L é uma tile da plataforma. Cadaarco ai j ∈ A representa a quantidade de mensagens de acesso à memória local da tile L j, feitapela tarefa ti. Como já foi comentado, o GCT é gerado na fase do mapeamento inicial, e levandoem consideração um mapeamento aleatório dos grupos de tarefas ou aplicações. A Figure 4.7apresenta um exemplo de um GCT de uma aplicação sintética com quatro tarefas para umaplataforma MPSoC de tamanho 2x2.

4.5 FASE DE OTIMIZAÇÃO DO MAPEAMENTO

Esta fase é responsável por encontrar um mapeamento para as tarefas de uma aplicaçãoou aplicações que minimizem o consumo de energia da NoC. Para realizar esse trabalho demapeamento, foi implementada uma meta-heurística de mapeamento. Essa meta-heurísticatem como objetivo encontrar uma solução para o problema de mapeamento de tarefas em umaplataforma MPSoC. É também durante essa fase que é gerado o modelo de energia da NoC,utilizada pela plataforma virtual.

Os fluxos desta fase podem ser visualizados com destaque na Figura 4.1. Onde o fluxo09 representa a geração do modelo de energia. O fluxo 10 representa os dados de entrada paraa otimização do mapeamento (GCT, modelo da plataforma virtual e o modelo de energia daNoC). Como na fase anterior, o fluxo 11 é responsável por carregar a aplicação/aplicações na

71

Figura 4.7 Grafo de Comunicação de Tarefas


plataforma. E finalmente no último fluxo 12, é gerada a estimativa do consumo de energia daNoC.

4.5.1 Modelo de Energia

O modelo de energia utilizado é baseado na passagem dos pacotes de rede pelosroteadores, onde o seu chaveamento produz as transições que dão origem à potência dinâmica.Para entender melhor o modelo de energia, é necessário conhecer as formas de dissipação depotência de uma NoC em um Field Programmable Gate Array (FPGA).

4.5.1.1 Medição de potência em FPGA

Para que um FPGA funcione adequadamente, é necessária a existência de uma fonte depotência externa, que forneça a energia elétrica necessária para as operações internas e externasao dispositivo serem executadas com sucesso. Dessa forma, o projeto da fonte deve levar emconsideração a potência total requerida pelo sistema e a potência total dissipada pelo dispositivo.A potência total dissipada por um FPGA e pelo sistema é constituída por três potências principais:potência estática, potência dinâmica e potência de Entrada e Saída (E/S).

A potência estática de um dispositivo é a potência dissipada quando o dispositivo está emstandby, ou seja, quando não tem atividade dos sinais (sem chaveamento). Nesse caso o consumodo dispositivo ocorre somente devido à dispersão das correntes elétricas, e essa dispersão varia deacordo com o tamanho, a temperatura e o processo de fabricação do FPGA. Em outras palavras,a potência estática de um FPGA está diretamente relacionada à sua temperatura do chip. Assim,para se obter uma baixa dissipação de potência estática, é necessário manter a temperatura doFPGA no menor valor possível (sistemas de refrigeração ou dissipadores de calor).

72

A potência dinâmica somente é dissipada quando ocorrem mudanças de níveis lógicosnos módulos internos do FPGA. Esse consumo de energia acontece quando ocorre a carga ea descarga tanto das capacitâncias dos arranjos lógicos quanto das redes de interconexões, ouseja, quando um sinal muda o seu nível lógico de 1 para 0, uma certa quantidade de potênciaé dissipada. Em um FPGA, os recursos que influenciam no gasto de potência dinâmica econtribuem no consumo são: elementos lógicos, elementos de roteamento, bloco de Random

Access Memory (RAM), bloco multiplicadores Digital Signal Processor (DSP), Phase Locked

Loops (PLL) e clocks. E, para se calcular a potência dinâmica total deve se levar em conta acorrente elétrica utilizada para cada um desses recursos e a voltagem fornecida ao FPGA.

4.5.1.2 Ambiente de medição

Para obter a corrente elétrica utilizada, foi desenvolvido um ambiente de medição queleva em consideração as seguintes estratégias:

(i) Replicação espacial: Colocar a NoC SoCIN dentro do FPGA, com vários clones domesmo, fazendo a mesma operar de forma sincronizada. Tentar colocar o máximo declones possíveis para ter uma adição significativa das correntes de chaveamento no núcleodo FPGA para aumentar o volume da corrente e, assim, melhorar a relação sinal/ruído.

(ii) Replicação Temporal: Realizar um sequência de repetições das transações, a seremcaracterizadas, de modo que o efeito de acumulação no tempo, dos diversos chaveamentosde elementos no FPGA, passem pelos componentes reativos (RLC) parasitas, presentesno circuito, vendo-os como um filtro passa baixa, resultando em uma corrente médiasignificativa a ser observada.

(iii) Filtragem Estatísticas: As formas de onda observadas com o Osciloscópio serão oresultado líquido dos diversos clones do circuito em comutação e da integração no tempodas diversas operações do circuito realizadas em sequência. Mas esse sinal ainda deveráconter muito ruído, vindo da própria placa DE2-70, do ambiente e do próprio conjunto.Desse modo, para melhorar o sinal, filtros foram aplicados a cada forma de onda capturadae/ou adicionar várias formas de onda para obter uma filtragem estatística dos ruídos.

Neste ambiente de medição, foi utilizado uma NoC 3x3, onde para cada roteador existeum gerador de sinal de rota e pacotes para simular a presença de um PE em cada nó da NoC.Cada gerador também proporciona recursos para replicação temporal, onde estes são previamenteconfigurados com períodos de operação intensa alternados com período de inatividade. E paraminimizar o ruído, foi escolhido um amplificador com um filtro passa baixa. Esse ambientede medição foi desenvolvido utilizando a linguagem SystemVerilog e prototipado utilizandoa ferramenta Quartus II da Altera. A prototipação deste ambiente permitiu medir o consumo,latência, desempenho e outros parâmetros. A síntese foi realizada em uma placa DE2-70 comFPGA Cyclone II EP2C35F672C6.

73

Como a potência dissipada pelo dispositivo precisa ser estimada de forma precisa, a fimde possibilitar o desenvolvimento de soluções de potência apropriadas, como fontes de potência,reguladores de voltagem, dissipadores de calor e sistemas de refrigeração, esse ambiente utilizoua ferramenta PowerPlay Power Analyzer que é uma ferramente para estimação de potência, quevem acoplada ao software Quartus II. O uso dessa ferramenta permite estimar o consumo depotência de um projeto, já que o PowerPlay Power Analyzer já conhece tanto o dispositivo alvoquanto como o projeto está arranjado e roteado dentro do dispositivo.

4.5.1.3 Energia da NoC

O modelo de energia da NoC utilizado é baseado no consumo de energia dos roteadores,ou seja, na energia consumida por cada roteador da NoC durante a execução de uma determinadaaplicação. A energia consumida por um roteador leva em consideração a quantidade de pacotestrafegados no roteador, a potência consumida pelo roteador para passar um pacote através dele eo período de tempo que o roteador ficou ativo durante a execução da aplicação. Para calcular aenergia consumida por um roteador da NoC, devemos aplicar a Equação 4.1:

Eri = Qri.Pri.tri� �4.1

onde Qri é o total de pacotes trafegados no roteador ri, Pri é a potência consumida porum roteador ri para passar um pacote através dele e tri é o período de tempo que o roteador ri

está em atividade durante a execução da aplicação.Com essa informação, é possível calcular a energia dinâmica total consumida pelos

roteadores de uma NoC. A Equação 4.2 define essa energia dinâmica total consumida pelorroteadores.

Eroteadores =n−1

∑i=0

Eri� �4.2

onde n é o número de roteadores da NoC e Eri é a energia consumida pelo roteador ri.O cálculo da energia dinâmica de uma NoC é dividido em: energia dinâmica consumida

pelos roteadores (Equação 4.2), energia dinâmica consumida pelos enlaces que conectam osroteadores da NoC (Equação 4.3)

Eenlaces =l−1

∑i=0

(Qli.Pli.tli)� �4.3

onde Qli, Pli e tli representam o total de pacotes trafegados no enlace, a potênciaconsumida pelo enlace li para passar um pacote através dele e o tempo trabalhado pelo li

durante a execução da aplicação respectivamente.Já a energia total consumida por uma NoC é baseada nas energias dinâmicas dos

roteadores, dos enlaces e da energia estática da NoC. Então a energia total consumida pela NoC

74

é definida pela Equação (4.4), onde Eestatica é a energia estática consumida pela NoC.

Etotal = Eroteadores +Eenlaces +Eestatica� �4.4

A energia consumida por um MPSoC é propocional à atividade de chaveamento originadapelos pacotes que se movem por meio da NoC. Roteadores e enlaces dissipam potências, e algunsautores como HU; MARCULESCU (2005) e BENINI; MICHELLI (2006) propõem estimar oconsumo de energia na NoC mediante a avaliação do efeito do tráfego em cada componente.E considerando a complexidade para estimar o tempo de operação de cada enlace durante asimulação da aplicação, este trabalho negligenciou a energia dinâmica Eenlace frente a Eroteadores.Então a energia total estimada pelo nosso modelo é baseada na Equação 4.5; utilizamos aferramenta Powerplay Analysis para estimar a potência Pri consumida pelo roteador ri e a energiaestática da NoC Eestatica.

Etotal = Eroteadores +Eestatica� �4.5

4.5.2 Mecanismo de Mapeamento de Tarefas

O mecanismo de mapeamento proposto é responsável por escolher a tile ideal para mapearum grupo de tarefas gerado durante a fase de agrupamento de tarefas ou mapear várias aplicações.Para implementar esse mecanismo, utilizamos uma meta-heurística baseada em inteligênciacoletiva, que é um campo de pesquisa que estuda a computação inspirada no comportamento degrupos de indivíduos, como insetos e pássaros. Escolhemos uma meta-heurística baseada emcolônia de formigas, que é uma das mais difundidas.

Essa meta-heurística foi escolhida porque possui um grande potencial e apresenta emgeral um melhor desempenho do que outras técnicas de otimização disponíveis, quando aplicadaao problema QAP, em experimentos realizados por STüTZLE; DORIGO (1999) em algumasinstâncias da Quadratic Assignment Problem Library (QAPLIB). Os resultados mostraram queo ACO são muitos bons para instâncias desestruturadas, como nos caso dos problemas reais.O QAP pode ser melhor descrito como o problema de alocar um conjunto de facilidades a umconjunto de locais dados, os fluxos entre as facilidades e as distâncias entre os locais cujo oobjetivo é encontrar uma disposição adequada das facilidades nos locais que minimize o produtoentre os fluxos e as distâncias.

Mais formalmente, dados n facilidades, n locais e duas matrizes nxn, F e D, onde fi j ∈ F

é o fluxo entre as facilidades i e j e dkl ∈ D é a distância entre os locais k e l, o QAP pode serformalizado como:

minφ∈Πn

n

∑i=1

n

∑j=1

fi jdφ(i)φ( j)

� �4.6

onde Πn é o conjunto de todas as permutações φ : {1, ...,n} −→ φ : {1, ...,n}.

75

4.5.2.1 Meta-heurística baseada em colônia de formigas

Esta meta-heurística foi desenvolvida na tese de doutorado de DORIGO (1992), quepropôs um algoritmo chamado Ant System para solucionar problemas computacionais queenvolvem procura em grafos. A meta-heurística foi utilizada no Problema do Caixeiro Viajante(PCV) para demonstrar sua funcionalidade.

O desenvolvimento desse algoritmo só foi possível porque os biólogos provaram queas formigas, mesmo sendo praticamente cegas, são capazes de encontrar o menor caminhoentre a fonte de alimento (comida) e o ninho (colônia) pela cooperação entre elas, usandouma comunicação indireta, ou seja, uma comunicação não simbólica, onde a natureza dainformação a ser transmitida corresponde a uma modificação física do ambiente (HöLLDOBLER;WILSON, 1990) (BECKERS; DENEUBOURG; GOSS, 1992). Essa comunicação e capacidadede adaptação à mudança do ambiente é possível graças a uma substância química, chamadaferomônio, que é depositada pelas formigas para que as outras possam segui-las entre a comida ea colônia. Esta substancia permite também que elas encontrem um novo caminho mais curto.

O comportamento das formigas funciona da seguinte maneira: inicialmente, elas exploramde forma aleatória a área ao redor do formigueiro ou colônia à procura de comida ou fontes decomida. Enquanto elas se deslocam, depositam no solo feromônios que vão ajudar a encontrar ocaminho de volta ao formigueiro e também para auxiliar na comunicação com as outras formigas.Dessa forma, quando uma formiga encontra uma fonte de alimento, o caminho ou trilha entre acomida e a colônia fica marcado por um rastro de feromônio. O rastro com maior quantidadede feromônio tende a ser seguido pelas outras formigas. Assim, as formigas que escolherem ocaminho mais curto farão o percurso em menor tempo e o rastro de feromônio será reforçadocom uma frequência maior que os caminhos mais longos, já que o feromônio é uma substânciavolátil. Essa evaporação do feromônio evita que, com o tempo, um caminho que não está maissendo utilizado continue a influenciar na decisão das formigas.

Esse comportamento é exemplificado na Figura 4.8, onde podemos observar que, inicialmente,as formigas partem do formigueiro em busca de alimento de forma aleatória (Figura 4.8 (a)). E,com o decorrer do tempo, elas passam a percorrer o menor caminho, pois esse caminho acumulamais feromônios (Figura 4.8 (b)).

O conceito básico dessa meta-heurística é encontrar a melhor solução para o problema,baseando-se em um caminho de feromônios em conjunto com um modelo matemático, que refleteo problema a ser resolvido, ou seja, é um algoritmo não determinístico baseado em populaçãode formigas (agentes), que se movem simultaneamente de forma independente, construindoestocasticamente soluções com base nas informações heurísticas e no caminho de feromônios(COLORNI; DORIGO; MANIEZZO, 1991).

A informação heurística se refere ao problema específico a ser resolvido, no caso destetrabalho, distância e tráfego entre tiles, e o caminho de feromônios reflete a experiência obtidadurante a busca. Em outras palavras, cada formiga, inicialmente, explora a área ao redor, e,

76

Figura 4.8 Comportamentos das Formigas: (a) Início aleatório e (b) Final com comprimento mínimo.


quando uma formiga encontra "comida"(solução), ela avalia a qualidade da solução, e, durantea viagem, de retorno a formiga deposita um caminho de feromônio no solo. A quantidade deferomônio depositado depende da quantidade e qualidade da "comida"(solução), a fim de orientaroutras formigas para encontrarem a fonte de alimento (Fonte da solução).

Essa meta-heurística é um algoritmo de busca baseado em dados e locais (DORIGO;STüTZLE, 2004) (AL-SHARAA; AL-QUBLAN, 2013) e, facilmente, aplicado para problemasrepresentados em grafo, onde o problema é representado por um conjunto de elementos (vértices)que podem estar conectados. Cada vértice representa uma abstração matemática e as conexõesentre os vértices (arcos) representam algumas características que relacionam dois vértices. Oalgoritmo é apresentado na Figura 4.9. Inicialmente é feita a distribuição de k formigas emvértices aleatórios de um grafo completo, que representa uma plataforma MPSoC, G = (V,E),onde V é o conjunto de vértices V = 1,2,3, ...,n e E é o conjunto de arestas E = 1,2,3, ...,m.Cada vértice vi ∈ T representa uma tile, cada aresta ei ∈ E representa um caminho entre duastiles e para cada aresta no grafo é associado um caminho/rasto de feromônios t. A complexidadedo ACO adaptado para esse problema é dado por O(m× n× k), onde m é o número total deiterações, n a discretização adotada e k é o número de formigas.

A Figura 4.10 apresenta o fluxo de construção de uma solução pelo ACO, onde durante aconstrução, cada formiga recebe a mesma sequencia de tarefas e são distribuídas pelos vérticesdo grafo G = (V,E). Cada formiga irá construir uma solução visitando individualmente váriosvértices do grafo, começando de um vértice i, para alocar uma tarefa da sua lista de tarefas. Epor meio de um mecanismo estocástico a formiga escolhe o próximo vértice j entre os seusvizinhos. Cada formiga tem uma memória, que também é chamada de lista tabu, que armazena oscaminhos percorridos por ela e previne que um caminho seja visitado pela formiga mais de uma

77

Figura 4.9 Algoritmo Colônia de Formiga


vez. A decisão de uma formiga k que está no vértice i de escolher o vértice j está sujeita a umadistribuição de probabilidade. A probabilidade de escolha de um caminho leva em consideraçãoduas informações diferentes: a informação heurística, que mede o impacto na função objetivoem atravessar a aresta (i, j) e a informação vinda do feromônio que mede quão desejável é aaresta (i, j). A probabilidade da formiga k percorrer uma aresta (i, j) corresponde à razão entreo peso do uso da aresta (τi j)

α(ηi j)β e a soma de todos os pesos do conjunto de caminhos não

percorridos ς ki . A Equação 4.7 mostra a probabilidade pk

i j de uma formiga k mover-se do nó i

para o no nó j.

pki j =

(τi j)

α (ηi j)β

∑u∈ςki(τiu)α (ηiu)β

, Se j ∈ ς ki

0, caso contrário

� �4.7

onde τi j representa a quantidade de feromônios associado à aresta (i, j) e ηi j representa ainformação heurística que mede o impacto na função para a formiga visitar o vértice j depois devisitar o vértice i. O valor de ηi j é apresentado na Equação 4.8, onde di j representa a distânciaentre o vértice i e o vértice j e f é o fluxo de pacotes entre a próxima tarefa a ser alocada novértice j. E ς k

i é o conjunto de caminhos não percorridos pela formiga k.

ηi j =f

di j

� �4.8

78

Figura 4.10 Fluxo de Construção de uma Solução pelo ACO


A probabilidade de distribuição é definida pelos parâmetros α e β , que são ajustesheurísticos que determinam a proporção entre a informação heurística e a informação dadapelo feromônio na aresta (i, j). Ou seja, é a influência relativa do caminho de feromônio e ainformação heurística, respectivamente.

A Figura 4.11 ilustra o comportamento de uma formiga localizada na tile 0 em relaçãoaos parâmetros α e β . Na Figura 4.11 (a) (α < β ), a informação heurística terá uma maiorinfluência para escolher o próximo vértice. E analisando a figura, podemos verificar que a tile 1é mais atrativa para a formiga localizada na tile 0, já que a probabilidade é maior.

Já na Figura 4.11 (b) (α > β ), o caminho de feromônio terá uma maior influência naescolha do próximo vértice. E analisando a figura, podemos observar que a tile 1 ainda é maisatrativa para a formiga, mas as probabilidades são diferentes das apresentadas na Figura 4.11 (a).

E, quando todas as formigas constroem suas soluções, faz-se necessário atualizar a matrizde feromônios por meio do depósito e/ou evaporação desta substância para cada tile. Ou seja,ao longo de um caminho (i, j), cada formiga deposita uma quantidade da substância, a qual édefinida pela Equação 4.9. Ao contrário da natureza, a deposição do feromônio é feita somente nofinal de cada iteração. Essa quantidade de feromônio em cada aresta está associada ao processode aprendizagem do algoritmo.

τi j = (1−ρ)τi j +m

∑k=1

∆τ(k)i j

� �4.9

Essa atualização é composta por dois termos: um associado ao processo de evaporação deferomônio e outro associado ao depósito de feromônio de todas as formigas que utilizaram cadaaresta. O processo de evaporação ((1−ρ)τi j) evita o acúmulo de feromônios indefinidamente

79

Figura 4.11 Demonstração dos parâmetros α e β : (a) α < β e (b) α > β


e, com isso, permite esquecer as decisões tomadas no passado. Isto evita que formigas fiquempresas em um ótimo local, além de diminuir a probabilidade de escolha de arestas que não foramutilizadas.

O parâmetro ρ é uma informação heurística, que controla a velocidade de evaporaçãodo feromônio. Esse parâmetro também pode ser chamado de coeficiente de evaporação. Ele éresponsável por indicar a quantidade de feromônio de uma iteração que será descartada paraa iteração seguinte. Já a quantidade de feromônio depositado pela formiga k entre (i, j) érepresentado por ∆τi j e é definido pela Equação 4.10.

∆τi j(k) =

{1Lk, if (i,j) ∈ Sk

0, caso contrário

� �4.10

onde Lk é o custo da solução gerada pela formiga k, de modo que o depósito é realizadose o caminho estimado (i, j) pertence ao caminho construído pela formiga k. O critério de paradautilizado no algoritmo é o número máximo de iterações.

Para demonstrar o processo de construção de uma solução, foi utilizado um exemplocom quatro tiles e um conjunto de quatro tarefas (A, B, C e D). A Figura 4.12 (a) apresenta oGCP e a Figura 4.12 (b) o GCT, onde 4 formigas são espalhadas pelo conjunto de vértices dografo, que se caracteriza de uma plataforma MPSoC de tamanho 2x2. Ou seja, no início cadaformiga é colocada em uma tile diferente (aleatoriamente). E, a partir desse ponto, cada formigairá construir uma solução, movendo-se entre as tiles. Esse ponto inicial do algoritmo é mostradona Figura 4.13 (a).

A Tabela 4.1 apresenta os valores iniciais das trilhas de feromônios e a Tabela 4.2apresenta a tabela de fluxo. Os valores destas tabelas foram utilizados pelo algoritmo.

No próximo passo, cada formiga escolhe probabilisticamente a próxima tile entre as tiles

80

Tabela 4.1 Tabela de feromônio inicialtile 0 tile 1 tile 2 tile 3

tile 0 0 1 1 1tile 1 1 0 1 1tile 2 1 1 0 1tile 3 1 1 1 0

Tabela 4.2 Tabela de fluxotile 0 tile 1 tile 2 tile 3

A 1300 360 200 800B 400 600 500 320C 1250 890 600 950D 250 540 100 500

Figura 4.12 Grafos do exemplo de construção de uma solução: (a) GCP (b) GCT


da plataforma MPSoC, utilizando a Equação 4.7, que calcula a probabilidade de a formiga queestá na tile i escolher a tile j. A Tabela 4.3 mostra um exemplo de valores de probabilidades. E aFigura 4.13 (b) mostra a solução parcial gerada por cada formiga.

Tabela 4.3 Passo 1 do exemplo de construção de uma soluçãoFormigas Candidatos/Probabilidade Solução Parcial

1 tile 1 (63%) tile 2 (36%) tile 3 (1%) tile 0 - tile 12 tile 0 (29%) tile 2 (56%) tile 3 (15%) tile 1 - tile 23 tile 0 (52%) tile 1 (22%) tile 3 (26%) tile 2 - tile 04 tile 0 (2%) tile 1 (62%) tile 3 (36%) tile 3 - tile 1

No segundo passo, as formigas continuam escolhendo as tiles da plataforma de formaprobabilística por meio da Equação 4.7. A Tabela 4.4 mostra um exemplo dos valores das

81

Figura 4.13 Um exemplo de construção de uma solução


probabilidades atualizados e a Figura 4.13 (c) mostra a solução parcial gerada por cada formiga.

Tabela 4.4 Passo 2 do exemplo de construção de uma soluçãoFormigas Candidatos/Probabilidade Solução Parcial

1 tile 2 (37%) tile 3 (63%) tile 0 - tile 1 - tile 32 tile 0 (69%) tile 3 (31%) tile 1 - tile 2 - tile 03 tile 1 (35%) tile 3 (65%) tile 2 - tile 0 - tile 34 tile 0 (96%) tile 2 (4%) tile 3 - tile 1 - tile 0

No último passo, cada formiga escolhe probabilisticamente a última tile entre as tiles daplataforma MPSoC a ser visitado; para isso, o algoritmo ainda continua utilizando a Equação4.7, A Tabela 4.5 mostra um exemplo dos valores das probabilidades atualizados, e a Figura 4.13(d) mostra a solução final (completa) gerada por cada formiga.

Durante a demonstração deste exemplo, foram geradas 4 soluções para alocação de 4tarefas (A, B, C e D). A Tabela 4.6 apresenta as soluções encontradas.

E depois que todas as formigas distribuem seu conjunto de tarefas, o algoritmo escolhea melhor solução de cada iteração para atualizar a trilha de feromônios, com base na Equação

82

Tabela 4.5 Passo final do exemplo de construção de uma soluçãoFormigas Candidatos/Probabilidade Solução Parcial

1 tile 2 (100%) tile 0 - tile 1 - tile 3 - tile 22 tile 3 (100%) tile 1 - tile 2 - tile 0 - tile 33 tile 1 (100%) tile 2 - tile 0 - tile 3 - tile 14 tile 2 (100%) tile 3 - tile 1 - tile 0 - tile 2

Tabela 4.6 Soluções encontradas para o exemploAlocação

Solução tile 0 tile 1 tile 2 tile 3 Qualidade1 Tarefa A Tarefa B Tarefa D Tarefa C 84502 Tarefa C Tarefa A Tarefa B Tarefa D 89503 Tarefa B Tarefa D Tarefa A Tarefa C 95004 Tarefa C Tarefa B Tarefa D Tarefa A 10100

4.9. Ou seja, a formiga que encontrou a melhor solução em cada iteração é usada como basepara atualizar o caminho de feromônios. A Tabela 4.7 apresenta a tabela de feromônios desseexemplo atualizada. Foi utilizada uma taxa de evaporação de 70%, nesta demonstração.

Tabela 4.7 Tabela de feromônio atualizadatile 0 tile 1 tile 2 tile 3

tile 0 0 0,3002 0,3003 0,3002tile 1 0,3002 0 0,3001 0,3003tile 2 0,3003 0,3001 0 0,3001tile 3 0,3002 0,3003 0,3001 0

Nos algoritmos baseados em colônias de formigas, a comunicação entre as formigas éfeita de maneira indireta, ou seja, lendo e escrevendo nas variáveis de rastro de feromônios. Essacomunicação entre as formigas gera uma interação coletiva entre elas e, assim, é possívelencontrar soluções de boa qualidade. Dessa forma, as formigas não são adaptáveis; elasmodificam a forma como solucionar o problema, e essa modificação é percebida pelas outrasformigas.

As formigas (agentes) do algoritmo colônia de formigas movem-se para qualquer nóde sua vizinhança, procuram sempre uma solução que otimize a função objetiva. Elas tambémpossuem uma memória, que é usada para armazenar informações sobre o caminho percorrido atéo momento.

4.6 CONCLUSÃO DA ABORDAGEM PROPOSTA

Portanto a abordagem proposta, apresentada nesse capitulo, utiliza inteligência coletivapara mapear tarefas em uma plataforma MPSoC baseada em NoC para minimizar a energia.

Esta abordagem apresenta um modelo de comunicação mais preciso, onde é possível

83

contabilizar todas as comunicações ocorridas na NoC e também incorpora ao processo umatécnica de agrupamento de tarefas. Esse agrupamento de tarefas comunicantes garante umaredução da comunicação na rede e consequentemente de energia.

A Tabela 4.8 mostra uma comparação entre a abordagem apresentada e os trabalhos deSAHU et al. (2014) e WANG et al. (2011) que também utilizam inteligência coletiva (ACO/PSO).E analisando a Tabela 4.8 pode ser concluído que SAHU et al. (2014) e WANG et al. (2011) nãoapresentam um modelo de comunicação preciso e não agrupam as tarefas comunicantes.

Tabela 4.8 Analise comparativa da abordagem proposta com os trabalhos relacionadosWANG et al. (2011) SAHU et al. (2014) Abordagem

PropostaO que faz? Mapeamento Mapeamento Mapeamento

Como? ACO PSO ACOInterconexão NoC NoC NoCAgrupamento Não Não Simde tarefasPrecisão do modelo Não Não Simde comunicação

848484

5EXPERIMENTOS E RESULTADOS

Neste capítulo, apresentaremos os resultados obtidos pelos experimentos realizados paravalidação da abordagem proposta. Como foi mencionado anteriormente, as métricas a seremavaliadas são: (i) Energia consumida na comunicação; (i) O Tempo total de execução dasaplicações mapeadas. Tanto os cenários como as aplicações utilizadas são descritos tambémneste capítulo. Também, neste capítulo, iremos apesentar a organização da plataforma MPSoCalvo (Plataforma Infinity) utilizada para fazer uma busca exaustiva no espaço de projeto duranteos experimentos de cada aplicação.

5.1 ORGANIZAÇÃO DA PLATAFORMA INFINITY

A plataforma Infinity foi organizada com a infraestrutura de comunicação baseada natopologia malha. E, dentre os parâmetros adotados para a NoC SoCIN, encontram-se: largura docanal, profundidade dos buffers de entrada, controle de fluxo, chaveamento de pacote e algoritmode roteamento. Os parâmetros apresentados na Tabela 5.1 são os valores padrão da NoC SoCIN.Neste trabalho foi utilizado uma configuração default obtida a partir de vários experimentos.

Tabela 5.1 Configurações da NoC SoCINLargura do Profundidade Controle de Chaveamento Algoritmo

canal dos Buffer fluxo de pacote roteamento34 bits 4 Baseado em crédito wormhole XY

5.2 EXPERIMENTOS

Os experimentos precisam respeitar duas restrições da plataforma Infinity durante osexperimentos. Primeiramente, a plataforma deve ser homogênea, de forma que cada tarefaou aplicação pode ser mapeada em qualquer PE da plataforma. E a segunda restrição estárelacionada a uma limitação da Infinity, onde o número de PE da plataforma deve ser umapotência de 2.

85

5.2.1 Mecanismo de Mapeamento

Para todos os cenários de simulação, o mecanismo de mapeamento foi configuradoconforme a Tabela 5.2.

Tabela 5.2 Configuração do mecanismo de mapeamento de tarefasNúmero de Formigas Taxa de Evaporação Critério de Parada

20 0,80 30 interações

Esse valores foram escolhidos, após 10 execuções da meta-heurística de mapeamentopara cada configuração. Esse experimento foi executado em uma máquina virtual, com sistemaoperacional Linux e com 6 GB de RAM. Em uma máquina workstation, com sistema operacionalWindows, 8 GB de RAM e com processador Core i5.

5.2.2 Ambiente de Medição de Potência

A configuração do ambiente de medição da potência foi baseado nas formas de dissipaçãode potência e no funcionamento dos componentes da NoC. Como já foi visto anteriormente, apotência estática de um circuito não depende da operação feita sobre o dispositivo e sim das suasdisposições físicas. Dessa forma, essa potência será constante. Assim, o ambiente de mediçãoconsegue calcular o consumo de potência dinâmica através da passagem de um pacote de 136bits pela rede.

Utilizando a ferramenta PowerPlay Analyzer, foi possível estimar através de uma sériede entradas (após as etapas de síntese e fitting) e de uma forma precisa, o consumo de potênciade um projeto baseado em NoC. Isso só foi possível porque o PowerPlay Analyzer já conhece oFPGA e como o projeto está arranjado e roteado dentro do FPGA.

A Figura 5.1 mostra o fluxo da ferramenta PowerPlay para estimar as potências dissipadas.Esse fluxo mostra a necessidade de quatro entradas para a realização da estimação de potênciade um projeto.

O ambiente de medição possibilita também o monitoramento da corrente dentro da FPGA,para que seja possível produzir dados mais confiáveis. Para isso, foi necessário instrumentar aplaca DE2-70, criando um filtro amplificador que foi acoplado na placa para amplificar o sinal eminimizar o ruído. A Figura 5.2 apresenta a placa DE2-70 instrumentada com o amplificadorcom filtro passa baixa, e a Figura 5.3 apresenta o ambiente de medição, medindo a potência deuma NoC.

A descrição do circuito de uma NoC, configurável, com topologia malha é descritono ambiente de medição, onde, em cada nó, existe um gerador de pacotes. Os geradores depacotes são responsáveis para enviar e consumir dados da NoC de acordo com a programaçãode controle. Para estimar a potência, foi feito um experimento em quatro cenários, de envio de

86

Figura 5.1 Fluxo do projeto usando PowerPlay


Figura 5.2 Placa DE2-70 com o filtro amplificador


Figura 5.3 Prototipação e medição da potência da NoC


87

pacotes, distintos de operação, norte para sul, sul para norte, leste para oeste e oeste para leste. ATabela 5.3 apresenta os valores médios para cada cenário.

Tabela 5.3 Estimativas do PowerPlay Analyzer sobre uma NoCRotas Total NoC Dinâmica NoC Estática NoC E/S NoC Roteador

(mW/pacote) (mW/pacote) (mW/pacote) (mW/pacote) (mW/pacote)

norte-sul 209,59 15,67 154,62 39,30 0,58

sul-norte 209,59 15,67 154,62 39,34 0,58

leste-oeste 209,62 15,67 154,62 39,34 0,58

oeste-leste 209,65 15,67 154,62 39,37 0,58

X̄ 209,61 15,67 154,62 39,34 0

σ 0,029 0 0 0,29 0,58

Considerando algumas restrições da placa DE2-70, o ambiente de medição precisa serconfigurado conforme os valores apresentados pela Tabela 5.4.

Tabela 5.4 Parâmetros de configuração do ambiente de mediçãoFrequência Clock

de operação (MHz) do ambiente (ns)

20 50

Com base nos valores estimados pelo ambiente de medição, foi possível utilizar o valormédio da potência dinâmica e estática estimada na última fase da abordagem proposta. É nestafase que é calculado o consumo de energia da NoC. A Tabela 5.5 apresenta os valores médios dapotência dinâmica e estática, que foram utilizados nos cenários de testes deste trabalho.

Tabela 5.5 Potências dissipadas pela NoCDinâmica do Estática da

roteador (mW/pacote) NoC (mW/pacote)

0,58 154,62

5.2.3 Análise Estatística

Para que os resultados obtidos nos cenários de teste tenham um bom nível de confiança,é necessário gerar uma amostra que represente o espaço de projeto de cada aplicação. Esse nívelde confiança está diretamente relacionado ao tamanho da amostra, onde quanto maior o tamanhoda amostra maior será sua representatividade (menor será a margem de erro); porém, amostrasmuito grandes requerem maiores esforços e recursos.

Para calcular o tamanho da amostra, que proporciona uma confiança desejada, foiutilizada a Equação 5.1 (JAIN, 1991).

88

n =Z2×σ2

E20

� �5.1

onde Z é o valor crítico que corresponde ao nível de confiabilidade desejada, σ é o desviopadrão populacional e E0 é o erro amostral tolerável. O erro amostral, em geral, é definido pelopesquisador/analista, e, frequentemente, esse erro é definido entre 5% e 10% do valor médio daamostra. Os valores de confiança mais utilizados e os seus valores de Z correspondentes podemser encontrados na Tabela 5.6 (LAPPONI, 2005).

Tabela 5.6 Valores críticos de ZGrau de confiança Valor crítico de Z

90% 1,64595% 1,96799% 2,576

5.2.4 Experimento A

Neste experimento, a plataforma Infinity foi configurada com dimensão reduzida (2x4),para permitir uma busca exaustiva no espaço de projeto e, assim, analisar se a abordagemproposta é capaz de encontrar soluções satisfatórias frente a melhor solução possível.

Três aplicações foram utilizadas como base para a geração dos grafos GDT e GCTnos cenários desse experimento. Essas aplicações que possuem topologia e também taxasaproximadas de comunicação das aplicações reais, visam aproximar os experimentos a umexperimento real. O grande volume de dados dessas aplicações podem ultrapassar a largura debanda disponível, sendo necessária a distribuição do tráfego por meio de diferentes caminhos(MURALI; DE MICHELI, 2004).

5.2.4.1 Aplicação MPEG

O MPEG é um padrão utilizado para compressão de dados digitais de áudio e vídeo. Nopresente trabalho, foi utilizado um decodificador parcial do MPEG, que é representado pelo GDTda Figura 5.4, composto por 5 (cinco) tarefas (start, ivlc, iquant, idct e print) e que apresenta umparalelismo temporal.

Figura 5.4 GDT da aplicação MPEG


89

5.2.4.2 Aplicação de segmentação de imagens

Como a aplicação MPEG, a Segmentação de Imagens também é uma aplicação real. Adiferença dessa aplicação em relação à aplicação MPEG, é que ela contém paralelismo espacial etemporal, como pode ser visto na Figura 5.5, que ilustra o grafo de dependência entre as 6 (seis)tarefas.

Figura 5.5 GDT da aplicação SegImg


5.2.4.3 Aplicação PIP

É uma aplicação real que contém comunicação paralela. A aplicação PIP permite exibirum vídeo em uma caixa dentro de um outro vídeo. Geralmente, a aplicação PIP é utilizada nastransmissões de TV ao vivo. A Figura 5.6 ilustra o grafo de dependência entre as 8 (oito) tarefas.

Figura 5.6 GDT da aplicação PIP


90

5.2.5 Cenários de Teste do Experimento A

Para o experimento A, foram realizadas três cenários de teste, para cada aplicação, eo que diferencia um cenário do outro é a configuração do número de tarefas por processador,durante a fase de agrupamento de tarefas. No primeiro cenário, o mecanismo de agrupamento foiconfigurado para não agrupar tarefas comunicantes, ou seja, uma única tarefa por processador;já, no segundo cenário, o mecanismo foi configurado para agrupar no máximo duas tarefas porprocessador e, no terceiro cenário, foram agrupadas três tarefas por processador. Uma buscaexaustiva no espaço de projeto foi realizada, no segundo cenário, para comparar os resultadosobtidos com o inicial, pior e o melhor mapeamento para as aplicações, indicando um percentualde melhoria.

5.2.5.1 Cenário de teste 1

Neste cenário de teste, o mecanismo de agrupamento não foi utilizado, ou seja, cada tarefadas aplicações MPEG, Segmentação de Imagens (SegImg) e PIP foram alocadas (mapeadas) emum PE da plataforma infinity.

Os mapeamentos iniciais foram encontrados, aleatoriamente, durante a fase do mapeamentoinicial, como podem ser vistos na Figura 5.7.

Figura 5.7 Mapeamento inicial para o cenário de teste 1 (a) MPEG, (b) SegImg e (c) PIP


As informações relacionadas a esses mapeamentos iniciais, como: tráfego na rede,energia dinâmica da rede e tempo para executar a aplicação, são apresentadas na Tabela 5.7.

Para continuar os experimentos deste cenário de teste, foi preciso encontrar as amostrasrepresentativas para cada aplicação. Essas amostras foram geradas, inicialmente, executando

91

Tabela 5.7 Informações do mapeamento inicial das aplicações para o cenário de teste 1MPEG SegImg PIP

Tráfego Energia Tempo Tráfego Energia Tempo Tráfego Energia Tempo(pacotes) (J) (ms) (pacotes) (J) (ms) (pacotes) (J) (ms)486693 2,96 4,01 1449984 27,65 3,91 386925 2,23 2,40

a abordagem 11 vezes, ou seja, foi gerada uma amostra inicial com 11 soluções (nu). Depoisfoi verificado se essa amostra tem um nível de confiança (representa o espaço de projeto) pormeio da Equação 5.1. Se nu > n representa que a amostra inicial é suficiente para representaro espaço de projeto; caso contrario, é necessário gerar novas soluções até que a amostra tenha(n+1) soluções.

A Tabela 5.8 apresenta as 11 soluções geradas para montar a amostra inicial para cadauma das aplicações analisadas. No final da tabela, são apresentadas as médias (X̄) e os desviospadrões (σ ) para os valores de tráfego, energia (dinâmica) e tempo de cada aplicação.

Tabela 5.8 Amostra inicial para o cenário de teste 1MPEG SegImg PIP

Tráfego Energia Tempo Tráfego Energia Tempo Tráfego Energia Tempo(pacotes) (J) (ms) (pacotes) (J) (ms) (pacotes) (J) (ms)

1 322879 2,17 3,73 1003149 16,14 9,27 280482 1,23 1,742 324162 2,43 3,93 1012065 16,16 9,97 281437 1,26 1,753 316684 1,62 2,93 1044952 17,14 9,41 277153 1,18 1,724 322879 2,17 3,73 1148854 20,46 9,52 277153 1,18 1,725 322420 2,02 3,76 1144314 19,98 9,85 286186 1,28 1,786 322420 2,02 3,76 1048529 18,61 9,72 280482 1,23 1,747 316684 1,62 2,93 1003149 16,14 9,27 279167 1,20 1,738 324162 2,43 3,93 1003149 16,14 9,27 281771 1,31 1,759 322879 2,17 3,73 1012173 16,90 10,90 281771 1,31 1,7510 318054 1,93 3,08 1007853 16,16 11,07 309190 1,39 1,9211 318054 1,93 3,08 1007853 16,16 11,07 277153 1,18 1,72X̄ 321025 2,05 3,51 1040537 17,27 9,78 282904 1,25 1,75σ 22571 0,34 0,32 54809 1,64 0,50 9118 0,07 0,06

Para a aplicação MPEG, a amostra inicial, apresentada na Tabela 5.8, já apresenta umbom nível de confiança (nu > n), visto que a Equação 5.1 encontra um n∼= 7,6, para um nívelde confiança de 95% e para um erro tolerável de 5% da média da amostra. Então, na média,a abordagem proposta consegue reduzir a energia consumida pela NoC em aproximadamente30% comparado com o mapeamento inicial. Para facilitar a visualização, foi plotado um gráficoque mostra o espaço da amostra, o valor médio da energia e o valor da energia do mapeamentoinicial. Esse gráfico pode ser visto na Figura 5.8.

Da mesma forma foi feita a analise da amostra da aplicação SegImg, onde foi constatadoque o valor de n igual a n ∼= 4,26, conforme a Equação 5.1. Dessa forma, não foi necessárioaumentar a amostra, já que nu > n. Então por meio da amostra da Tabela 5.8, foi calculado ovalor médio da energia consumida para a aplicação SegImg durante o cenário de teste. O valor

92

Figura 5.8 Amostra da aplicação MPEG para o cenário de teste 1


médio encontrado pela abordagem apresentou uma economia de energia de aproximadamente64% quando comparado com o mapeamento inicial. A Figura 5.9 apresenta um gráfico que plotaa amostra e o valor inicial e médio da aplicação SegImg.

Figura 5.9 Amostra da aplicação SegImg para o cenário de teste 1


Para a aplicação PIP foi constatado que nu > n, quando aplicada a Equação 5.1 naamostra da aplicação PIP, apresentada na Tabela 5.8, n∼= 1,60. Dessa forma, a amostra analisadaapresenta um bom nível de confiança. Para a aplicação PIP a abordagem conseguiu encontraruma solução que economiza na média 45% da energia dinâmica consumida pela NoC. A Figura5.10 apresenta o gráfico, que mostra o valor inicial e médio, e os valores da amostra para aaplicação PIP.

Analisando as informações da Tabela 5.8 e dos gráficos apresentados nas Figuras 5.8,5.9 e 5.10, é possível visualizar que a abordagem proposta encontra na média uma solução queeconomiza 46%, comparando os resultados obtidos com o mapeamento inicial.

93

Figura 5.10 Amostra da aplicação PIP para o cenário de teste 1



Neste cenário de teste, o mecanismo de agrupamento foi configurado para agrupar nomáximo duas tarefas por processador. Também, neste cenário, é feito uma busca exaustivapelo espaço de projeto, de cada aplicação, para encontrar o pior e o melhor mapeamento paraas aplicações analisadas. Estes valores (piores e melhores) são utilizados para comparar como valores médios encontrados pela abordagem. Os espaços de projeto de cada aplicação sãoapresentados nas Figuras 5.11, 5.12 e 5.13.

Figura 5.11 Espaço de projeto da aplicação MPEG para o cenário de teste 2


Os mapeamentos iniciais utilizados neste cenário foram encontrados, aleatoriamente,como no cenário de teste anterior. Esses mapeamentos podem ser vistos na Figura 5.14. E asinformações desses mapeamentos são apresentadas na Tabela 5.9.

Para descobrir o tamanho adequado das amostras deste cenário de teste, foi aplicado a

94

Figura 5.12 Espaço de projeto da aplicação SegImg para o cenário de teste 2


Figura 5.13 Espaço de projeto da aplicação PIP para o cenário de teste 2


Tabela 5.9 Informações do mapeamento inicial das aplicações para o cenário de teste 2MPEG SegImg PIP


Equação 5.1, com nível de confiança de 95% e erro tolerável de 10%. E para o desvio padrão e amédia amostral foram utilizados o do espaço de projeto, que foi encontrado de forma exaustiva.A Tabela 5.10 apresenta os valores de n para cada aplicação analisada.

A Tabela 5.11 apresenta as soluções geradas para montar as amostras. Esta tabela foiencontrada como no cenário de teste 1, e apresenta, no final, as médias (X̄) e os desvios padrões(σ ) para os valores de tráfego, energia (dinâmica) e tempo de cada aplicação.

Os valores médios de tráfego, energia e tempo encontrados pela abordagem, para as três

95

Figura 5.14 Mapeamento inicial para o cenário de teste 2 (a) MPEG, (b) SegImg e (c) PIP


Tabela 5.10 Valores de nAplicação n

MPEG 14SegImg 14

PIP 4

Tabela 5.11 Amostras para o cenário de teste 2MPEG SegImg PIP


1 308161 1,44 3,18 781443 11,93 9,28 282453 1,35 1,962 266598 1,44 3,33 785442 11,95 10,16 270079 1,05 1,843 266598 1,44 3,33 785442 11,95 10,16 280110 1,20 1,864 315970 1,76 3,68 733039 11,13 10,21 277088 1,16 1,735 315970 1,76 3,68 781443 11,93 9,286 318330 1,85 3,76 793028 11,80 9,927 339063 1,86 3,90 872734 13,01 9,178 266598 1,44 3,33 873940 13,23 9,759 318330 1,85 3,76 810495 12,96 9,7810 339063 1,86 3,90 800942 12,72 9,7111 315970 1,76 3,68 793028 11,80 9,9212 315970 1,76 3,68 798158 12,10 10,1713 266598 1,44 3,33 785442 11,95 10,1614 266598 1,44 3,33 733039 11,13 10,21X̄ 301416 1,65 3,56 794830 12,11 9,85 277433 1,19 1,85σ 28231 0,19 0,25 40083 0,65 0,37 5372 0,02 0,09

96

aplicações (MPEG, SegImg e PIP), são mostrados na Tabela 5.11. Comparando o valores médiosencontrados com o mapeamento inicial, é possível ver que a abordagem consegue economizaraproximadamente 58%, 53% e 37% para as aplicações MPEG, SegImg e PIP respectivamente.E analisando esses dados, é possível concluir que a abordagem proposta encontra na média umasolução que economiza 49% quando os resultados são comparados com o mapeamento inicial.As Figuras 5.15, 5.16 e 5.17 apresentam os gráficos, que mostram o valor iniciais e médios e osvalores das amostras para as aplicações MPEG, SegImg e PIP respectivamente.

Figura 5.15 Amostra da aplicação MPEG para o cenário de teste 2


Figura 5.16 Amostra da aplicação SegImg para o cenário de teste 2


Mas, para validar a abordagem, foi feita, durante este cenário de teste, uma exploraçãocompleta do espaço de projeto como já foi mostrado. O objetivo dessa exploração é comparar osvalores médios encontrados pela abordagem com o pior e o melhor mapeamento do espaço deprojeto. As Tabelas 5.12, 5.13 e 5.14, e as Figuras 5.18, 5.19 e 5.20 mostram esses valores paraas aplicações MPEG, SegImg e PIP respectivamente.

97

Figura 5.17 Amostra da aplicação PIP para o cenário de teste 2


Tabela 5.12 O melhor e o pior mapeamento para o MPEG no cenário de teste 2Melhor Pior

Tráfego Energia Tempo Tráfego Energia Tempo(pacotes) (J) (ms) (pacotes) (J) (ms)266459 1,34 3,01 537643 4,07 4,41

Tabela 5.13 O melhor e o pior mapeamento para o SegImg no cenário de teste 2Melhor Pior


Tabela 5.14 O melhor e o pior mapeamento para o PIP no cenário de teste 2Melhor Pior


Para facilitar a análise destes espaços de projeto, foi gerado um gráfico, que mostratodas essas comparações e também com as soluções encontradas pelo SA para cada uma dasaplicações (MPEG, SegImg e PIP). Esse gráfico pode ser visualizado na Figura 5.21. O Simulated

Annealing foi escolhido porque é uma meta-heurística que também começa sua busca a partir deuma solução inicial e gerar uma nova solução a cada iteração, e desta forma o algoritmo buscaencontrar sempre uma nova solução que seja a mínima na vizinhança, agindo de acordo com adiferença entre os valores da função objetivo. A maior vantagem do Simulated Annealing sobreoutros métodos é a possibilidade de evitar mínimos locais. E para isso utiliza uma busca aleatóriaque eventualmente pode acabar aceitando soluções que não sejam minimas. Ou seja, em algumasiterações, o Simulated Annealing tende a maximizar a função objetivo em vez de minimiza-lá.

E com base nos resultados apresentados pelos experimentos realizados neste cenário de

98

Figura 5.18 Exploração do espaço de projeto da aplicação MPEG para o cenário 2


Figura 5.19 Exploração do espaço de projeto da aplicação SegImg para o cenário 2


teste, é possível concluir que a abordagem proposta é capaz de encontrar valores médios, quereduzem o consumo de energia se comparado com o pior e o mapeamento inicial e encontraresultados médios muito próximos do valor ótimo (melhor mapeamento).


Neste último cenário de teste do experimento A, o mecanismo de agrupamento foiconfigurado para agrupar no máximo três tarefas por processador. Como nos cenários anterioresos mapeamentos iniciais utilizados foram encontrados aleatoriamente, esses mapeamentos podemser vistos na Figura 5.22 e as informações desses mapeamentos são apresentados na Tabela 5.15.

A Tabela 5.16 apresenta as 11 soluções geradas para montar a amostra inicial para cadauma das aplicações do experimento A. E, como nos cenários de testes anteriores, a tabela deamostra apresenta também as médias (X̄) e os desvios padrões (σ ) para os valores de tráfego,

99

Figura 5.20 Exploração do espaço de projeto da aplicação PIP para o cenário 2


Figura 5.21 Comparação do tráfego e energia da abordagem com o espaço de projeto das aplicações parao cenário de teste 2


Tabela 5.15 Informações do mapeamento inicial das aplicações na seção de teste 3MPEG SegImg PIP


energia dinâmica e tempo de cada aplicação.Analisando a amostra inicial da aplicação MPEG, apresentada na Tabela 5.16, é possível

verificar que o nu > n, apresentando, assim, bom nível de confiança. O valor de n foi calculadopor meio da Equação 5.1, que encontrou um n∼= 8,7 para um nível de confiança de 95% e um errotolerável de 5% da média da amostra. Como já dito anteriormente, se o nu > n não é necessário

100

Figura 5.22 Mapeamento inicial na seção de teste 3 (a) MPEG, (b) SegImg e (c) PIP


Tabela 5.16 Amostra inicial da seção de teste 3MPEG SegImg PIP


1 308161 1,44 3,68 776923 11,04 9,45 264963 1,00 2,232 266459 1,34 3,10 797482 11,80 10,41 265411 1,07 2,143 324839 2,11 3,90 797482 11,80 10,41 265411 1,07 2,144 266459 1,34 3,10 880942 13,56 11,01 264963 1,00 2,235 326345 2,37 3,93 781874 11,23 10,21 279609 1,35 2,656 308161 1,44 3,68 814012 12,25 10,63 264963 1,00 2,237 308428 1,65 3,73 796379 11,34 10,35 264963 1,00 2,238 308428 1,65 3,73 846141 13,47 10,91 279609 1,35 2,659 308161 1,44 3,68 814012 12,25 10,63 284978 1,42 2,9210 308161 1,44 3,68 781874 11,23 10,21 279609 1,35 2,6511 266459 1,34 3,10 776923 11,04 9,45 279609 1,35 2,65X̄ 300006 1,59 3,57 805822 11,91 10,33 272190 1,18 2,43σ 22571 0,34 0,32 32324 0,90 0,51 8274 0,18 0,28

gerar novas amostras para manter a análise estatística confiável. Analisando os valores geradosneste cenário de teste, é observado que, na média, a abordagem proposta consegue reduzir aenergia consumida da NoC em aproximadamente 46% quando comparado com o mapeamentoinicial. Como foi feito nos cenários anteriores, um gráfico foi gerado para facilitar a visualizaçãoda amostra. Este gráfico pode ser visto na Figura 5.23.

Da mesma forma, foi feita a análise da amostra da aplicação SegImg onde foi constatadoque o n∼= 4,26, conforme a Equação 5.1; assim, não é necessário aumentar a amostra, já quenu > n. Então, por meio da amostra apresentada na Tabela 5.16, foi gerado um gráfico da amostra

101

Figura 5.23 Amostra da aplicação MPEG no cenário de teste 3


que pode ser visualizado na Figura 5.24. Esse gráfico apresenta os valores iniciais e médiosda aplicação SegImg. O valor médio encontrado pela abordagem apresentou uma economia deenergia de aproximadamente 64% quando comparado com o mapeamento inicial.

Figura 5.24 Amostra da aplicação SegImg no cenário de teste 3


Para a aplicação PIP, foi constatado que o nu > n, ou seja, n ∼= 1,60. Dessa forma, aamostra analisada apresenta um bom nível de confiança. E, para a aplicação PIP, a abordagemconsegue encontrar uma solução que economiza na média 47% da energia dinâmica consumidapela NoC. A Figura 5.25 apresenta o gráfico que mostra os valores iniciais e médios, e os valoresda amostra para a aplicação PIP.

Analisando as informações da Tabela 5.16 e dos gráficos apresentados nas Figuras 5.8,5.9 e 5.10, é possível visualizar que a abordagem na média encontrou uma solução que economiza52% comparando os resultados obtidos com o mapeamento inicial.

102

Figura 5.25 Amostra da aplicação PIP no cenário de teste 3


5.2.6 Análise dos Resultados do Experimento A

Para demonstrar o desempenho da abordagem durante os cenários de teste, foramanalisados os dados de energia e tempo de execução das aplicações. Com esses dados foramgerados gráficos para cada aplicação e que podem ser analisados nas Figuras 5.26, 5.27 e 5.28.

Figura 5.26 Desempenho da abordagem proposta no experimento A para a aplicação MPEG


Nestes gráficos, é possível verificar que o uso de um mecanismo de agrupamento antesdo mapeamento de tarefas gera uma economia de energia significativa. E se compararmos ocenário de teste 1 (sem agrupamento) com os outros cenários (com agrupamento), é possívelverificar que a abordagem consegue economizar aproximadamente 19%, 30% e 5% de energiano cenário de teste 2 e 22%, 31% e 6% no cenário de teste 3 para as aplicações MPEG, SegImge PIP respectivamente.

103

Figura 5.27 Desempenho da abordagem proposta no experimento A para a aplicação SegImg


Figura 5.28 Desempenho da abordagem proposta no experimento A para a aplicação PIP

; Fonte: O Autor(2014)

5.2.7 Experimento B

Neste experimento, a abordagem proposta foi utilizada para mapear multiaplicações,onde cada aplicação é considerada uma tarefa. O objetivo deste experimento é encontrar o PEadequado para executar cada tarefa, de forma a economizar energia. As aplicações utilizadasneste experimentos são: Secure Hash Algorithm (SHA), o encoder e decoder do algoritmoRijndael, que são aplicações do benchmark Splash 2.

Como não existe dependência entre as aplicações, nesse experimento, a abordagem foiconfigurada como o cenário de teste 1 do experimento A, sem agrupamento de tarefas. E aplataforma Infinity recebeu a mesma configuração do experimento A, com tamanho 2x4, parapermite uma busca exaustiva no espaço de projeto e, assim, analisar se a abordagem proposta écapaz de encontrar soluções satisfatórias frente à melhor solução possível.

Durante este experimento, o valor médio encontrado pela abordagem proposta foi

104

comparado com o pior e o melhor mapeamento. O pior e o melhor mapeamento foramencontrados por meio de uma busca exaustiva por todo o espaço de projeto. Esse espaço de projetopode ser visualizado no gráfico da Figura 5.29, e os valores do pior mapeamento, mapeamentoinicial e do melhor mapeamento são apresentados na Tabela 5.17. Onde o mapeamento inicial,apresentado na Figura 5.30, foi encontrado de forma aleatória.

Figura 5.29 Espaço de projeto do experimento B


Figura 5.30 Mapeamento inicial para o experimento B


Tabela 5.17 Resultados do mapeamentos do espaço de projetoPior Inicial Melhor

Tráfego Energia Tráfego Energia Tráfego Energia(pacotes) (J) (pacotes) (J) (pacotes) (J)149647 0,31 116663 0,20 76003 0,12

105

Para encontrar os valores médios do tráfego e da energia, foi gerada uma amostra com 41soluções. O tamanho dessa amostra foi definido pela Equação 5.1. E para o cálculo do tamanhoda amostra foi utilizado um nível de confiança de 95% e um erro tolerável de 10% sobre o desviopadrão e a média do espaço de projeto da Figura 5.31. A Tabela 5.18 apresenta todas as soluçõesda amostra e a média (X̄) e o desvio padrão (σ ) para os valores de tráfego e energia.

Por meio do valor médio apresentado pela Tabela 5.18, é possível verificar que aabordagem proposta consegue economizar aproximadamente 43% quando comparado como mapeamento inicial. Para tentar facilitar a visualização, a Figuras 5.31 apresenta um gráficoque mostram os valores inicial, médio e os valores da amostra deste experimento.

Figura 5.31 Amostra da abordagem para o experimento B


Também, durante esse experimento, foi feita uma comparação com o valor médioencontrado pelo SA. Para encontrar o valor médio do SA, foi gerada uma amostra com 41soluções. Este cálculo foi feito por meio da Equação 5.1. Essa amostra pode ser visualizada naTabela 5.18. Analisando o valor médio encontrado SA e comparando com o mapeamento inicial,é possível calcular que o SA consegue economizar aproximadamente 42% da energia consumida.Para facilitar a visualização, foi gerado um gráfico (Figura 5.32) que mostra os valores inicial,médio e os valores da amostra do SA.

Como já foi mostrado, o experimento faz um exploração completa do espaço de projeto.Com o objetivo de comparar os valores médios encontrados pela abordagem proposta e peloSA com o pior e o melhor mapeamento do espaço de projeto. Estas comparações podem seranalisadas na Figura 5.33, que mostram estes valores.

Com base nos resultados apresentados pelos experimentos realizados, é possível concluirque a abordagem proposta é capaz de encontrar, em média, soluções que reduzem o consumo deenergia se comparado com o pior e o mapeamento inicial e encontra resultados médios muitopróximos do valor ótimo (melhor mapeamento). E, para facilitar a análise desse resultados, foigerado um gráfico que mostra todas as comparações. Tal gráfico pode ser visualizado na Figura

106

Tabela 5.18 Amostra do cenário de teste para o experimento BAbordagem SA

Tráfego Energia Tráfego Energia(pacotes) (J) (pacotes) (J)

1 76293 0,12 76615 0,102 78933 0,11 85772 0,133 78933 0,11 76219 0,104 78548 0,12 80233 0,115 80061 0,13 79537 0,136 85772 0,13 79398 0,127 78821 0,11 76491 0,118 76293 0,12 85465 0,129 76409 0,11 79055 0,1110 80233 0,11 85864 0,1211 76409 0,10 76491 0,1112 76219 0,10 76219 0,1013 78933 0,11 80061 0,1314 78548 0,12 78933 0,1115 76409 0,11 79701 0,1116 85772 0,13 76409 0,1017 78327 0,13 85524 0,1218 78368 0,12 79774 0,1119 78368 0,12 76409 0,1020 76491 0,11 80061 0,1321 79398 0,12 85772 0,1322 78368 0,12 78933 0,1123 79055 0,11 79055 0,1124 76409 0,11 76219 0,1025 80576 0,12 79701 0,1126 76409 0,10 78548 0,1227 76615 0,10 80008 0,1228 76409 0,10 80233 0,1129 78821 0,11 78368 0,1230 79055 0,11 78550 0,1131 80576 0,12 79774 0,1132 79774 0,11 78548 0,1233 79701 0,11 79398 0,1234 76409 0,10 76491 0,1135 80008 0,12 80061 0,1336 79701 0,11 78548 0,1237 76219 0,10 78821 0,1138 85524 0,12 78550 0,1139 85465 0,12 76003 0,1240 76003 0,12 79055 0,1141 80008 0,12 79774 0,11X̄ 78894 0,11 79381 0,12σ 2680 0,01 2737 0,01

107

Figura 5.32 Amostra do SA para o experimento B


Figura 5.33 Exploração do espaço de projeto do experimento B


5.34.Para comparar a abordagem com o SA, foi utilizado o tempo necessário para encontrar

uma solução. Em média, a abordagem proposta leva 1 ms para encontrar uma solução e o SAutilizado leva em média 10 s. Com isso, é possível concluir que a abordagem proposta é maisrápida do que o SA para encontra uma solução. Mostrando que o SA é uma meta-heurística queprecisa de mais tempo de execução para evitar o mínimo local. Ou seja, com mais tempo deexecução o SA pode encontrar soluções melhores.

5.2.8 Experimento C

Neste experimento, a abordagem proposta também mapear multiaplicações, comono experimento B, onde cada aplicação é considerada uma tarefa. As aplicações utilizadasneste experimentos são: SHA, o encoder e decoder do algoritmo Rijndael e o algoritmo

108

Figura 5.34 Comparação do tráfego e energia da abordagem com o espaço de projeto do experimento B


Blowfish. Como nas multiaplicações não existe dependência entre as aplicações, a abordagem foiconfigurada sem agrupamento de tarefas. E a plataforma Infinity foi configurada com tamanho4x4.

O mapeamento inicial utilizados neste experimento foram encontrados, aleatoriamente,da mesma forma que os experimentos anteriores. Esse mapeamento podem ser vistos na Figura5.35. E as informações desses mapeamentos são apresentadas na Tabela 5.19.

Figura 5.35 Mapeamento inicial para o experimento C


Tabela 5.19 Informações do mapeamento inicial para o experimento CTráfego Energia(pacotes) (J)13994010 8,21

Para encontrar os valores médios do tráfego e da energia, foi gerada uma amostra inicial

109

com 11 soluções. E analisando esta amostra inicial apresentada na Tabela 5.20, é possívelverificar que o nu apresenta um bom nível de confiança, onde nu > n e o valor de n foi calculadopor meio da Equação 5.1, que encontrou um n ∼= 9,52 para um nível de confiança de 95% eum erro tolerável de 5% da média da amostra. A Tabela 5.20 apresenta todas as soluções daamostra e a média (X̄) e o desvio padrão (σ ) para os valores de tráfego e energia. Por meiodo valor médio apresentado pela Tabela 5.20, é possível verificar que a abordagem propostaconsegue economizar aproximadamente 16% quando comparado com o mapeamento inicial.Para tentar facilitar a visualização, a Figuras 5.36 apresenta um gráfico que mostram os valoresinicial, médio e os valores da amostra deste experimento.

Tabela 5.20 Amostra do experimento CTráfego Energia Tempo(pacotes) (J) (ms)

1 1386303 8,09 1,282 1173314 6,13 1,153 1394010 8,21 1,304 1394010 8,21 1,305 1394010 8,21 1,306 1094060 6,05 1,127 1394010 8,21 1,308 1394010 8,21 1,309 1394010 8,21 1,3010 1386303 8,09 1,2811 1386303 8,09 1,28X̄ 1344577 7,79 1,26σ 105818,09 0,84 0,07

Figura 5.36 Amostra da abordagem para o experimento C


110

5.3 CONCLUSÕES SOBRE OS EXPERIMENTOS REALIZADOS

Portanto é possível concluir através dos três experimentos realizados neste capítulo que aabordagem proposta consegue encontrar soluções satisfatórias que minimiza na média o consumode energia da NoC. Durantes dos experimentos é possível também concluir que a estrategiade agrupar tarefas comunicantes antes do mecanismo de mapeamento permite a diminuição demensagem na rede reduzindo assim a comunicação na NoC e consequentemente reduzindo assima energia consumida pela comunicação da plataforma.

111111111

6Conclusões e Trabalhos Futuros

Neste Capítulo, são apresentadas as principais conclusões do trabalho e algumas sugestõesde trabalhos futuros.

6.1 CONCLUSÕES

O problema de mapeamento de tarefas em uma infraestrutura de comunicação, baseadaem NoC, influencia diretamente o desempenho da plataforma MPSoC, seja em termo dedesempenho ou em consumo de energia. Como o problema de mapeamento é um problemaNP-díficil, ou seja, não pode ser resolvido em tempo polinomial e deve ser resolvido com a ajudade uma ferramenta computacional, então este trabalho busca contribuir na resolução do problemade mapeamento de tarefas de forma a minimizar o consumo de energia na comunicação.

A abordagem que foi desenvolvida neste trabalho busca reduzir o consumo de energiada NoC, diminuindo o volume de mensagens (pacotes) trafegadas na rede. A metodologiaadotada analisa a dependência entre as tarefas da aplicação e a infraestrutura da plataformaMPSoC. Dessa forma a abordagem tem como entrada um modelo da aplicação, da plataforma edo consumo de energia. Com esses modelos a abordagem pode mapear as tarefas na plataformaMPSoC e estimar a energia da rede-em-chip (NoC).

O ponto de complexidade encontrado, durante o desenvolvimento do trabalho, estárelacionado à modelagem do consumo de energia da infraestrutura de comunicação, já que aplataforma alvo é modelada em alto nível de abstração (TLM), e a estimativa de consumo deenergia em alto nível é bastante diferente da estimativa obtida em um modelo RTL (baixo nívelde abstração e com precisão de ciclos). Por esse motivo, foi incorporada à plataforma Infinity,uma NoC em nível RTL para que fosse possível estimar o consumo de energia da NoC. O modelode consumo de energia definido no trabalho está relacionado com o tráfego de mensagens narede.

A abordagem apresentada tem como ponto central agrupar as tarefas que se comunicammais, no mesmo núcleo, limitando o número máximo de tarefas por núcleo, antes de aplicara técnica de mapeamento. O mecanismo de agrupamento é utilizado para diminuir a troca de

112

mensagem na rede, já que as mensagens trafegadas pela rede (NoC) são mensagens de coerênciade cache e a comunicação entre as tarefas se faz por meio de variáveis compartilhadas. Então,agrupando tarefas comunicantes, é possível diminuir a quantidade de mensagens na rede e,consequentemente, a energia consumida pela NoC da plataforma. Mesmo sendo um pontocentral da abordagem o mecanismo de agrupamento de tarefas pode ser configurado para nãoagrupar tarefas ou limitar um número máximo de tarefas por PE.

Analisando os experimentos realizados nos cenários de teste, é possível verificar quea utilização do mecanismo de agrupamento em conjunto com o mecanismo de mapeamentoconsegue reduzir em média a energia consumida pela rede em 47% dependendo da configuraçãodo mecanismo de agrupamento (quantidade de tarefas por processador). E quando o mecanismode agrupamento é desligado (uma tarefa por PE) a abordagem consegue em média reduzira energia consumida pela NoC em 44%. Também foi possível verificar nos experimentosque a abordagem proposta consegue encontrar soluções boas, quando comparamos a soluçãoencontrada com a melhor e pior solução do espaço de projeto.

Este trabalho abriu algumas novas frentes de pesquisa para o grupo de pesquisa deEngenharia da Computação do Centro de Informática da Universidade Federal de Pernambuco, eque podem ser desenvolvidas em diversos trabalhos futuros, incluindo:

(i) Extração automática de dependência de tarefas de uma aplicação, por meio de umaespecificação da aplicação;

(ii) Avaliação do processo de agrupamento de tarefas, de forma a atender melhor aos requisitosde projetos que não são atendidos;

(iii) Refinamento do modelo de consumo de energia da NoC, para que seja possível estimarcom mais precisão o consumo de energia em alto nível de abstração;

(iv) Proposta de infraestrutura de comunicação com baixo consumo de energia, como utilizaçãode várias frequências e tensões em uma NoC.

113113113

REFERÊNCIAS

AL-SHARAA, B.; AL-QUBLAN, T. Bounded Ant Colony Algorithm for Task Allocation aNetwork of Homogeneous Processor Using a Primary Site (BTS-ACO). International Journalof Computer Science & Information Technology (IJCSIT), [S.l.], v.5, 2013.

ALMEIDA, G. M. et al. Evaluating the impact of task migration in multi-processorsystems-on-chip. In: SBCCI. Anais. . . [S.l.: s.n.], 2010. p.73–78.

ASCIA, G.; CATANIA, V.; PALESI, M. A Multi-Objective Generic Approach to MappingProblem on Network-on-Chip. In: Anais. . . [S.l.: s.n.], 2006. v.12, n.4, p.370–394.

BECKERS, R.; DENEUBOURG, J. L.; GOSS, S. "Trails and U-turns in the Selection of theShortest Path by the Ant Lasius Niger". Journal of Theoretical Biology, v. 159, [S.l.],p.397–415, 1992.

BENINI, L.; MICHELLI, G. de. Networks on chips : technology and tools. [S.l.]: ElsevierMorgan Kaufmann Publishers, 2006. 408p. (The Morgan Kaufmann series in systems onsilicon).

BJERREGAARD, T.; MAHADEVAN, S. A survey of research and practices ofNetwork-on-chip. ACM Computing Surveys, [S.l.], v.38, n.1, 2006.

COLORNI, A.; DORIGO, M.; MANIEZZO, V. Distributed optimization by ant colonies. In:Anais. . . [S.l.: s.n.], 1991.

DALLY, W. J.; TOWLES, B. Route packets, not wires: on-chip interconnection networks.Proceedings of the 38th annual Design Automation Conference, [S.l.], p.684–689, 2001.

DALLY, W. J.; TOWLES, B. P. Principles and practices of interconnection networks. [S.l.]:Elsevier, 2004.

DORIGO, M. Optimization, Learning and Natural Algorithms (in Italian). Milan, Italy,1992.

DORIGO, M.; STüTZLE, T. Ant Colony Optimization. Cambridge, MA: MIT Press, 2004.

FERNANDEZ-ALONSO, E. et al. Survey of NoC and Programming Models Proposals forMPSoC. In: Anais. . . [S.l.: s.n.], 2012. v.9, n.2, p.22–32.

GHOSH, P.; SEN, A.; HALL, A. Energy Efficient Application Mapping to NoC ProcessingElements Operating at Multiple Voltage Levels. In: NETWORKS-ON-CHIP, 2009. NOCS 2009.3RD ACM/IEEE INTERNATIONAL SYMPOSIUM ON. Anais. . . [S.l.: s.n.], 2009. p.80–85.

GUERRIER, P.; GREINER, A. A generic architecture for on-chip packet-switchedinterconnections. In: DESIGN, AUTOMATION AND TEST IN EUROPE CONFERENCEAND EXHIBITION 2000. PROCEEDINGS. Anais. . . [S.l.: s.n.], 2000. p.250–256.

HEMANI, A. et al. Network on Chip: an architecture for billion transistor era. In:PROCEEDING OF THE IEEE NORCHIP CONFERENCE. Anais. . . [S.l.: s.n.], 2000.

114

HENNESSY, J. L.; PATTERSON, D. A. Computer Architecture: a quantitative approach.5nd.ed. [S.l.]: Morgan Kaufmann Publishers, Inc, 2012. 493p.

HU, J.; MARCULESCU, R. Energy-aware mapping for tile-based NoC architectures underperformance constraints. In: DESIGN AUTOMATION CONFERENCE, 2003. PROCEEDINGSOF THE ASP-DAC 2003. ASIA AND SOUTH PACIFIC. Anais. . . [S.l.: s.n.], 2003. p.233–239.

HU, J.; MARCULESCU, R. Energy- and performance-aware mapping for regular NoCarchitectures. In: COMPUTER-AIDED DESIGN OF INTEGRATED CIRCUITS ANDSYSTEMS, IEEE TRANSACTIONS ON. Anais. . . [S.l.: s.n.], 2005. v.24, n.4, p.551–562.

HUANG, J. et al. Energy-Aware Task Allocation for Network-on-Chip Based HeterogeneousMultiprocessor Systems. In: PARALLEL, DISTRIBUTED AND NETWORK-BASEDPROCESSING(PDP), 2011 19TH EUROMICRO INTERNATIONAL CONFERENCE ON.Anais. . . [S.l.: s.n.], 2011. p.447–454.

HöLLDOBLER, B.; WILSON, E. The Ants. [S.l.]: Belknap Press, 1990. 746p.

ISSCC. ISSCC 2013 Tech Trends. [S.l.]: ISSCC’13, 2013.

JAIN, R. The art of computer systems performance analysis - techniques for experimentaldesign, measurement, simulation, and modeling. [S.l.]: Wiley, 1991. I-XXVII, 1-685p.(Wiley professional computing).

JANTSCH, A.; TENHUNEN, H. Network on Chip. [S.l.]: Klumer Academic Publishers, 2003.

JENA, R.; SHARMA, G. A Multi-Objective Evolutionary Algorithm Based Optimization Modelfor Network-on-Chip Synthesis. In: INFORMATION TECHNOLOGY, 2007. ITNG ’07.FOURTH INTERNATIONAL CONFERENCE ON. Anais. . . [S.l.: s.n.], 2007. p.977–982.

KUMAR s. et al. A network on chiparchitecture and design methodology. iISVLSI, [S.l.],p.0117, 2002.

KUROSE, J. F.; ROSS, K. W. Computer Networking: a top-down approach. 5th.ed. USA:Addison-Wesley Publishing Company, 2009.

LAPPONI, J. C. Estatística usando Excel. [S.l.]: CAMPUS - RJ, 2005.

MARCON, C. et al. Time and energy efficient mapping of embedded applications onto NoCs. In:DESIGN AUTOMATION CONFERENCE, 2005. PROCEEDINGS OF THE ASP-DAC 2005.ASIA AND SOUTH PACIFIC. Anais. . . [S.l.: s.n.], 2005. v.1, p.33–38.

MARCON, C. et al. Comparison of network-on-chip mapping algorithms targeting low energyconsumption. In: COMPUTERS & DIGITAL TECHNIQUES, IET. Anais. . . [S.l.: s.n.], 2008.v.2, n.6, p.471–482.

MARCULESCU, R. et al. Outstanding Research Problems in NoC Design: system,microarchitecture, and circuit perspectives. Computer-Aided Design of Integrated Circuitsand Systems, IEEE Transactions on, [S.l.], v.28, n.1, p.3–21, Jan 2009.

MICHELI, G. de; BENINI, L. Networks on Chip: a new paradigm for systems on chip design.Proceedings of conference on Design automation and test in Europe, [S.l.], p.418, 2002.

115

MURALI, S.; DE MICHELI, G. SUNMAP: a tool for automatic topology selection andgeneration for nocs. In: DESIGN AUTOMATION CONFERENCE, 2004. PROCEEDINGS.41ST. Anais. . . [S.l.: s.n.], 2004. p.914–919.

PALMA, J. et al. Mapping Embedded Systems onto NoCs - The Traffic Effect on DynamicEnergy Estimation. In: INTEGRATED CIRCUITS AND SYSTEMS DESIGN, 18THSYMPOSIUM ON. Anais. . . [S.l.: s.n.], 2005. p.196–201.

RIJPKEMA, E. et al. A RouterArchitectureforNetworkson Silicon. Proceedings of progress2001, 2nd Workshop on embedded systems, [S.l.], p.181–188, 2001.

RIJPKEMA, E. et al. Trade-offs in the design of a router with both guaranteed and best-effortservices for networks on chip. Computers and Digital Techniques, IEEE Proceedings, [S.l.],v.150, n.5, p.294–302, Sep 2003.

RUGIERO, M. et al. Communication-Aware Allocation and Acheduling Framework forStream-Oriented Multi-Processor System-on-Chip. In: DESIGN, AUTOMATION AND TESTIN EUROPE, 2006. DATE’06. PROCEEDINGS. Anais. . . [S.l.: s.n.], 2006. v.1, p.6 pp.–.

S. S. MUKHERJEE P. BANNON, S. L. A. S.; WEBB, D. The Alpha 21364 networkarchitecture. IEEE Micro, [S.l.], p.26–35, 2002.

SAHU, P. et al. Application Mapping onto Mesh Structured Network-on-Chip Using ParticleSwarm Optimization. In: Anais. . . [S.l.: s.n.], 2011. p.335–336.

SAHU, P. et al. Application Mapping Onto Mesh-Based Network-on-Chip Using DiscreteParticle Swarm Optimization. In: Anais. . . [S.l.: s.n.], 2014. v.22, n.2, p.300–312.

SAHU, P. K.; CHATTOPADHYAY, S. A survey on application mapping strategies forNetwork-on-Chip design. In: Anais. . . [S.l.: s.n.], 2013. v.59, n.1, p.60–76.

SINGH, A. et al. Mapping on multi/many-core systems: survey of current and emerging trends.In: DESIGN AUTOMATION CONFERENCE (DAC), 2013 50TH ACM / EDAC / IEEE.Anais. . . [S.l.: s.n.], 2013. p.1–10.

STüTZLE, T.; DORIGO, M. ACO Algorithms for the Quadratic Assignment Problem. In:CORNE, D.; DORIGO, M.; GLOVER, F. (Ed.). New Ideas in Optimization. London, UK:McGraw-Hill, 1999. p.33–50.

TILERA, C. TILE64 Processor. [S.l.]: Product Brief Description, 2007.

VANGAL, S. et al. An 80-Tile 1.28TFLOPS Network-on-Chip in 65nm CMOS. In:SOLID-STATE CIRCUITS CONFERENCE, 2007. ISSCC 2007. DIGEST OF TECHNICALPAPERS. IEEE INTERNATIONAL. Anais. . . [S.l.: s.n.], 2007. p.98–589.

WANG, J. et al. Bandwidth-Awaew Application Mapping for NoC-Based MPSoCs. In: Anais. . .[S.l.: s.n.], 2011. v.1, n.1, p.152–159.

WINGARD, D. Micronetwork-based integration for SoCs: 673. Proceedings of the 38thannual Design Automation Conference, [S.l.], p.677, 2001.

WOLF, W. The future of multiprocessor systems-on-chips. In: DESIGN AUTOMATIONCONFERENCE, 2004. PROCEEDINGS. 41ST. Anais. . . [S.l.: s.n.], 2004. p.681–685.

116

ZEFERINO, C. A.; SUSIN, A. A. SoCIN: a parametric and scalable network-on-chip. In:SYMPOSIUM ON INTEGRATED CIRCUITS AND SYSTEMS DESIGN, 16., Washington,DC, USA. Proceedings. . . IEEE Computer Society, 2003. p.169–. (SBCCI’03).

ZEFERINO, C.; SANTO, F.; SUSIN, A. ParIS: a parameterizable interconnect switch fornetworks-on-chip. In: INTEGRATED CIRCUITS AND SYSTEMS DESIGN, 2004. SBCCI2004. 17TH SYMPOSIUM ON. Anais. . . [S.l.: s.n.], 2004. p.204–209.

117117117

APÊNDICE APublicações

As publicações realizadas no período do doutorado demonstram a aceitação do presentetrabalho na comunidade científica internacional. As publicações aceitas e publicadas são listadas,juntamente com a respectiva classificação (Qualis da CAPES) na Tabela A.1.

Tabela A.1 Publicações realizadas durante o período do doutorado.Conferência Qualis PublicaçãoICECS 2013 B1 An Ant Colony Metaheuristic for Energy Aware Application Mapping on NoCs

Max Farias, Edna Barros, Abel Filho, André Araújo, André Silva and João MeloMWSCAS 2014 B1 An Approach for Multi-Task and Multi-Application Mapping Onto NoC-Based MPSoC

Max Farias, Edna Barros and André Araújo

118118118

APÊNDICE BSetup da Plataforma Infinity

Este apêndice detalha a instalação das bibliotecas e ferramentas necessárias para odesenvolvimento da plataforma Infinity.

B.1 Pré-requisitos

Todas as instruções descritas neste apêndice foram executados em uma máquina executandoo sistema operacional Ubuntu 10.04 Desktop Edition. Os pacotes necessários são:

• build-essential;

• texinfo;

• autoconf;

• automake;

• libncurses5-dev (Necessário para o GDB).

Com algumas modificações é possível executar este tutorial em outras versões do Ubuntuou distribuição Linux.

B.2 Preparação

B.2.1 Diretório Raiz da Instalação

Crie um diretório para ser o diretório raiz da instalação e salve o caminho na variável deambiente INSTALLPREFIX.

$ sudo su -# mkdir /opt/infinity# export INSTALLPREFIX = /opt/infinity

B.2.2 Diretório de Trabalho

Crie um diretório de trabalho.

119

# mkdir /tmp/build

B.2.3 Download das bibliotecas e Ferramentas

Mude para o diretório de trabalho.

# cd /tmp/build

Faça o download dos seguintes pacotes para a instalação das bibliotecas e ferramentas demodelagem:

• SystemC 2.2.0;

• Patch para SystemC (systemc-2.2.0-ubuntu10.04.patch);

• TLM 2.0.1;

• SCML 2.0;

• ArchC 2.0 beta 3.

Faça o download dos seguintes pacotes para a instalação do toolchain GNU:

• Binutils 2.20.1;

• GCC Core 4.5.1;

• G++ 4.5.1;

• NewLib 1.18.0;

• MPFR 2.4.2;

• GMP 5.0.1;

• MPC 0.8.2;

• GDB 7.2 (opcional);

B.2.4 Instalação das bibliotecas e Ferramentas

Esta seção detalha a instalação do SystemC, TLM, SCML e ArchC.

120

# tar zxf systemc-2.2.0.tgz

# cd systemc-2.2.0

# patch - p1 < ../systemc-2.2.0-ubuntu10.04.patch

# aclocal# autoconf# automake

B.2.4.1 SystemC

Descompacte o pacote systemc-2.2.0.tgz.Mude para o diretório descompactado.Aplique o patch.Recrie o sistema de build.Edite o arquivo Makefile.in para remover a linha 95.Crie um diretório temporário.

# mkdir objdir

Mude para o diretório temporário.

# cd objdir

Crie o diretório de destino.

# mkdir -p $INSTALLPREFIX/lib/systemc-2.2.0

Execute a configuração com os parâmetros a seguir.

# ../configure –prefix = $INSTALLPREFIX/lib/systemc-2.2.0

Compile e instale.

# make# make install

Volte para o diretório de trabalho.

# cd ../..

B.2.4.2 TLM

Descompacte o pacote.Copie o diretório descompactado para o diretório de instalação.

121

# tar axf TLM-2.0.1.tgz

# cp -R TLM-2009-07-15 $INSTALLPREFIX/lib

B.2.4.3 SCML

Descompacte o pacote.

# tar zxf scml-2.0-pv.tgz

Mude para o diretório descompactado.

# cd scml-2.0

Crie um diretório temporário.

# mkdir objdir


# cd objdir

Crie o diretório de destino.

# mkdir -p $INSTALLPREFIX/lib/scml-2.0

Execute a configuração com os parâmetros a seguir:

# ../ configure –prefix = $INSTALLPREFIX/lib/scml-2.0–with-systemc = $INSTALLPREFIX/lib/systemc-2.2.0–with-tlm = $INSTALLPREFIX/lib/TLM-2009-07-15/include/tlm

Compile e instale.



# cd ../..

122

# tar xf archc-2.0beta3-sync.tar# tar jxf binutils-2.20.1.tar.bz2

# mkdir -p $INSTALLPREFIX/src# cp -R binutils-2.20.1 $INSTALLPREFIX/src

# cd archc-2.0beta3-sync

# ./configure –prefix = $INSTALLPREFIX–with-systemc = $INSTALLPREFIX/lib/systemc-2.2.0–with-tlm = $INSTALLPREFIX/lib/TLM-2009-07-15/include/tlm–with-binutils = $INSTALLPREFIX/src/binutils-2.20.1


B.2.4.4 ArchC

Descompacte o pacote do ArchC e do Binutils. O ArchC utiliza o código-fonte doBinutils.

Copie o fonte do Binutils para o diretório src no diretóio de instalação.Mude para o diretório descompactado do ArchC.Execute a configuração com os parâmetros a seguir.Compile e instale.Volte para o diretório de trabalho.

# cd ..

B.2.5 Instalação do toolchain GNU

Esta seção detalha a instalação do GCC e GDB.Crie as variáveis de ambiente conforme a seguir. Para cada target desejado, repita todas

as instruções desta seção.

# export TARGET = sparc# export PATH = $INSTALLPREFIX/bin : $PATH

B.2.5.1 Binutils

Crie um diretório temporário para a compilação.

# mkdir build-binutils


123

# cd build-binutils

# ../binutils-2.20.1/configure –prefix = $INSTALLPREFIX–target = $TARGET-elf –disable-nls

Execute a configuração com os parâmetros a seguir.Compile e instale.

# make all# make install


# cd ..

B.2.5.2 GCC (Parte 1)

Descompacte os pacotes.

# tar jxf gcc-core-4.5.1.tar.bz2# tar jxf gcc-g++-4.5.1.tar.bz2# tar jxf mpfr-2.4.2.tar.bz2# tar jxf mp-5.0.1.tar.bz2# tar zxf mpc-0.8.2.tar.gz

Mova o diretório descompactado das bibliotecas MPFR, GMP e MPC para o diretório doGCC.

# mv mpfr-2.4.2 gcc-4.5.1/mpfr# mv gmp-5.0.1 gcc-4.5.1/gmp# mv mpc-0.8.2 gcc-4.5.1/mpc


# mkdir build-gcc


# cd build-gcc


# ../gcc-4.5.1/configure –prefix = $INSTALLPREFIX–target = $TARGET-elf –with-gnu-as –with-gnu-ld– with-newlib –enable-languages = c,c++ –disable-nls

124

# make all-gcc# make install-gcc

# make all-target-libgcc# make install-target-libgcc

Case não tenha baixado o pacote opcional do G++, use apenas –enable-languages=c.Compile e instale o compilador.Compile e instale a libgcc.Volte para o diretório de trabalho.

# cd ..

B.2.5.3 Newlib


# tar zxf newlib-1.18.0.tar.gz


# mkdir build-newlib


# cd build-newlib


# ../newlib-1.18.0/configure –prefix = $INSTALLPREFIX– target = $TARGET-elf –disable-nls

Compile e instale.



# cd ..

B.2.5.4 GCC (Parte 2)

Mude para o diretório temporário.Compile e instale.Volte para o diretório de trabalho.

125

# cd build-gcc


# cd ..

B.2.5.5 GDB


# tar jxf gdb-7.2.tar.bz2


# mkdir build-gdb


# cd build-gdb


# ../gdb-7.2/configure –prefix = $INSTALLPREFIX –target = $TARGET-elf –disable-nls

Compile e instale.



# cd ..

Apague o diretório de trabalho para salvar espaço.

# cd ..# rm - rf build

uma abordagem meta-heurÍstica para o mapeamento … · 2019. 10. 25. · catalogação na fonte...

Documents