Uma abordagem meta-heurística para o mapeamento de tarefas em uma plataforma MPSoC baseada em NoC

UMA ABORDAGEM META-HEURÍSTICA PARA O

MAPEAMENTO DE TAREFAS EM UMA PLATAFORMA

MPSOC BASEADA EM NOC

Centro de Informática

Ciência da Computação

Max Santana Rolemberg Farias

UMA ABORDAGEM META-HEURÍSTICA PARA O MAPEAMENTO

DE 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

RECIFE 2014

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.

Max Santana Rolemberg Farias

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

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 estresses quando 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. Max Vinícius e Maria Eduarda, papai ama muito vocês. Também não posso esquecer de agradecer aos 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 que tive o prazer de conhecer e conviver, que me ensinou muito durante estes anos. Agradeço a sua paciência, as observações, os comentários, as críticas, as broncas, o incentivo e todo o conhecimento que adquiri durante o desenvolvimento deste trabalho, que contribuíram para o meu desenvolvimento pessoal e profissional. Profª. Edna agradeço-lhe a confiança e espero ter atendido às suas expectativas.

Não poderia esquecer-me do pessoal do laboratório C23 do Centro de Informática da Universidade Federal de Pernambuco (CIn/UFPE), onde encontrei a amizade e o companheirismo de muitos outros estudantes (não tem como citar nomes). Não consigo imaginar o término deste doutorado sem as discussões sobre diversos assuntos e, principalmente, sem as trocas de experiências. Agradeço aos meus companheiros de publicações: André Aziz, André Olivino e João Erick. Valeu pela força. Foi muito legal trabalhar com vocês. Também não poderia esquecer 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 ajudou na 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 proporcionado pela FACEPE, que também foi muito imprescindível.

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 o meio de comunicação tradicional (barramento) possui uma largura de banda limitada e não são escalá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 em plataformas MPSoC baseado em NoC é o custo de comunicação, pois esse custo de comunicação depende do mapeamento de tarefas nos processadores. Este trabalho apresenta uma abordagem que 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 o mapeamento de tarefas de aplicações e, em alguns experimentos, os resultados foram comparados com o pior e o melhor mapeamento do espaço de projeto. Os resultados encontrados durante os experimentos mostram uma redução média de energia de 47% quando é utilizado o mecanismo de agrupamento de tarefas e 44% quando o mecanismo de agrupamento é desligado.

Abstract

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

Lista de Figuras

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

1.2 Número de processadores por chip. . . 25

2.1 Plataforma MPSoC genérica . . . 27

2.2 Plataforma MPSoC baseada em barramento simples . . . 28

2.3 Plataforma MPSoC baseada em barramentos hierárquicos . . . 28

2.4 Plataforma MPSoC baseada em NoC . . . 29

2.5 Fluxo Genérico do projeto de um MPSoC . . . 29

2.6 Principais componentes de uma Plataforma MPSoC baseada em NoC . . . 31

2.7 Fluxo dos dados através da NoC . . . 32

2.8 Interface de rede Network Interface Controller (NIC) . . . 32

2.9 Formato de uma mensagem . . . 34

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

2.11 Rede indireta: (a) árvore (b) anel . . . 35

2.12 Mapeamento de tarefas em uma plataforma MPSoC . . . 38

2.13 Modelo de uma aplicação . . . 39

2.14 Modelo de uma plataforma MPSoC 2x2 . . . 39

2.15 Plataforma Infinity . . . 41

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

2.17 Organização da interface de rede . . . 43

2.18 Estrutura da mensagem da plataforma Infinity . . . 45

3.1 Fluxo do projeto implementado porJENA; SHARMA(2007) . . . 57

3.2 Algoritmo ACO implementado porWANG et al.(2011) . . . 60

3.3 Algoritmo PSO implementado porSAHU et al.(2014) . . . 62

4.1 Fluxo da Proposta . . . 66

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

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 . . . 67

4.4 Algoritmo para gerar o grafo inverso do GDT . . . 68

4.5 Um exemplo de agrupamento de tarefas: (a) GDT, (b) GDT’ e (c) Grafo colorido 69 4.6 Algoritmo de coloração de vértices . . . 70

mínimo. . . 76

4.9 Algoritmo Colônia de Formiga . . . 77

4.10 Fluxo de Construção de uma Solução pelo Ant Colony Optimization (ACO) . . 78

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

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

4.13 Um exemplo de construção de uma solução . . . 81

5.1 Fluxo do projeto usando PowerPlay . . . 86

5.2 Placa DE2-70 com o filtro amplificador . . . 86

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

5.4 GDT da aplicação MPEG . . . 88

5.5 GDT da aplicação SegImg . . . 89

5.6 GDT da aplicação PIP . . . 89

5.7 Mapeamento inicial para o cenário de teste 1 (a) MPEG, (b) SegImg e (c) PIP . 90 5.8 Amostra da aplicação MPEG para o cenário de teste 1 . . . 92

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

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

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

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

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

5.14 Mapeamento inicial para o cenário de teste 2 (a) MPEG, (b) SegImg e (c) PIP . 95 5.15 Amostra da aplicação MPEG para o cenário de teste 2 . . . 96

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

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

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

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

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

5.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 . . . 99

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

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

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

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

5.26 Desempenho da abordagem proposta no experimento A para a aplicação MPEG 102 5.27 Desempenho da abordagem proposta no experimento A para a aplicação SegImg 103 5.28 Desempenho da abordagem proposta no experimento A para a aplicação PIP . . 103

5.29 Espaço de projeto do experimento B . . . 104

5.32 Amostra do SA para o experimento B . . . 107 5.33 Exploração do espaço de projeto do experimento B . . . 107 5.34 Comparação do tráfego e energia da abordagem com o espaço de projeto do

experimento B . . . 108 5.35 Mapeamento inicial para o experimento C . . . 108 5.36 Amostra da abordagem para o experimento C . . . 109

Lista de Tabelas

2.1 Características de uma NoC . . . 34

2.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 . . . 47

3.2 Atividades de uma tarefa da aplicação . . . 48

3.3 Funções modeladas porGHOSH; SEN; HALL(2009) . . . 50

3.4 Variáveis utilizadas porGHOSH; SEN; HALL(2009) . . . 50

3.5 Variáveis da formulação Integer Linear Programming (ILP) proposta porHUANG et al.(2011) . . . 52

3.6 Propriedades da aresta ai j do grafo de características da aplicação . . . 53

3.7 Propriedades da aresta ri j do grafo de características da plataforma . . . 54

3.8 Funções utilizadas pelo operador de mutação do Strength Pareto Evolutionary Algorithm(SPEA) . . . 56

3.9 Aplicações e configurações da plataforma . . . 62

3.10 Comparação do custo e desempenho . . . 62

3.11 Trabalhos relacionados baseados em métodos exatos . . . 63

3.12 Trabalhos relacionados baseados em busca . . . 63

3.13 Analise comparativa dos trabalhos baseados em métodos exatos . . . 63

3.14 Analise comparativa das meta-heurísticas baseadas em busca . . . 64

3.15 Analise comparativa dos algoritmos baseados em inteligência coletiva . . . 64

4.1 Tabela de feromônio inicial . . . 80

4.2 Tabela de fluxo . . . 80

4.3 Passo 1 do exemplo de construção de uma solução . . . 80

4.4 Passo 2 do exemplo de construção de uma solução . . . 81

4.5 Passo final do exemplo de construção de uma solução . . . 82

4.6 Soluções encontradas para o exemplo . . . 82

4.7 Tabela de feromônio atualizada . . . 82

4.8 Analise comparativa da abordagem proposta com os trabalhos relacionados . . 83

5.1 Configurações da NoC SoCIN . . . 84

5.2 Configuração do mecanismo de mapeamento de tarefas . . . 85

5.3 Estimativas do PowerPlay Analyzer sobre uma NoC . . . 87

5.4 Parâmetros de configuração do ambiente de medição . . . 87

5.5 Potências dissipadas pela NoC . . . 87

5.8 Amostra inicial para o cenário de teste 1 . . . 91

5.9 Informações do mapeamento inicial das aplicações para o cenário de teste 2 . . 94

5.10 Valores de n . . . 95

5.11 Amostras para o cenário de teste 2 . . . 95

5.12 O melhor e o pior mapeamento para o MPEG no cenário de teste 2 . . . 97

5.13 O melhor e o pior mapeamento para o SegImg no cenário de teste 2 . . . 97

5.14 O melhor e o pior mapeamento para o PIP no cenário de teste 2 . . . 97

5.15 Informações do mapeamento inicial das aplicações na seção de teste 3 . . . 99

5.16 Amostra inicial da seção de teste 3 . . . 100

5.17 Resultados do mapeamentos do espaço de projeto . . . 104

5.18 Amostra do cenário de teste para o experimento B . . . 106

5.19 Informações do mapeamento inicial para o experimento C . . . 108

5.20 Amostra do experimento C . . . 109

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

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

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

Sumário

1 INTRODUÇÃO 21

1.1 MOTIVAÇÃO . . . 23

1.2 ORIGINALIDADE E OBJETIVOS DO TRABALHO . . . 25

1.3 ORGANIZAÇÃO DO TRABALHO . . . 26

2 CONCEITOS BÁSICOS 27 2.1 PLATAFORMA MPSOC . . . 27

2.1.1 Fluxo Genérico do Projeto de uma Plataforma MPSoC . . . 29

2.2 PLATAFORMA MPSOC BASEADA EM NOC . . . 30

2.3 NETWORK-ON-CHIP (NoC) . . . 30

2.3.1 Arquitetura de uma NoC . . . 31

2.3.1.1 Interface de rede (NIC) . . . 32

2.3.1.2 Roteador . . . 33

2.3.1.3 Enlace . . . 33

2.3.1.4 Mensagens e pacotes . . . 33

2.3.2 Características Gerais de uma NoC . . . 33

2.3.2.1 Topologia . . . 34 2.3.2.2 Roteamento . . . 36 2.3.2.3 Chaveamento . . . 36 2.3.2.4 Controle de fluxo . . . 36 2.3.2.5 Arbitragem . . . 37 2.3.2.6 Memorização . . . 37

2.4 MAPEAMENTO DE TAREFAS EM UMA PLATAFORMA MPSOC . . . 37

2.4.1 Modelo da Aplicação . . . 38

2.4.2 Modelo da Plataforma . . . 38

2.4.3 Definição do Problema . . . 39

2.5 A PLATAFORMA MPSOC INFINITY . . . 40

2.5.1 Descrição da Plataforma Infinity . . . 40

2.5.1.1 Núcleo infinity . . . 41

2.5.1.2 Interface de rede (NIC) . . . 42

2.5.1.3 Modelo de mensagens . . . 43

3.1 BASEADOS EM TÉCNICAS EXATAS . . . 46

3.1.1 Uma Abordagem Exata para Alocar e Escalonar Tarefas . . . 46

3.1.1.1 Etapa de alocação de tarefas . . . 46

3.1.1.2 Etapa de escalonamento de tarefas . . . 47

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

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

3.2 MAPEAMENTO BASEADO EM BUSCA . . . 53

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

3.2.2 Uma Abordagem Multiobjetivo para o Problema de Mapeamento . . . 55

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

3.2.3.1 Etapa de alocação de tarefas em PE . . . 56

3.2.3.2 Etapa de alocação de PE em tiles . . . 57

3.2.4 Algoritmos de Mapeamento para MPSoC Baseada em NoC . . . 58

3.2.5 Uma Abordagem ACO para o Mapeamento de Tarefas . . . 59

3.2.6 Uma Abordagem Particle Swarm Optimization (PSO) para o Mapeamento de Tarefas 61 3.3 ANALISE DOS TRABALHOS RELACIONADOS . . . 62

3.3.1 Mapeamento Exato . . . 63

3.3.2 Mapeamento Baseado em Busca . . . 64

4 ABORDAGEM PROPOSTA 65 4.1 VISÃO GERAL . . . 65

4.2 FASE DE EXTRAÇÃO DE GRAFOS . . . 66

4.2.1 Grafo de Características da Plataforma . . . 66

4.2.2 Grafo de Dependências entre Tarefas . . . 67

4.3 FASE DE AGRUPAMENTO DE TAREFAS . . . 68

4.3.1 Mecanismo de Agrupamento de Tarefas . . . 68

4.3.1.1 Algoritmo de coloração de grafos . . . 69

4.4 FASE DO MAPEAMENTO INICIAL . . . 69

4.4.1 Grafo de Comunicação de Tarefas . . . 70

4.5 FASE DE OTIMIZAÇÃO DO MAPEAMENTO . . . 70

4.5.1 Modelo de Energia . . . 71

4.5.1.1 Medição de potência em FPGA . . . 71

4.5.1.2 Ambiente de medição . . . 72

4.5.1.3 Energia da NoC . . . 73

4.5.2 Mecanismo de Mapeamento de Tarefas . . . 74

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

5.1 ORGANIZAÇÃO DA PLATAFORMA INFINITY . . . 84

5.2 EXPERIMENTOS . . . 84

5.2.1 Mecanismo de Mapeamento . . . 85

5.2.2 Ambiente de Medição de Potência . . . 85

5.2.3 Análise Estatística . . . 87

5.2.4 Experimento A . . . 88

5.2.4.1 Aplicação MPEG . . . 88

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

5.2.4.3 Aplicação PIP . . . 89

5.2.5 Cenários de Teste do Experimento A . . . 90

5.2.5.1 Cenário de teste 1 . . . 90

5.2.5.2 Cenário de teste 2 . . . 93

5.2.5.3 Cenário de teste 3 . . . 98

5.2.6 Análise dos Resultados do Experimento A . . . 102

5.2.7 Experimento B . . . 103

5.2.8 Experimento C . . . 107

5.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 . . . 118

B.2 Preparação . . . 118

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

B.2.2 Diretório de Trabalho . . . 118

B.2.3 Download das bibliotecas e Ferramentas . . . 119

B.2.4 Instalação das bibliotecas e Ferramentas . . . 119

B.2.4.1SystemC . . . 120

B.2.4.2TLM . . . 120

B.2.4.3SCML . . . 121

B.2.5.1Binutils . . . 122

B.2.5.2GCC (Parte 1) . . . 123

B.2.5.3Newlib . . . 124

B.2.5.4GCC (Parte 2) . . . 124

1

INTRODUÇÃO

O avanço da tecnologia de fabricação de circuitos integrados permitiu o aumento do nível de integralização entre os componentes em um circuito integrado, com a possibilidade de 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 e extremamente 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 sistema com relação ao tempo de execução, já que as comunicações entre os componentes de um SoC podem 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 projeto SoC é baseado no reuso de núcleos de hardware (Intellectual Property (IP)), que são módulos pré-projetados e pré-validados. E o reuso desses núcleos pode garantir um tempo menor para a chegada do produto ao mercado, ou seja, é possível amortizar os custos do projeto entre os diversos 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 da complexidade 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 embarcados que precisam de uma plataforma com múltiplos elementos de processamento (multicores) com funcionalidades específicas que refletem a necessidade da aplicação. O principal objetivo de um MPSoC é permitir uma maior utilização do paralelismo, ou seja, permite que seja executada uma aplicação paralela ou, até mesmo, várias aplicações em paralelo.

Atualmente, as aplicações para sistemas embarcados estão cada vez mais utilizando mú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 uma realidade e estão presentes em várias implementações comerciais e sendo amplamente utilizados em projetos de sistemas embarcados (WOLF,2004).

comunicação, ou seja, todos os componentes são ligados uns aos outros. Tradicionalmente, a interconexã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 organizados de 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 ter um gargalo na comunicação (JANTSCH; TENHUNEN,2003). Com isso, o grande desafio de sistemas 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ão atende completamente aos requisitos das aplicações atuais, que demandam dezenas a centenas de 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 maior escalabilidade, reusabilidade e um bom grau de paralelismo nos MPSoC. Essas redes são chamadas 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 seus roteadores vizinhos e com o seu elemento de processamento. Essa comunicação entre os componentes ocorrem por meio da troca de mensagens, ou seja, a comunicação ocorre por meio do envio e recebimento de pacotes, seguindo os mesmos princípios que são aplicados em 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 interconectar diferentes blocos IP em MPSoC, esta infraestrutura de comunicação ainda apresenta algumas problemas que têm sido alvo de investigações (MARCULESCU et al.,2009). Um dos problemas relacionados porMARCULESCU et al. (2009) é o problema de alocação e agendamento de tarefas. Esse problema é um dos tradicionais problemas da ciência da computação e mesmo existindo 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 de minimizar o consumo de energia sob restrições de desempenho. Outro problema relacionado por MARCULESCU et al.(2009) é o de gerenciamento de energia. Esse problema é o que resolve algumas das restrições de projeto de sistemas embarcados devido às preocupações com a vida da bateria, refrigeração e o custo de energia elétrica. Uma plataforma MPSoC baseada em NoC deve ter preocupações com energia, já que vários protótipos de MPSoC baseados em NoC demonstraram que um porção substancial da energia consumida pelo sistemas é relacionada a NoC. 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 energia total (S. S. MUKHERJEE P. BANNON; WEBB,2002) e no TERAFLOPS, da Intel, com 80 núcleos, o consumo chega a quase 30% (VANGAL et al.,2007);

Para automatizar as atividades de um projeto de sistemas baseado MPSoC, de forma a permitir 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, os projetistas devem explorar ao máximo o espaço de projeto de um MPSoC para encontrar a melhor 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 plataforma multicoresé muito complexa e de difícil exploração, e esse problema de exploração é classificado como um problema de otimização combinatória NP-hard.

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

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úmero maior de alternativas de mapeamento, sem afetar o tempo de execução da aplicação, já que o tempo computacional do algoritmo de mapeamento não interfere no tempo de execução da aplicação. Mas a desvantagem em utilizar o mapeamento estático está relacionada às cargas dinâmicas, que não são tratadas, como, por exemplo, a inserção de novas tarefas em tempo de execução.

1.1 MOTIVAÇÃO

O International Technology Roadmap for Semiconductors (ITRS) aponta que as tendências de projetos de SoC terão dezenas de bilhões de transistores com dimensões cada vez menores e com frequência de operação cada vez maior, nas próximas décadas. Essas tendências geram novos desafios de projeto, como dissipação de potência durante projetos de sistemas eletrônicos. O ITRS também prevê que o consumo de energia global deve crescer nos SoC futuros, principalmente na comunicação intra-chip, já que a redução da tensão de alimentação não é mais suficiente para balancear os sistemas complexos demandados pelo mercado e alimentados por baterias. E o crescimento do mercado para sistemas embarcados (sistemas alimentados por bateria) reforça a importância da redução de potência durante a exploração do espaço de projeto, que, antes, era voltado 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 encapsulamento e dissipação de calor. E para garantir que o sistema final esteja de acordo com os requisitos funcionais, térmicos e de custo desejados, a questão do consumo de potência deve ser levada em consideraçã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 duas décadas com relação à quantidade de transistores em um único chip e a frequência de relógio

(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 a frequência do relógio, mas a redução da frequência leva à diminuição do desempenho do sistemas. 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, a tendencia 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ótipos de MPSoC com 80 e 64 núcleos respectivamente, utilizando uma NoC como infraestrutura de comunicação (VANGAL et al.,2007) (TILERA,2007).

Então a principal motivação para o desenvolvimento desse trabalho é o fato de que cerca de quase 40% do consumo de energia dos MPSoC atuais está relacionado à comunicação intrachip, 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 minimizar a comunicação entre os componentes de uma arquitetura MPSoC, enquanto uma aplicação está sendo executada (MARCULESCU et al.,2009), já que o consumo de potência em uma NoC cresce linearmente com a quantidade de transações de sinais ocasionadas pelos pacotes transmitidos pela NoC (PALMA et al.,2005).

Figura 1.2 Número de processadores por chip.

Fonte:ISSCC(2013)

Uma forma de solucionar esse problema é por meio do mapeamento de tarefas, pois esse problema de mapeamento é similar ao Quadratic Assigment Problem (QAP). O QAP é um dos problemas fundamentais de otimização combinatória, sendo um problema NP-completo, ou seja, não existe uma solução para resolvê-lo em tempo polinomial. Para pequenas instâncias do problema, como, por exemplo, mapeamento de tarefas em uma NoC de tamanho 2x2, o tempo para encontrar a melhor solução usando métodos exaustivos deve ser relativamente baixo; mas para, uma NoC 5x5, o tempo pode ser inaceitável para o projeto. Por isso este trabalho propõe reduzir 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 mapeamento que visa, inicialmente, agrupar as tarefas comunicantes para, em seguida, mapear as tarefas na plataforma MPSoC. E, com somente duas simulações, essa abordagem explora o espaço de projeto para encontrar uma solução que diminui o consumo de energia mediante a redução da comunicação na NoC. Para isso a abordagem, inicialmente, agrupa as tarefas comunicantes, ou seja, agrupa as tarefas que trocam mensagens com bastante frequência, utilizando um algoritmo de agrupamento baseado no algoritmo de coloração de grafos e por fim, faz o mapear das tarefas na plataforma, utilizando uma meta-heurística baseada em colonia de formigas.

Portanto, este trabalho se aprofunda nos aspectos do desenvolvimento de uma abordagem que 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íficos deste trabalho são:

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

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ção da NoC, por meio da otimização do mapeamento de tarefas nos PE da plataforma MPSoC. Os resultados foram obtidos a partir de simulações de uma plataforma MPSoC composta por uma NoC descrita em VHSIC Hardware Description Language (VHDL) e os PE são simulados por meio 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 conceitos básicos para o entendimento do trabalho. No capítulo 3, são apresentados os trabalhos relacionados ao problema de mapeamento de tarefas em MPSoC. No capítulo 4, é apresentada a abordagem de mapeamento de tarefas proposta. No capítulo 5, são apresentados os resultados iniciais dos primeiros experimentos, que faz uma avaliação do funcionamento da plataforma e a viabilidade da abordagem de mapeamento. E, no capítulo 6, finalmente, são apresentadas as conclusões e trabalhos futuros. E, por fim, são apresentadas as referências bibliográficas do trabalho.

2

CONCEITOS 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, apresentarmos a 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 processamento em 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órias e um meio de interconexão no mesmo chip, como pode ser visto na Figura 2.1 (WOLF,2004).

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

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ção ou de um conjunto de aplicações.

Em um projeto de plataforma, existem muitas restrições de projeto como redução do consumo de energia, minimização da área do chip e maximização do desempenho. Como já foi mencionado, o consumo de energia é muito importante, especialmente em projetos de sistemas embarcados que dependem do tempo de vida da bateria. E, em geral, a maioria dessas restrições de projeto podem ser conflitantes, como, por exemplo, minimizar o consumo de energia afeta diretamente o desempenho do sistema. Então, a questão principal em um projeto de plataforma MPSoC é encontrar o melhor compromisso entre as restrições de projeto. E uma das formas para encontrar 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, tais como, 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 de plataforma é 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 um roteador. A Figura 2.6 apresenta os principais componentes de um MPSoC baseado em NoC e também é possível visualizar nove tiles (0, 1, 2, 3, 4, 5, 6, 7 e 8) interligadas por meio de roteadores (R0, R1, R2, R3, R4, R5, R6, R7 e R8). O modelo de roteador ilustrado na Figura 2.6 possui cinco portas bidirecionais conectadas a um núcleo crossbar, sendo uma das portas conectada a Network Interface Controller (NIC) (DALLY; TOWLES,2004).

Dessa forma, uma plataforma MPSoC baseada em NoC pode solucionar alguns dos problemas associados a uma plataforma baseada em barramento (modelo de plataforma tradicional) como escalabilidade e paralelismo. Em um MPSoC baseado em NoC, existe uma maior largura de banda nos enlaces, permitindo, assim, conectar mais núcleos IP na plataforma e como existem 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 da plataforma (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 por roteadores e enlaces (links), e utilizada em chips. Os enlaces são utilizados para interconectar os

transferência entre as interfaces de redes são representados na camada de rede e implementados nos 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 os mecanismos de comunicação necessários para a transferência das mensagens pela rede. Esses mecanismos são constituídos por um conjunto de filas, multiplexadores, controladores e portas de entrada e saída para comunicação com outros roteadores e/ou núcleo IP. Essas portas de entrada e saída podem possuir buffer (memórias para armazenamento temporário) e ainda controladores 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 simultaneamente mensagens 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 envelopam a carga útil, como pode ser visto na Figura 2.9. É no cabeçalho que são incluídas as informações de roteamento e de controle que serão utilizadas pelos roteadores para transferir a mensagem pela NoC. Já o terminador inclui a sinalização do final da mensagem e, ainda, pode incluir informações usadas para a detecção de erros. Geralmente, as mensagens são quebradas em pacotes antes de serem transmitidas. Um pacote é sempre constituído por uma sequência de palavras com largura igual a largura física do canal (n) e, em alguns casos, pode incluir sinais de enquadramento 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 e estratégias utilizadas para roteamento, chaveamento, controle de fluxo, arbitragem e memorização, conforme definido na Tabela 2.1 (ZEFERINO; SUSIN,2003).

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

2.3.2.2 Roteamento

O roteamento é o método usado para definir o caminho a ser utilizado por uma mensagem para atingir o seu destino. O desempenho da NoC está diretamente ligado ao algoritmo de roteamento 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 nenhuma mensagem ficará bloqueada ou circulando pela rede sem atingir o destino, capacidade de rotear pacotes por meio de caminhos alternativos quando ocorrer congestionamento e capacidade de rotear mensagens mesmo com falhas em algum componente da rede. Um exemplo de algoritmo de 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 chaveamento podem ser classificados em dois tipos principais de chaveamento: chaveamento por circuito ou chaveamento por pacote. O chaveamento por circuito é baseado no estabelecimento de um caminho completo entre a origem e o destino, por onde a mensagem será enviada. Esse caminho só será liberado depois que o terminador da mensagem passa pelo caminho (sinalizando que o recurso pode ser liberado). Já no chaveamento por pacote, nenhum caminho é reservado entre a origem e o destino da mensagem; em vez disso, os pacotes são encaminhados para os roteadores, usando as informações contidas no pacote. Os roteadores que utilizam chaveamento por 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 fluxo de uma NoC é feito em nível de enlace, e para cada roteador da rede deve existir um buffer para o armazenamento do dado que esta sendo transferido. Dessa forma, o mecanismo de controle de fluxo deve ser usado para bloquear a saída de dados do transmissor, e o receptor deve enviar uma informação de controle ao transmissor para informar que está pronto para receber novos dados. As técnicas básicas de controle de fluxo são: handshake, slack buffer, baseado em crédito e canais virtuais (JANTSCH; TENHUNEN,2003).

2.3.2.5 Arbitragem

O mecanismo de arbitragem ao contrário do mecanismo de roteamento, que determina qual canal de saída deve ser usado pela mensagem que entra no roteador, é responsável por resolver conflitos internos, quando duas ou mais mensagens competem pelo mesmo canal, ou seja, 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 chaveamento por 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 pela liberação da saída para evitar a perda de dados recebidos (JANTSCH; TENHUNEN,2003).

2.4 MAPEAMENTO DE TAREFAS EM UMA PLATAFORMA

MPSOC

O mapeamento de tarefas ou alocação de tarefas é semelhante ao problema de atribuição quadrá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, mas que pode ser resolvido, utilizando abordagens heurísticas para encontrar uma solução quase ideal. (MARCULESCU et al.,2009) (SAHU; CHATTOPADHYAY,2013). Para o mapeamento de poucas 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-se todos os casos (SINGH et al.,2013). O problema de mapeamento de tarefas pode ser dividido em duas classes: mapeamento estático e mapeamento dinâmico.

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

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

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

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

forma: E_biti j = 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 o modelo de energia para avaliar a qualidade do mapeamento das tarefas, é possível formular o problema em uma função map : T → N, tal que ∀ ti∈ T, ∃ nj∈ N e map(ti) = Nj, ou seja, um

mapeamento 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 que pode minimizar o consumo de energia de comunicação é apresentado na Equação 2.2

min

_∑

i

∑

j

E_biti j ☛_✡2.2✟_✠

2.5 A PLATAFORMA MPSOC INFINITY

A plataforma Infinity é uma plataforma MPSoC baseada em NoC desenvolvida em SystemC e que simula o comportamento de um sistema embarcado distribuído, onde os seus elementos são implementados em nível Transaction-level modeling (TLM) e a NoC em nível Register Transfer Level(RTL). A NoC foi implementada em RTL para garantir a extração dos dados de potência dissipada com maior precisão. A potência dissipada pela NoC é estimada usando a ferramenta PowerPlay Power Analyzer, que vem acoplada ao software Quartus II. Por meio da ferramenta PowerPlay Powe Analyzer, é possível obter uma estimativa bastante precisa do 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 meio dos roteadores da NoC SoC Interconnection Network (SoCIN) (ZEFERINO; SUSIN,2003). A NoC SoCIN foi escolhida principalmente devido à disponibilidade da descrição em VHDL e SystemC.

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

(v) Novas Instruções de Load e Store. As instruções foram modificadas para que elas possam salvar 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 com base no modelo descrito porHENNESSY; PATTERSON(2012).

2.5.1.2 Interface de rede (NIC)

A interface de rede da plataforma Infinity foi desenvolvida para realizar a comunicação entre os núcleos Infinity e os roteadores da rede SoCIN. A Figura 2.17 ilustra a arquitetura da interface de rede da plataforma Infinity, que possui dois submódulos: front-end (nível TLM) e back-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 ser separadas em transações de serviços e transações de dados. Dessa forma, o front-end pode ser visto como uma implementação da camada de sessão do modelo de referência OSI, onde a camada de sessão representa a interface do usuário com a rede, determinando quando uma sessão é aberta, o tempo necessário e quando deverá ser fechada. Já o back-end implementa as camadas 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 da plataforma (BENINI; MICHELLI,2006).

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

Figura 2.17 Organização da interface de rede

Fonte: O Autor (2014)

2.5.1.3 Modelo de mensagens

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

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

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

(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 pelo controlador da cache depois de ter recebido as mensagens. Os serviços implementados e que podem ser transportados em um pacote de rede são mostrados juntamente com o seu código na Tabela 2.2.

Tabela 2.2 Descrição dos serviços que um pacote de rede pode carrega

Serviços Código Error 0000 Get shared 0001 Get modified 0010 Invalidate 0011 Invalidate ack 0100 Invalidate started 0101 Put modified 0110 Put modified and shared 0111 Put modified ack 1000 Forward get shared 1001 Forward get modified 1010

Data 1011

Unknow message 1100

2.5.1.4 Formato da mensagem

Para oferecer os serviços previstos pela plataforma Infinity foram realizadas modificações no formato da mensagem da rede SoCIN, com o objetivo de oferecer suporte aos serviços previstos pela plataforma. A nova estrutura da mensagem apresenta uma extensão do cabeçalho por meio de um bit ((header extension) para informar se o próximo flit é uma continuação do cabeç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ósito específico (Begin of Packet (BOP) e End of Packet (BOP)), que são utilizados para sinalizar o 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 ser constituido por um ou mais flit, devido ao bit específico (header extension), que é responsável por informar se o próximo flit ainda faz parte do cabeçalho. No cabeçalho, constam os seguintes dados: High Level Protocol (HLP), Routing Information Bits (RIB), o código do serviço

3

TRABALHOS RELACIONADOS

Neste capítulo, são apresentados os trabalhos relacionados que buscam reduzir a energia de comunicação de uma plataforma MPSoC, em tempo de projeto, por meio do problema de mapeamento de tarefas. Para facilitar a leitura, os trabalhos estudados serão apresentados em ordem cronológica de publicação e classificados conforme a técnica utilizada para encontrar a soluçã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 plataforma MPSoC geralmente utilizam Integer Linear Programming (ILP) ou Mixed Integer Linear Program (MILP). Alguns dos trabalhos que utilizam ILP para otimizar a energia, buscam também minimizar a energia de comunicação por meio do problema de gerenciamento de energia dos enlaces da NoC (rede), ou seja, usam a ILP para desligar determinados enlaces de comunicação e/ou para selecionar tensão e frequência de operação dos enlaces utilizados pela plataforma.

3.1.1 Uma Abordagem Exata para Alocar e Escalonar Tarefas

RUGIERO et al.(2006), neste trabalho, apresentaram uma abordagem exata para alocar e escalonar tarefas em uma plataforma MPSoC mediante a decomposição do problema em dois subproblemas ou etapas, criando, assim, uma abordagem híbrida. Os subproblemas ou etapas sã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 processadores da plataforma, de modo que a quantidade total de memória alocada para as tarefas em cada processador não exceda o tamanho da memória local. Mas, para aplicações com dados extremamente

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

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

Tabela 3.1 Variáveis utilizadas no subproblema de alocação de tarefas

Variáveis Explicação

Ti j Variável inteira que recebe o valor 1 se a tarefa i é executada no processador j,

e 0 caso contrário

Yi 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ário

Zi 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ário

Xi 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 min

_∑

∑

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

☛ ✡

✟ ✠

3.1 onde Memi, Stateie Dataisão coeficientes que representam a quantidade de dado usado

pela tarefa i para armazenar respectivamente o dado do programa, o estado interno e a fila de comunicação.

As restrições para o subproblema são as seguintes: cada tarefa só pode ser executada em um processador e impedir a alocação de um conjunto consecutivo de tarefas onde a soma do tempo 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 alocadas em 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ão descritas na Tabela 3.2.

As restrições introduzidas no modelo são as seguintes: cada tarefa só pode começar a ler a fila de comunicação apenas após o final da sua iteração anterior (Equação 3.2); cada tarefa deve ler 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 tarefa anterior gerar a fila (Equação 3.5); cada tarefa deve ler o estado interno pouco antes da execução e escrevê-lo apenas depois (Equações 3.6 e 3.7); uma tarefa pode ler a fila de comunicação

Tabela 3.2 Atividades de uma tarefa da aplicação

Atividades Explicação

Ai j Atividade computacional

Ini j Atividades de entrada de dados de leitura

RSi j Atividade de leitura do estado interno

W Si 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 tarefa devem ser executadas em ordem (Equação 3.9).

A_{i( 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 W Si j, ∀i, j ☛ ✡ ✟ ✠ 3.7 A_{(i+1)( j−1)}≺ Ini j, ∀i, j ☛ ✡ ✟ ✠ 3.8 A_{i( j−1)}≺ Ai j, ∀i, j ☛ ✡ ✟ ✠ 3.9 A plataforma MPSoC usada nos experimentos realizados pelo autores, utiliza memória distribuída com troca de mensagens e com todos os processadores iguais (homogêneos) e com infraestrutura de comunicação baseada em barramento. Cada elemento de processamento da plataforma consiste de um processador Acorn RISC Machine (ARM), que inclui cache de instrução e dados e, para a comunicação entre os elementos de processamento, a plataforma utiliza um barramento Advanced Microcontroler Bus Architecture (AMBA). A plataforma utilizada 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ções com 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,

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

Para validar as etapas de alocação e escalonamento de tarefas, os autores utilizam aplicações sintéticas. Segundo os autores, é possível fazer alterações nos parâmetros das aplicaçõ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 a abordagem proposta tem um nível de precisão alto, ou seja, a diferença média entre os valores medidos e o previstos é 4,7%, com um desvio padrão de 0,08. E para provar a viabilidade da proposta, 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 ainda apresenta uma limitação com relação à plataforma MPSoC, que utiliza barramento como infraestrutura de comunicação. Outro ponto que não ficou claro, mesmo a abordagem conseguindo resolver o problema de escalonamento, é se é possível modelar o problema para permitir flexibilizar o uso dos recursos, ou seja, se é possível minimizar o uso de processadores para uma aplicaçã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 busca minimizar o consumo de energia de uma plataforma MPSoC heterogênea por meio do mapeamento das tarefas da aplicação e também selecionando vários níveis de voltagem de operação. Os autores propuseram a utilização de uma técnica de programação matemática para resolver o problema de mapeamento da aplicação. Os autores formularam o problema utilizando uma formulação MILP para minimizar o consumo de energia de uma plataforma baseada em NoC. O destaque 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 plataforma MPSoC. 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 MILPGHOSH; SEN; HALL(2009), utilizam uma função para cada problema. Essas funções são descritas e explicadas na Tabela 3.3, e na Tabela 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 porGHOSH; SEN; HALL(2009) é apresentada na Equação 3.10.

Tabela 3.3 Funções modeladas porGHOSH; SEN; HALL(2009)

Funções Explicação

M1(ti) = pj Significa que a tarefa tideve ser mapeada para o PE pj

M2(pi) = rj Significa que o PE pideve ser mapeada para o roteador rj

M3(pi) = vj Significa que para o PE pideve ser atribuído um nível de tensão vj

M₄(ti,tx) Se eix∈ ET, M1(ti) = pj, M2(pj) = 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 porGHOSH; SEN; HALL(2009)

Variáveis Explicação

G(VT, ET) Grafo de tarefas, onde cada vértice ti∈ VT representa uma tarefa e

cada aresta ei j = (ti,tj) ∈ ET representa a dependência entre as tarefa tje ti

GR(VR, ER) Grafo da arquitetura NoC, onde cada vértice ri∈ VR representa um roteador e

cada aresta ei j = (ri, rj) ∈ ERrepresenta o enlace entre os roteadores rie rj

wi j Representa o volume de comunicação (em Mbps) entre as tarefas tie tj

D Deadlineda aplicação

k Número máximo de ilhas de tensão criadas P O conjunto de PE P = {p1, p2, ..., pk}

Pt⊆ P Conjunto de PE que pode executar a tarefa t

Vp 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 ∈ Ptcom 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 roteador

Li j Tamanho da aresta ei j ∈ ER

αv₁v₂ Consumo de energia da transição de tensão entre dois PE operando com v1e v2

ςv

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

ζrv Se r ∈ VRoperando com tensão v então ζrv= 1 senão ζrv= 0

fxyi j Se ei j ∈ ET, exy∈ ER e exy∈ M4(ei j então fxyi j = 1 senão fxyi j= 0 min E = Ec+ Er+ El+ Evt ☛ ✡ ✟ ✠ 3.10 onde Ecé a energia consumida na computação, Er e Elsão as energias consumidas nos

roteadores e nos enlaces respectivamente e Evt é a energia consumida na transação da tensão, e

são calculadas como:

Ec=

∑

∑

∑

∑

∑

El=

∑

∑

∑

∑

∑

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 testes foram realizados utilizando seis cenários de teste, e para cada cenário foi usado um nível de tensão diferente. E para os experimentos com a aplicação industrial do E3S a plataforma foi configurada com uma rede de tamanho 4x4 e para as outras três aplicações do E3S com tamanho 3x3. Já para os experimentos com as aplicações reais, a plataforma foi configurada da seguinte forma: 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 energia de uma plataforma MPSoC, para as quatro aplicações do E3S (indústria, consumo, rede e automação de escritório), conseguindo economizar 18% do consumo de energia. E para as três aplicações reais (MPEG-4, MWD e OPD), a abordagem MILP proposta porGHOSH; 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 consumida de uma plataforma MPSoC por meio de uma abordagem que unifica em uma única formulação quatro problemas de otimização. Mesmo com tal eficiência, a abordagem proposta utiliza um roteamento 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 minimiza a energia consumida pelo processador, por meio do problema de mapeamento, para uma formulação ILP que encontra um trade-off entre a energia consumida pela computação e comunicação, ou seja, um função objetivo para minimizar a soma da energia consumida pelos processadores e pela NoC (HUANG et al.,2011).

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

min E = Ep+ Ec ☛ ✡ ✟ ✠ 3.15 onde Ep é a energia consumida pelo processador e Ec é a energia consumida pela