Departmento de Informática e Matemática Aplicada Programa de Pós-Graduação em Sistemas e Computação
Mestrado Acadêmico em Sistemas e Computação
Redes em Chip Irregulares para Tolerância a
Falhas e Atendimento de Tempo Real
Elisio Breno Garcia Cardoso
Natal/RN Janeiro/2021
Redes em Chip Irregulares para Tolerância a Falhas e
Atendimento de Tempo Real
Dissertação de Mestrado apresentada ao Pro-grama de Pós-Graduação em Sistemas e Computação do Departamento de Informá-tica e MatemáInformá-tica Aplicada da Universidade Federal do Rio Grande do Norte como re-quisito parcial para a obtenção do grau de Mestre em Sistemas e Computação.
Linha de pesquisa:
Sistemas Integrados e Distribuídos
Orientadora
Profª Drª Monica Magalhães Pereira
PPgSC – Programa de Pós-Graduação em Sistemas e Computação DIMAp – Departamento de Informática e Matemática Aplicada
CCET – Centro de Ciências Exatas e da Terra UFRN – Universidade Federal do Rio Grande do Norte
Natal-RN Janeiro/2021
Cardoso, Elisio Breno Garcia.
Redes em chip irregulares para tolerância a falhas e
atendimento de tempo real / Elisio Breno Garcia Cardoso. - 2021. 109f.: il.
Dissertação (mestrado) - Universidade Federal do Rio Grande do Norte, Centro de Ciências Exatas e da Terra, Departamento de Informática e Matemática Aplicada, Programa de Pós-Graduação em Sistemas e Computação. Natal, 2021.
Orientadora: Profa. Dra. Monica Magalhães Pereira.
1. Computação - Dissertação. 2. Redes-em-chip - Dissertação. 3. Topologias Dissertação. 4. Tolerância a falhas
-Dissertação. 5. Tempo-real - -Dissertação. I. Pereira, Monica Magalhães. II. Título.
RN/UF/CCET CDU 004
Catalogação de Publicação na Fonte. UFRN - Biblioteca Setorial Prof. Ronaldo Xavier de Arruda - CCET
Agradecimentos
Diante deste desafio, muita coragem, perserverança e dedicação foram necessárias na superação de cada adversidade. Aqui deixo meu agradecimento aos amigos que colabora-ram na conclusão deste grau.
Ao meu Senhor Jesus Cristo, provedor de toda capacidade. À minha família pelo apoio, incentivo e os valores transmitidos desde a tenra idade. A meus irmãos Bruno e Kleber, companheiros de primeira hora que sempre pude contar.
À Profª Monica Pereira pela oportunidade de estar como seu orientando. Agradeço pela amizade, dedicação e compreensão demonstrados neste periodo. De grande valia foram nossas reuniões, onde construímos juntos o entendimento, dúvidas eram sanadas e o ânimo era sempre renovado para o aprimoramento desta dissertação. Deixo também meus agradecimentos ao Profº Márcio Kreutz pelos conhecimentos adquiridos, pelas exposições onde o domínio dos temas era sempre observado e as discusões compartilhadas com toda a seriedade.
Aos colegas André Ribeiro, Samuel de Oliveira e Vinícius Petch pela boa amizade construída ao longo do curso, conversas várias vezes intermináveis, discusões sobre os projetos uns dos outros, e suporte mútuo sempre que possível. Ao amigo Adelino por gentilmente ter cedido a estrutura do simulador NoC42, que também viabilizou a execução deste projeto.
Atendimento de Tempo Real
Autor: Elisio Breno Garcia Cardoso Orientadora: Profª. Drª. Monica Magalhães Pereira
Resumo
As redes-em-chip surgiram devido à necessidade de comunicar de forma eficiente dezenas de núcleos de sistemas multiprocessados em um único chip. Desde então, tornaram-se o principal paradigma de comunicação para esse tipo de sistema, com diversos modelos ar-quiteturais sendo propostos ao longo dos anos. Os projetos buscam atender principalmente restrições relacionadas à latência média, área da rede, consumo de energia, dentre outros. Os projetos atuais também abrangem a arquitetura da rede, com a geração de topologias que proporcionam desempenho otimizado para aplicações específicas. Este trabalho pro-põe uma heurística para a geração de topologias tolerantes a falhas capazes de entregar os pacotes de tempo real por um caminho alternativo dentro da rede em caso de falha em um canal. Para avaliar a solução proposta, foi utilizado um simulador em SystemC chamado NoC42, alterado para atender topologias irregulares, pacotes de tempo real, algoritmo de roteamento baseado em uma tabela de roteamento e injeção de falhas nos canais.
Author: Elisio Breno Garcia Cardoso Supervisor: Profª. Drª. Monica Magalhães Pereira
Abstract
Network-on-chip emerged due to the need to e⇥ciently communicate the cores from a multiprocessor systems on a chip. Since then, they have become the main communication paradigm for this type of system, with several architectural models being proposed over the years to meet restrictions related to median latency, network area, energy consump-tion, among others. The projects also cover the network architecture, with the generation of topologies that provide optimized performance for specific applications. This work proposes a heuristic for the generation of fault-tolerant topologies capable of delivering real-time packets via an alternative path within the network even if a link fail. To eva-luate the proposed solution, a SystemC simulator NoC42 has been modified to support irregular topologies, real-time packets, a routing algorithm based in a routing table and a fault injector.
Lista de figuras
1 Exemplo de rede-em-chip . . . p. 25 2 Roteador RASoC (ZEFERINO; KREUTZ; SUSIN, 2004) . . . p. 26
3 Mensagem: (a) carga útil e carga de controle; (b) subdivisão da mensagem p. 27 4 Topologias regulares: (a) mesh-2D; (b) Toróide-2D . . . p. 29 5 Topologia irregular . . . p. 29 6 Exemplo de um votador TMR . . . p. 31 7 Modelo OSI em NOC (RADETZKI et al., 2013) . . . p. 32
8 Exemplo de topologia com redundância de hardware nos canais . . . . p. 33 9 Canal de comunicação da SoCIN (ZEFERINO; SUSIN, 2003) . . . p. 33
10 Algorimo de roteamento XY . . . p. 34 11 Esquema básico de um algoritmo genético . . . p. 37 12 Seleção: (a) Por roleta; (b) Por torneio . . . p. 37 13 Cruzamento: (a) Em um ponto; (b) Multiponto . . . p. 38 14 Exemplos de mutação . . . p. 38 15 Fluxo de Construção da Rede em (CHOUDHARY et al., 2010) . . . p. 41
16 Exemplo de uma rede UTNoC em (MESQUITA, 2016). . . p. 41
17 Etapa de broadcasting em (MESQUITA, 2016). . . p. 42 18 Modelos de roteadores utilizados por (OLIVEIRA, 2018) . . . p. 43
19 Interface de link em (KOUPAEI; KHADEMZADEH; JANIDARMIAN, 2011). p. 44
20 Arquitetura proposta em (KOUPAEI; KHADEMZADEH; JANIDARMIAN, 2011) p. 44
21 Cenários de Busca em (BEZERRA, 2019) . . . p. 46
24 Exemplo de um indivíduo do Algoritmo Genético para a geração de
to-pologias . . . p. 52 25 Fluxograma da heurística de geração de topologias . . . p. 53 26 Exemplos de topologias desejadas neste trabalho . . . p. 54 27 Exemplos de topologias indesejadas neste trabalho . . . p. 55 28 Exemplo de uma distribuição de tarefas pela heurística do mapeamento
de tarefas . . . p. 57 29 Fluxograma da heurística de mapeamento de tarefas . . . p. 58 30 Preparação para a simulação na NoC42 . . . p. 58 31 Tabela de roteamento para o roteador R5 . . . p. 60 32 Fluxograma de execução . . . p. 63 33 Grafo das Aplicações 1 e 2: (a) MP3 Decoder; (b) VOPD . . . p. 64 34 Grafos das Aplicações 3 e 4: (a) Integral; (b) Sintética . . . p. 65 35 Grafo da Aplicação 5: Sintética . . . p. 65 36 Resultados de latência média da aplicação 1 . . . p. 68 37 Resultados de latência média da aplicação 2 . . . p. 69 38 Resultados de latência média da aplicação 3 . . . p. 70 39 Resultados de latência média da aplicação 4 . . . p. 71 40 Resultados de latência média da aplicação 5 . . . p. 72 41 Resultados de violações de deadline da aplicação 1 . . . p. 73 42 Resultados de violações de deadline da aplicação 2 . . . p. 74 43 Resultados de violações de deadline da aplicação 3 . . . p. 75 44 Resultados de violações de deadline da aplicação 4 . . . p. 76 45 Resultados de violações de deadline da aplicação 5 . . . p. 77 46 Fluxograma da heurística implementada para os experimentos adicionais p. 78
rimentos adicionais . . . p. 79 48 Resultados de latência dos novos testes com a aplicação 2, comparando
com os obtidos na seção 5.3 . . . p. 80 49 Resultados de violações de deadline dos novos testes com a aplicação 5,
Lista de tabelas
1 Variação da quantidade de canais ativados em cada dimensão de
topolo-gia em diferentes taxa de falhas . . . p. 71 2 Aplicação 1 partindo da topologia mesh-2D 5x5 . . . p. 90 3 Aplicação 1 comparando com a mesh-2D 5x5 . . . p. 90 4 Aplicação 1 partindo da topologia mesh-2D 6x6 . . . p. 91 5 Aplicação 1 comparando com a mesh-2D 6x6 . . . p. 91 6 Aplicação 1 partindo da topologia mesh-2D 7x7 . . . p. 91 7 Aplicação 1 comparando com a mesh-2D 7x7 . . . p. 92 8 Aplicação 1 partindo da topologia mesh-2D 8x8 . . . p. 92 9 Aplicação 1 comparando com a mesh-2D 8x8 . . . p. 92 10 Aplicação 2 partindo da topologia mesh-2D 5x5 . . . p. 93 11 Aplicação 2 comparando com a mesh-2D 5x5 . . . p. 93 12 Aplicação 2 partindo da topologia mesh-2D 6x6 . . . p. 94 13 Aplicação 2 comparando com a mesh-2D 6x6 . . . p. 94 14 Aplicação 2 partindo da topologia mesh-2D 7x7 . . . p. 94 15 Aplicação 2 comparando com a mesh-2D 7x7 . . . p. 95 16 Aplicação 2 partindo da topologia mesh-2D 8x8 . . . p. 95 17 Aplicação 2 comparando com a mesh-2D 8x8 . . . p. 95 18 Aplicação 3 partindo da topologia mesh-2D 5x5 . . . p. 96 19 Aplicação 3 comparando com a mesh-2D 5x5 . . . p. 96 20 Aplicação 3 partindo da topologia mesh-2D 6x6 . . . p. 97 21 Aplicação 3 comparando com a mesh-2D 6x6 . . . p. 97
23 Aplicação 3 comparando com a mesh-2D 7x7 . . . p. 98 24 Aplicação 3 partindo da topologia mesh-2D 8x8 . . . p. 98 25 Aplicação 3 comparando com a mesh-2D 8x8 . . . p. 98 26 Aplicação 4 partindo da topologia mesh-2D 5x5 . . . p. 99 27 Aplicação 4 comparando com a mesh-2D 5x5 . . . p. 99 28 Aplicação 4 partindo da topologia mesh-2D 6x6 . . . p. 100 29 Aplicação 4 comparando com a mesh-2D 6x6 . . . p. 100 30 Aplicação 4 partindo da topologia mesh-2D 7x7 . . . p. 100 31 Aplicação 4 comparando com a mesh-2D 7x7 . . . p. 101 32 Aplicação 4 partindo da topologia mesh-2D 8x8 . . . p. 101 33 Aplicação 4 comparando com a mesh-2D 8x8 . . . p. 101 34 Aplicação 5 partindo da topologia mesh-2D 5x5 . . . p. 102 35 Aplicação 5 comparando com a mesh-2D 5x5 . . . p. 102 36 Aplicação 5 partindo da topologia mesh-2D 6x6 . . . p. 103 37 Aplicação 5 comparando com a mesh-2D 6x6 . . . p. 103 38 Aplicação 5 partindo da topologia mesh-2D 7x7 . . . p. 103 39 Aplicação 5 comparando com a mesh-2D 7x7 . . . p. 104 40 Aplicação 5 partindo da topologia mesh-2D 8x8 . . . p. 104 41 Aplicação 5 comparando com a mesh-2D 8x8 . . . p. 104 42 Aplicação 1: experimentos adicionais partindo da topologia mesh-2D 5x5 p. 105 43 Aplicação 1: experimentos adicionais partindo da topologia mesh-2D 6x6 p. 105 44 Aplicação 1: experimentos adicionais partindo da topologia mesh-2D 7x7 p. 105 45 Aplicação 1: experimentos adicionais partindo da topologia mesh-2D 8x8 p. 105 46 Aplicação 2: experimentos adicionais partindo da topologia mesh-2D 5x5 p. 106 47 Aplicação 2: experimentos adicionais partindo da topologia mesh-2D 6x6 p. 106
49 Aplicação 2: experimentos adicionais partindo da topologia mesh-2D 8x8 p. 106 50 Aplicação 3: experimentos adicionais partindo da topologia mesh-2D 5x5 p. 107 51 Aplicação 3: experimentos adicionais partindo da topologia mesh-2D 6x6 p. 107 52 Aplicação 3: experimentos adicionais partindo da topologia mesh-2D 7x7 p. 107 53 Aplicação 3: experimentos adicionais partindo da topologia mesh-2D 8x8 p. 107 54 Aplicação 4: experimentos adicionais partindo da topologia mesh-2D 5x5 p. 108 55 Aplicação 4: experimentos adicionais partindo da topologia mesh-2D 6x6 p. 108 56 Aplicação 4: experimentos adicionais partindo da topologia mesh-2D 7x7 p. 108 57 Aplicação 4: experimentos adicionais partindo da topologia mesh-2D 8x8 p. 108 58 Aplicação 5: experimentos adicionais partindo da topologia mesh-2D 5x5 p. 109 59 Aplicação 5: experimentos adicionais partindo da topologia mesh-2D 6x6 p. 109 60 Aplicação 5: experimentos adicionais partindo da topologia mesh-2D 7x7 p. 109 61 Aplicação 5: experimentos adicionais partindo da topologia mesh-2D 8x8 p. 109
ANSI C – American National Standards Institute C ASIC – Application Specific Integrated Circuits AUTOSAR – AUTomotive Open System ARchitecture BOP – Begin Of Packet
DFS – Depth-First Search
DSE – Design Space Exploration EOP – End Of Packet
EP – Elemento de Processamento
FPGA – Field Programmable Gate Array GP – General Purpose
HLS – High-Level Syntesis
HPC – Hardware Performance Counters IHC – Interação Humano-Computador IP-Core – Intellectual Property-Cores LI – Link Interface
MP3 – Moving Picture Experts Group Layer 3 MPSoC – Multiprocessor System-on-Chip NoC – Network-on-Chip
NoC42 – Network-on-Chip 42 NoCem – Network on Chip emulator OSI – Open System Interconnection RAM – Random Access Memory RASoC – Router Architecture for SoC RR – Round-Robin
RT – Real-Time
RTL – Register Transfer Level SoC – System-on-Chip
SoCIN – SoC Interconnection Network TGFF – Task Graphs For Free
UTNoC – Undefined Topology Network-on-Chip VC – Virtual Channels
VLSI – Very Large-Scale Integrated
VHDL – VHSIC Hardware Description Language VOPD – Video Object Plane Decoder
Lista de algoritmos
1 Heurística para a geração de topologias . . . p. 51 2 Heurística para o mapeamento de tarefas . . . p. 57 3 Geração das tabelas de roteamento através do Algoritmo de Floyd . . . p. 59 4 Injetor de falhas . . . p. 61
Sumário
1 Introdução p. 20 1.1 Objetivos e Contribuições . . . p. 22 1.2 Metodologia . . . p. 22 1.3 Organização do trabalho . . . p. 23 2 Referencial Teórico p. 24 2.1 Sistemas Multiprocessados . . . p. 24 2.2 Redes-em-Chip . . . p. 25 2.3 Tolerância a Falhas . . . p. 30 2.4 Simulador NoC42 . . . p. 32 2.5 Algoritmo Genético . . . p. 36 3 Trabalhos Relacionados p. 40 3.1 Topologias Irregulares . . . p. 40 3.2 Topologias Tolerantes a Falhas . . . p. 43 3.3 Mapeamento de Tarefas . . . p. 45 3.4 Injeção de Falhas . . . p. 47 3.5 Considerações Finais . . . p. 494 Algoritmos Desenvolvidos p. 50
4.1 Exploração de Espaço de Projeto . . . p. 50 4.2 Mapeamento de Tarefas . . . p. 56 4.3 Algoritmo de Roteamento Proposto . . . p. 59
5 Experimentos e Resultados p. 62 5.1 Ambiente de Simulação . . . p. 62 5.2 Metodologia dos Testes . . . p. 64 5.3 Resultados de Latência Média . . . p. 66 5.4 Resultados de Violações de Deadline . . . p. 70 5.5 Experimentos Adicionais . . . p. 77
6 Considerações Finais p. 82
Referências p. 84
Apêndice A -- Resultados completos da aplicação 1 p. 90 Apêndice B -- Resultados completos da aplicação 2 p. 93 Apêndice C -- Resultados completos da aplicação 3 p. 96 Apêndice D -- Resultados completos da aplicação 4 p. 99 Apêndice E -- Resultados completos da aplicação 5 p. 102 Apêndice F -- Resultados dos experimentos adicionais com a aplicaçãoj
1 p. 105
Apêndice G -- Resultados dos experimentos adicionais com a aplicação
2 p. 106
Apêndice H -- Resultados dos experimentos adicionais com a aplicação
3 p. 107
Apêndice I -- Resultados dos experimentos adicionais com a aplicação
1
Introdução
As redes-em-chip (NoC – Network-on-Chip) surgiram diante das necessidades de pro-jeto dos sistemas multiprocessados em um único chip (MPSoC – Multiprocessor System-on-Chip) relacionadas à escalabilidade, comunicação e paralelismo na execução de instru-ções (BENINI; MICHELI, 2002). Até então, o barramento era o meio mais utilizado visando
interconectar vários elementos de processamento, porém a sua escalabilidade se tornou cada vez mais limitada conforme houve o aumento da complexidade dos sistemas com a adição de mais núcleos de processamento (FILHO; PONTES; LEITHARDT, 2007). Enquanto
arquiteturas interligadas via barramento suportam algumas dezenas de núcleos, as NoCs permitem integrar mais de uma centena de elementos em um mesmo sistema (KUMAR; TYAGI; JHA, 2017).
Em uma NoC, cada elemento de processamento está conectado à rede através de uma interface de rede presente em um roteador. A topologia constitui uma das principais ca-racterísticas de uma NoC, definindo a maneira como os roteadores estão integrados na rede (ZEFERINO, 2003). Este aspecto possui grande importância em virtude de sua
in-fluência no desempenho do sistema (TOSUN et al., 2015), principalmente quando avaliados
o consumo de energia e a latência média dos pacotes. Um pacote poderá percorrer um ca-minho maior ou menor quando enviado do nodo fonte para um nodo destino dependendo da topologia da rede.
As topologias regulares são as mais comuns no projeto de NoC. A mesh-2D é um exemplo bastante conhecido de topologia regular, consistindo em M xN blocos regulares interconectados como uma rede de malha 2D (BHARDWAJ; JENA, 2009). Apesar da
sim-plicidade de implementação, estas topologias não possuem o desempenho mais eficiente quando avaliados o consumo de energia e a latência média dos pacotes (CHOUDHARY et al., 2010). Em contrapartida, topologias irregulares apresentam área mais otimizada e
melhor desempenho em relação ao consumo de energia e latência média do que sua equiva-lente regular quando são projetadas para uma aplicação específica (TOSUN; AR; OZDEMIR,
Durante a vida útil de um sistema embarcado seus componentes de hardware se tor-nam cada vez mais vulneráveis conforme há o envelhecimento dos chips, resultando num aumento progressivo da taxa de falhas (YANG et al., 2016). Falhas em componentes de hardware podem resultar em diversas consequências como: perda de dados, interrupções dos serviços oferecidos pelo sistema, no colapso total do sistema (WEBER, 2003). Por vezes,
o projeto de NoC tem de lidar com falhas transientes e permanentes (CONSTANTINESCU,
2003). Falhas transientes podem ocorrer por um ou mais ciclos devido a algum fator ex-terno, enquanto as falhas permanentes comprometem o funcionamento de um circuito de forma irreversível.
A pesquisa de tolerância a falhas em redes-em-chip possui o objetivo de superar falhas que possam ocorrer na rede de maneira a minimizar os seus impactos no desempenho e na confiabilidade do sistema (RADETZKI et al., 2013). Uma falha possível numa NoC é o rompimento total de um canal entre dois roteadores, causando dificuldades na entrega dos pacotes e consequentes prejuízos na comunicação da rede. Uma solução já trabalhada para mitigar este tipo de falha é através da redundância de hardware, por exemplo, gerando topologias nas quais um roteador pode encaminhar um pacote ao seu destino por mais de um canal conectado a ele sem prejudicar a comunicação (TOSUN et al., 2014).
Em um sistema de tempo real (RT - Real-Time), a corretude do sistema depende não apenas dos resultados apresentados na saída, mas também do instante em que ele é produzido (KOPETZ, 1997). Sendo assim, um sistema de tempo real deve ter por
ca-racterística a previsibilidade, que é a capacidade de executar ações desejadas dentro de um prazo determinado (MACÊDO et al., 2004). No contexto de redes-em-chip, os pacotes
de tempo real possuem um prazo de entrega (deadline) e os pacotes com prazo expirado são tão defeituosos quanto qualquer outro pacote perdido na rede como consequência de algum outro evento (HESHAM et al., 2017). Essas questões podem ser solucionadas através
da estratégia de alocação de recursos, buscando garantir a entrega dos pacotes dentro do deadline estabelecido (SINGH et al., 2017).
1.1 Objetivos e Contribuições
O principal objetivo deste trabalho é realizar a geração de topologias irregulares cujas configurações sejam tolerantes a falhas e que consigam entregar pacotes com restrição de tempo real (deadline) por mais de um caminho distinto na rede, apresentando resultados menores de latência média quando comparadas a uma topologia mesh-2D regular. Neste trabalho, é considerado como falha o rompimento de um canal de comunicação entre dois roteadores adjacentes, inviabilizando a troca de dados entre eles. Uma topologia gerada deve ser capaz de entregar os pacotes por um caminho alternativo mesmo na ocorrência de falha em um canal.
Uma das principais contribuições desse trabalho é um método de exploração que leva em consideração não apenas a tolerância a falhas da rede, mas também a entrega dos pacotes em tempo real em cenários de falhas na rede. Essas abordagens são largamente exploradas na literatura de redes-em-chip, porém a associação entre elas não é algo tão comum nas pesquisas. A exploração realizada neste trabalho busca eliminar o número de deadlines violados pelas topologias, mas também reduzir o número médio de pacotes que não são entregues dentro do prazo quando a rede apresenta canais rompidos e alguns pacotes partem do nodo origem ao destino por um caminho alternativo.
1.2 Metodologia
As topologias são geradas através de uma exploração de espaço de projeto (DSE – Design Space Exploration) partindo da topologia mesh-2D completa. Métodos em DSE geralmente consideram alguns parâmetros de uma arquitetura do hardware, tais como: número de processadores, quantidades e tamanhos de memórias (PISCITELLI; PIMENTEL,
2012) e realizam testes com diferentes combinações deles, selecionando ao final as configu-rações que atendam às restrições desejadas. O espaço de projeto deste trabalho é composto pelos canais de uma topologia mesh-2D regular, e um algoritmo genético busca combina-ções de canais cujas ativacombina-ções resultem em topologias tolerantes a falhas. Um algoritmo genético busca um mapeamento de tarefas cuja distribuição das tarefas entre os elemen-tos de processamento (EP) atenda à restrição de tempo real. Um algoritmo também foi implementado para o roteamento de pacotes em topologias irregulares. Um módulo foi implementado medir o desempenho da rede quando alguns canais são desativados.
1.3 Organização do trabalho
Este trabalho está organizado da seguinte forma: o capítulo 2 aborda no referencial teórico os principais conceitos de sistemas multiprocessados, redes-em-chip, tolerância a falhas, algoritmo genético e detalha simulador utilizado para a implementação dos algo-ritmos. O capítulo 3 apresenta alguns trabalhos relacionados, comentando alguns projetos acerca de topologias irregulares, tolerantes a falhas, mapeamento de tarefas, e simulação de injeção de falhas. O capítulo 4 detalha a heurística desenvolvida para a exploração de espaço de projeto, a heurística para o mapeamento de tarefas, a estratégia de roteamento e módulo de injeção de falhas na NoC. O capítulo 5 detalha os experimentos realizados e os resultados obtidos nas simulações. Por fim, o capítulo 6 apresenta considerações finais.
2
Referencial Teórico
Este capítulo apresenta os principais conhecimentos que embasaram o desenvolvi-mento deste trabalho. A seção 2.1 discute o conceito de sistemas em chip e sistemas multiprocessados. A seção 2.2 apresenta as redes-em-chip e os seus principais elementos. A seção 2.3 apresenta a área de tolerância a falhas bem como a abordagem seguida neste projeto. A seção 2.4 apresenta o simulador NoC42 e as modificações necessárias para sua adequação a este trabalho. A seção 2.5 finaliza apresentando o algoritmo genético, utilizado na exploração de espaço de projeto descrita no capítulo 4.
2.1 Sistemas Multiprocessados
Ao longo dos anos, a indústria de semicondutores tem trabalhado no sentido de au-mentar a capacidade de integração dos chips, de maneira que os atuais dispositivos VLSI (Very Large-Scale Integrated) alcancem bilhões de transistores dentro de uma única pasta de silício (JERRAYA; WOLF, 2004). Uma consequência deste avanço foi o surgimento dos
sistemas em chip (SoC - System on Chip), arquiteturas que condensam todos os compo-nentes necessários para o funcionamento de um sistema eletrônico (processador, memória, cache, entrada e saída, dentre outros) em um único chip (MARTIN; SMITH, 2009).
No projeto de SoC, passou a ser uma metologia bastante comum a utilização de IP-Cores (IP - Intellectual Property), ou elementos de processamento (EP), que podem ser definidos como blocos pré-existentes obtidos de terceiros (SALEH et al., 2006). Com o tempo, foi possível combinar vários destes blocos dando origem aos sistemas multipro-cessados em único chip (MPSoC - Multiprocessor System-on-Chip), atendendo demandas relacionadas principalmente ao paralelismo na execução de instruções (WOLF, 2004).
A vantagem dos MPSoCs em relação aos SoCs não é comprovada apenas pelo número maior de núcleos de processamento, mas também pela flexibilidade de projetar sistemas de acordo com as características intrínsecas às aplicações (FILHO; PONTES; LEITHARDT,
Purpose) com núcleos voltados à aplicações específicas (ASIC - Application Specific Inte-grated Circuits), por esta razão, eles são largamente utilizados em redes de computadores, telecomunicações, processamento de sinais, aplicações multimídia, e outras aplicações que exigem um alto grau de processamento (WOLF; JERRAYA; MARTIN, 2008).
2.2 Redes-em-Chip
Durante muito tempo, o barramento foi utilizado para a interconexão de vários ele-mentos de processamento em um mesmo chip, porém ele se mostrava ineficiente quando havia o aumento da quantidade de núcleos do sistema, apresentando baixo desempenho de largura de banda, latência média e consumo de energia (MARCULESCU et al., 2008).
As redes-em-chip (NoC) surgiram diante da necessidade de melhorar a comunicação entre vários núcleos em sistemas multiprocessados (MPSoC). Ao contrário do barramento, as redes-em-chip permitem uma maior escalabilidade e paralelismo de comunicação. Os principais elementos que compõem um MPSoC que utiliza rede-em-chip são: roteadores, canais e elementos de processamento, que podem ser processadores, unidades de memória ou também dispositivos de entrada e saída. A Figura 1 exemplifica um MPSoC conectado através de uma rede-em-chip, onde os roteadores (blocos cinzas) estão interligados através de canais (linhas pretas) conectados em suas portas de comunicação, e os elementos de processamentos (círculos laranjas) todos conectados a um roteador através de sua interface de rede.
Figura 1: Exemplo de rede-em-chip
O roteador é o componente que permite a comunicação entre os elementos de proces-samento (BENINI; MICHELI, 2002), os quais encaminham as mensagens até que cheguem
entrada, portas de saída, unidade de arbitragem, algoritmo de roteamento e uma conexão do tipo crossbar que interliga todas as portas de entrada e saída (DUATO; YALAMAN-CHILI; NI, 2002). O RASoC (Router Architecture for SoC ) proposto por Zeferino, Kreutz e Susin (2004), apresentado na Figura 2, é um exemplo de uma arquitetura de roteador presente numa rede-em-chip. Para a comunicação, ele possui quatro portas que permitem a conexão com outros roteadores (North, South, East, West), além de uma porta local (Local) para conectar um elemento de processamento à rede. Internamente, ele possui um controle de fluxo, que lida com a alocação dos canais e bu⇥ers, um árbitro que controla a utilização dos canais de saída, e também um algoritmo de roteamento que indica a porta de saída para qual um pacote será encaminhado.
Figura 2: Roteador RASoC (ZEFERINO; KREUTZ; SUSIN, 2004)
O roteamento em uma NoC determina como os dados serão enviados de um nodo origem até o seu destino (GHOSAL; DAS, 2012). É uma importante característica da rede,
pois é esperado que um algoritmo de roteamento seja capaz de reduzir a latência média na entrega dos pacotes além de reduzir o número de saltos (hops) que um pacote precisará dar da origem até o seu destino. Os algoritmos de roteamento podem ser classificados como determinísticos, quando tomam sempre o mesmo caminho do nodo origem até o destino (LEE; LEE; PARK, 2005), ou como adaptativos, quando são capazes de tomar caminhos
alternativos para a entrega dos pacotes dependendo do tráfego na rede (DEHYADGARI et al., 2005).
A comunicação entre os elementos de uma rede-em-chip é realizada através de mensa-gens. Cada mensagem (Figura 3.a) contém uma parte composta pelos dados de controle, onde o cabeçalho contém as informações necessárias para o roteamento enquanto o
termi-nador indica o final do pacote, e a carga útil contendo os dados trocados entre dois nodos. Para facilitar a sua transmissão na rede, uma mensagem pode ser dividida em vários pa-cotes (Figura 3.b) que, por sua vez, também podem ser divididos em flits (FLow control unITs) que são as menores unidades transmitidas pelos canais (VANGAL et al., 2008).
Figura 3: Mensagem: (a) carga útil e carga de controle; (b) subdivisão da mensagem O chaveamento define como os pacotes são transmitidos na rede através dos roteadores (DUATO; YALAMANCHILI; NI, 2002). Na técnica de chaveamento por circuitos, a conexão
entre origem e destino é estabelecida antes dos pacotes serem transmitidos, de forma que os recursos demandados pela aplicação estejam disponíveis durante toda a transmissão de dados (KUMAR; MANJUNATH; KURI, 2004). Já na técnica de chaveamento por pacotes,
as mensagens são subdividas em pacotes (Figura 3.b) que são transmitidos individual-mente pela rede, sem a necessidade de um caminho dedicado para a comunicação (DALLY; TOWLES, 2001). A primeira abordagem possui a desvantagem de manter recursos
aloca-dos enquanto não está sendo feita transmissão de daaloca-dos entre noaloca-dos, prejudicando assim o desempenho da rede (MELLO et al., 2007). A segunda abordagem pode até demandar
maior complexidade e uma quantidade maior de recursos já que é necessário que os ro-tadores estejam munidos de bu⇥ers intermediários. Por outro lado, é capaz de oferecer redução na latência média dos pacotes, além de conseguir explorar melhor o paralelismo da rede-em-chip.
Quando mais de um pacote requisita a utilização de uma mesma porta de saída simultaneamente, o mecanismo de arbitragem escolhe qual requisição fará uso do canal. Esta resolução interna de conflitos no roteador precisa ser ágil e justa, garantindo um bom desempenho da rede (KAVYASHREE; NEELAGAR, 2016). Em um árbitro centralizado, o
roteador é munido de apenas um mecanismo que enxerga todas as solicitações presentes no momento e realiza a tomada de decisões para todas as portas. Já no modo distribuído, cada
porta possui um árbitro que processa suas solicitações independentemente. A arbitragem distribuída é mais vantajosa do que a centralizada por oferecer um melhor desempenho de latência média (COTA; AMORY; LUBASZEWSKI, 2012), além de ter uma implementação menos complexa.
O Round-Robin (RR) é uma das políticas mais comuns de arbitragem. Ele atribui uma prioridade a cada canal de entrada, e permite que o canal com maior prioridade encaminhe o pacote pela porta de saída que está sendo disputada. Após utilizar a saída uma vez, tal entrada tem a menor prioridade atribuída pelo RR, garantindo uma utilização justa e equilibrada. Os pacotes que não foram encaminhados permanecem armazenados em bu⇥ers localizados nas portas de entrada do roteador aguardando o seu envio nas próximas rodadas do RR. A memorização em bu⇥ers é uma consequência típica do chaveamento de pacotes em cenários de congestionamento da rede devido ao alto tráfego de pacotes. É uma questão que impacta o desempenho da rede em termos de latência média (BOLOTIN et al.,
2004), e está diretamente ligada ao tamanho da área e consumo energético dos circuitos (ZHAO et al., 2011).
O controle de fluxo em uma NoC tem por função o gerenciamento dos recursos alocados para o envio de pacotes (DALLY; TOWLES, 2004). Este mecanismo também é responsável
por uma utilização otimizada de recursos como largura de banda, canais, além de garantir que os pacotes sejam roteados sem deadlock (COTA; AMORY; LUBASZEWSKI, 2012). Um
dos principais modos de controle de fluxo é através do protocolo handshake, no qual o emissor envia um sinal val para informar o envio de um flit ao receptor, que responde com um sinal ack quando houver disponibilidade para o recebimento da informação. Outra técnica viável é a multiplexação de um canal em n canais virtuais (VC - Virtual Channel), os quais fornecem bu⇥ers extras para armazenamento de pacotes em cada canal (MELLO et al., 2005). As vantagens da técnica de VC estão na redução da latência média, além do
aumento da vazão da NoC.
A arquitetura de NoC é caracterizada por sua topologia, que define a maneira como os roteadores estão integrados na rede (ZEFERINO, 2003). Este aspecto possui grande
importância em virtude de sua influência no desempenho do sistema, precisamente em atributos como latência média, área dos circuitos e energia dissipada. É possível classificar as topologias como regulares e irregulares.
Nas topologias regulares, os roteadores estão dispostos de maneira padronizada. Bons exemplos disso são os modelos mesh-2D e toróide-2D. A mesh-2D (Figura 4.a) é com-posta por M xN blocos interconectados que são dispostos regularmente como uma rede de
malha 2D (BHARDWAJ; JENA, 2009), a toróide-2D (Figura 4.b) é semelhante à mesh-2D
diferindo na ligação dos roteadores das bordas. Topologias regulares são ideais para o uso de propósito geral e possuem vantagens em relação ao endereçamento dos roteadores, simplicidade na construção e reutilização dos blocos, porém não são capazes de oferecer um desempenho otimizado às aplicações (TOSUN et al., 2015).
Figura 4: Topologias regulares: (a) mesh-2D; (b) Toróide-2D
Nas topologias irregulares, como na Figura 5, não há um padrão definido na dispo-sição e interconexão dos roteadores. Este tipo de topologia oferece a oportunidade de construir a arquitetura com o objetivo de atender ás restrições de uma aplicação em es-pecífico (SRINIVASAN; CHATHA; KONJEVOD, 2006). Assim, otimizando o desempenho de
área, latência média e consumo energético do sistema em relação àquele obtido quando a mesma aplicação é executada numa rede com topologias regular.
2.3 Tolerância a Falhas
Apesar da confiabilidade alcançada pelos sistemas computacionais ao longo do tempo, eles ainda estão suscetíveis a erros. As causas podem ser múltiplas: desde a má ou incorreta utilização do sistema pelos seus usuários, erros lógicos na programação dos recursos, e em um nível mais profundo, as causas podem estar relacionadas ao mal funcionamento dos componentes eletrônicos dos hardwares que estão executando os programas.
As questões relacionadas à usabilidade dos sistemas são objetos de estudo da área de IHC (Interação Humano-Computador), que analisa o contexto de uso dos sistemas, características dos usuários, a arquitetura dos sistemas, bem como o processo de desen-volvimento (BARBOSA; SILVA, 2010). É uma boa prática de desenvolvimento que alguns
erros causados pelos usuários sejam reversíveis e rapidamente corrigíveis (OLIVEIRA; OLI-VEIRA, 2015), o que minimiza o impacto que uma má utilização possa causar, além de
contribuir para familiarização do usuário com o sistema.
Os sistemas também estão vulneráveis a erros gerados durante o desenvolvimento, os conceitos de Falta e Falha são utilizados para definir estas situações (IEEE, 1989). O
primeiro é descrito como um problema causado pela implementação do software, enquanto o segundo como a manifestação deste problema. As Faltas podem não ser tão percebidas em alguns casos, pois é perfeitamente possível que haja corretude em um código ao mesmo tempo que ele leva o sistema para um estado inconsistente (LAPRIE; RANDELL; AVIZIENIS,
2004). Já as Falhas podem ser mais perceptíveis e se manifestarem de diferentes maneiras, até mesmo causando o travamento total das funcionalidades. É possível a existência de algum nível de tolerância em certos tipos de Falhas, casos nos quais um bloco de código as detecta e leva o sistema para o estado recuperável (BLOCH, 2018), as chamadas Exceções.
Os componentes de hardware também podem estar na raiz das falhas ocorridas nos sistemas. A redução no tamanho dos transistores pode ser vista como algo positivo quando é possível condensar uma maior quantidade em um circuito integrado, mas por outro lado há uma consequência negativa quando a redução nos canais dos transistores aumenta probabilidade de falhas nos circuitos (FOCHI, 2015). Além dessa questão relacionada à
fabricação, há de se constatar que os circuitos se tornam cada vez mais vulneráveis à ocorrência de falhas à medida que o tempo passa, boa parte disso causada pelo envelhe-cimento dos componentes eletrônicos presentes nos chips (YANG et al., 2016). Estas falhas
podem comprometer o funcionamento do sistema de maneira parcial ou até resultar no colapso total do sistema (WEBER, 2003).
As falhas podem ser classificadas em três tipos diferentes: permanentes, transientes, intermitentes (GRECU et al., 2007). As falhas permanentes são aquelas que se manifestam
constantemente afetando os componentes de maneira irreversível, estas podem ocorrer por defeitos de fabricação, rompimento de componentes, ligações incorretas nas placas. As transientes ocorrem em virtude de algum fator temporário externo aos circuitos, como radiação ou interferências eletromagnéticas que comprometem o funcionamento de algum circuito temporariamente. As falhas intermitentes são causadas por fatores não-ambientais como desgaste ou envelhecimentos dos circuitos, que podem prejudicar o funcionamento do sistema somado a algum fator ambiental.
A redundância de hardware é uma das abordagens pela qual é possível alcançar a to-lerância a falhas, esta é baseada na replicação de componentes e repetição da computação por eles realizada. A redundância modular tripla (TMR - Triple Modular Redundancy) é um dos modelos mais simples para mascarar falhas em hardware, foi originada do conceito de redundância tripla de Von Neumann. Exemplificada na Figura 6, a TMR triplica um módulo crítico de falha (hardware nesta abordagem, todavia possível ser software tam-bém) e define o resultado da computação pela maioria simples (3 a 0 ou 2 a 1) das saídas ou por um valor médio (LYONS; VANDERKULK, 1962).
Figura 6: Exemplo de um votador TMR
Em redes-em-chip, a pesquisa de tolerância a falhas visa principalmente minimizar os impactos que falhas possam causar no desempenho, além de aumentar a confiabilidade do sistema. É possível utilizar o modelo OSI (OSI - Open System Interconnection) para organizar os modelos de falhas de acordo com as suas características (RADETZKI et al.,
2013), considerando as camadas de enlace, de dados e de transporte para agrupar os modelos de falhas e as possíveis soluções para mitigá-las (Figura 7).
Figura 7: Modelo OSI em NOC (RADETZKI et al., 2013)
de um canal de comunicação entre dois roteadores adjacentes atinge a camada física da rede. A redundância de hardware constitui uma solução bastante viável para mitigar este tipo de falha, onde é necessário garantir que a rede possua um caminho alternativo entre quaisquer pares de roteadores, permitindo a entrega dos pacotes mesmo que haja falha em algum canal de comunicação (TOSUN et al., 2014).
A Figura 8 apresenta um exemplo de topologia de NoC gerada neste trabalho seguindo o conceito de redundância de hardware. Em um cenário onde o EP conectado ao roteador S (source) envia um pacote ao EP que se encontra conectado ao roteador D (destiny), há a impossibilidade de efetivá-la pelo caminho mais curto caso uma falha interrompa um canal que conecta dois roteadores pelos quais a mensagem será transmitida. Neste caso, é possível combinar topologia e algoritmo de roteamento para fornecer um caminho alter-nativo para o envio dos pacotes. Assim, os pacotes podem transitar através dos roteadores destacados com a cor verde.
2.4 Simulador NoC42
A heurística desenvolvida neste trabalho, detalhada no capítulo 4, simula em hardware a rede configurada com as topologias geradas a fim de coletar dados relacionados ao desempenho obtido quando uma aplicação é executada. Desta forma, é possível atribuir uma nota de qualificação e comparar o seu desempenho com o obtido pelas demais. Esta fase da execução faz o uso de uma versão modificada da ferramenta NoC42
(Network-on-Figura 8: Exemplo de topologia com redundância de hardware nos canais Chip 42 ), desenvolvido por Avelino (2018).
A NoC42 é um simulador versátil codificado na linguagem SystemC baseado na rede SoCIN (SoC Interconnection Network), descrita em (ZEFERINO; SUSIN, 2003). Com o seu
desenvolvimento em um alto nível de abstração, a NoC42 permite a realização de um grande número de simulações em um curto período de tempo.
A SoCIN é uma rede-em-chip escalável que conta com as topologias mesh-2D e toróide. Ela utiliza o roteador parametrizável RASoC (ZEFERINO; KREUTZ; SUSIN, 2004), que
permite ajustar variáveis como largura dos canais, profundidade dos bu⇥ers e algoritmo de roteamento, conforme as necessidades da simulação. Os canais de comunicação de rede SoCIN (Figura 9) são bidirecionais, com cada via oposta enviando n bits de dados, 2 bits para o enquadramento do pacote (SystemC baseado na rede SoCIN (bop e eop), mais dois para o controle de fluxo (val e ack).
Figura 9: Canal de comunicação da SoCIN (ZEFERINO; SUSIN, 2003)
O algoritmo XY é utilizado pela SoCIN para o roteamento dos pacotes. Esta é uma abordagem determinística de baixo custo e livre de deadlock, perfeitamente aplicável em redes bidimensionais. Quando um pacote é enviado de um EP origem para um EP destino (Figura 10), o algoritmo XY prevê que ele primeiramente percorra os roteadores na direção X das linhas para depois percorrer o caminho Y das colunas até o seu destino.
Figura 10: Algorimo de roteamento XY
Em suas demais características, a rede SoCIN possui chaveamento wormhole, onde os pacotes são subdivididos em flits que, ao chegarem no roteador, são encaminhados por uma porta de saída quando há recurso disponível ou ficam armazenados nos bu⇥ers dos roteadores aguardando liberação de recursos. Utiliza uma arbitragem do tipo round-robin, onde cada entrada recebe uma prioridade que define a ordem de utilização do canal de saída, garantindo uma utilização balanceada. Possui um controle de fluxo baseado em handshake, onde o emissor da mensagem ativa um sinal de controle val e o receptor responde com um ack ao consumir o dado.
A SoCIN foi desenvolvida originalmente na linguagem VHDL (VHSIC Hardware Des-cription Language), uma linguagem de modelagem RTL (Register-Transfer Level ) onde os códigos descrevem os circuitos a nível de registrador, portanto, em um baixo nível de abstração. Sínteses VHDL em RTL permitem a observação do comportamento ao longo do tempo (CHEN; MISHRA; KALITA, 2012), porém com um custo de tempo elevado. Isso
torna inviável a sua utilização na exploração desenvolvida neste trabalho, que exige um número elevado de simulações.
Diferentemente da abordagem RTL, a TLM (Transaction-Level Modeling) é um mo-delo que destaca os elementos mais importantes do sistema enquanto diminui o enfoque em detalhes de baixo nível (GAJSKI; RAMACHANDRAN, 1994). Ferramentas TLM, utili-zadas para síntese em alto nível (HLS - High-Level Syntesis), geralmente utilizam um subconjunto da linguagem ANSI C, onde o desenvolvedor combina suas habilidades em linguagens de propósito geral com algum conhecimento em hardware para modelar siste-mas embarcados (ORUKLU et al., 2012). A NoC42 é um versão da rede SoCIN desenvolvida na linguagem SystemC e, por ser uma ferramenta TLM, tornou-se mais adequada para o desenvolvimento deste trabalho pela sua capacidade de realizar um grande número de
simulações com um baixo custo temporal.
Tendo inspiração na SoCIN, a NoC42 permite a variação de parâmetros como: ta-manho dos bu⇥ers, modo de arbitragem (estática, rotativa ou randômica) e algoritmo de roteamento (XY, negative first, north last, west first, odd even). A configuração é defi-nida em um arquivo que a ferramenta recebe como entrada ao efetuar uma simulação. Os algoritmos desenvolvidos neste trabalho foram executados em uma versão modificada do simulador NoC42. As alterações tiveram como principal objetivo tornar a ferramenta capaz de simular a rede com as topologias irregulares propostas neste trabalho.
Em sua versão original, a NoC42 organiza os roteadores em uma topologia regular mesh-2D com dimensões MxN fornecidas na entrada. Neste trabalho, a primeira modifi-cação está localizada no módulo que conecta os roteadores, tornando o simulador capaz de operar com topologias irregulares. No lugar de conectar os roteadores como uma topologia mesh-2D regular, a nova versão deste módulo é capaz de interligar ou não quaisquer pares de roteadores adjacentes.
A segunda modificação realizada no contexto desta dissertação permitiu que a rede fosse capaz de cumprir tempo real. Neste caso, a rede também recebe na entrada o deadline de tempo real de cada pacote e verifica se o mesmo foi cumprido após a sua entrega. O simulador também contabiliza a quantidade de pacotes que não foram entregues dentro do prazo e a retorna na saída do simulador.
Por fim, a última alteração realizada diz respeito à implementação de um algoritmo de roteamento baseado no algoritmo de Floyd-Warshall (FLOYD, 1962), que usa uma
tabela de roteamento (detalhado na seção 4.3). Esta alteração fez-se necessária para que o simulador fosse capaz de rotear os pacotes numa topologia em configuração irregular, o que não era possível com os algoritmos de roteamento presentes na versão original. O novo roteamento demandou o acréscimo de uma tabela em cada um dos roteadores da NoC42, a qual é consultada para determinar o próximo salto de um pacote durante a sua transmissão. As tabelas de roteamento são calculadas com base no grafo da topologia antes da execução de uma simulação. As informações são armazenadas em arquivos de texto que são carregados durante a simulação, que salva em cada roteador a sua tabela correspondente.
2.5 Algoritmo Genético
O algoritmo genético foi proposto por Holland (1975) e baseia-se na teoria da evolução das espécies de Charles Darwin. Esta abordagem faz parte da categoria dos algoritmos evolucionários, os quais possuem inspiração em eventos ocorridos na biologia populacional, na genética evolutiva para criar novas amostras de soluções e atualizar o conjunto das mais aptas à resolução do problema em questão, selecionando as que irão sobreviver para a próxima iteração (LUKE, 2013).
Estes são os principais conceitos envolvidos quando se trata de algoritmos genéticos, cada terminologia biológica foi mapeada para descrever um fato ou objeto correspondente na computação:
• Indivíduo: Uma solução para o problema;
• População: Um conjunto de soluções para o problema; • Gene: Menor parte da solução;
• Cruzamento: Operação em que dois indivíduos têm seus genes combinados para dar origem a um novo;
• Mutação: Ocorre quando uma quantidade de genes é alterada num indivíduo; • Avaliação: Quando os indivíduos são classificados de acordo com a sua aptidão
para solucionar o problema em questão;
• Seleção Natural: Os mais aptos persistem para a geração seguinte enquanto os me-nos aptos são descartados. Serve para regular o número de indivíduos da população a cada geração.
No esquema básico de funcionamento de um algoritmo genérico, como apresentado na Figura 11, a execução inicia com a formação de uma população inicial contendo uma quantidade inicial de indivíduos. Os genes de cada indivíduo podem ser definidos de maneira aleatória, garantindo que as soluções estejam bem distribuídas pelo espaço de busca, além de aumentar a diversidade da população, onde há uma melhor chance de encontrar regiões promissoras (MIRJALILI, 2019).
Após esta fase inicial, o algoritmo entra na fase de otimização onde executa um loop de instruções onde cada iteração corresponde a uma geração. A cada volta, são aplicados
os operadores de cruzamento, mutação, avaliação e seleção natural em um subconjunto de soluções sucessivas vezes até ser atingido um critério de parada.
Figura 11: Esquema básico de um algoritmo genético
Na fase de cruzamento, ocorre a seleção de um grupo de indivíduos que têm suas características combinadas para composição de novas soluções filhas (WANG, 2003). Há
diversas metodologias para a escolha dos indivíduos participante de cada cruzamento, a mais simples é realizada sorteando aleatoriamente um par de indivíduos para gerar uma nova solução. No modo roleta (Figura 12.a), é realizado um sorteio onde as soluções mais aptas possuem maior probabilidades de serem selecionadas para o cruzamento. No torneio de seleção (Figura 12.b), um grupo de n soluções é selecionado e apenas o mais apto persiste para o cruzamento.
Figura 12: Seleção: (a) Por roleta; (b) Por torneio
ponto (Figura 13.a) ou em vários pontos de cruzamento (Figura 13.b). No primeiro caso, os indivíduos pais são divididos em duas partes a partir de um único ponto no cromossomo e as soluções filhas são construídas com a fusão de dois destes trechos. No cruzamento multiponto, os indivíduos pais são divididos em mais de um ponto na solução, podendo dar origem a vários descendentes distintos.
Figura 13: Cruzamento: (a) Em um ponto; (b) Multiponto
O operador de mutação (Figura 14) é responsável por modificar uma parte da estrutura genética dos novos indivíduos. Isso permite aumentar a variedade genética da rede, além de reduzir as chances de uma convergência prematura da qualidade das soluções para um ótimo local (BARROS et al., 2012).
Figura 14: Exemplos de mutação
A função fitness do algoritmo atribui um valor numérico a cada solução segundo a sua aptidão para a resolução do problema proposto. Elas, então, são ordenadas e o operador de seleção natural reequilibra o tamanho da população com o descarte dos indivíduos menos aptos.
Por fim, o algoritmo genético é utilizado neste trabalho na heurística de exploração de espaço de projeto para a otimização topologias tolerantes a falhas. Também é utilizado
na heurística de mapeamento de tarefas para otimização do desempenho da aplicação garantindo a entrega de pacotes e tempo real e para a redução da latência média dos pacotes.
3
Trabalhos Relacionados
A quantidade de projetos de topologias desenvolvidas para uma aplicação específica vem crescendo nos últimos anos, os estudos geralmente desenvolvem métodos de busca de topologias que ofereçam um desempenho otimizado em aspectos como latência média dos pacotes, o consumo de energia da rede, área dos circuitos da rede, tempo real, dentre outros. Os trabalhos discutidos neste capítulo tratam de propostas de topologias irregula-res, topologias tolerantes a falhas, geração de topologias através de métodos heurísticos, mapeamento de tarefas e simulação de injeção de falhas.
3.1 Topologias Irregulares
Choudhary et al. (2010) propõem uma heurística baseada em algoritmo genético para a geração de topologias irregulares de NoC bem como para otimização do desempenho dos requisitos de comunicação da rede. Durante a execução, Figura 15, uma população inicial é gerada e o algoritmo de dijkstra é utilizado para encontrar o menor caminho livre de deadlock entre os IP-Cores. O algoritmo genético proposto considera que o cromos-somo representa uma instância de uma topologia de NoC e cada gene representa uma coleção de caminhos livres de deadlock entre uma fonte e um destino no grafo da rede. Os operadores de mutação, cruzamento e seleção são aplicados para a geração de novos indivíduos na população. A função fitness considera a largura de banda média da rede e o consumo de energia para a topologia gerada. Os experimentos nas topologias foram realizados utilizando vários grafos de tarefas gerados aleatoriamente com diversos requi-sitos de largura de banda. Avaliando a vazão da rede e a latência média dos pacotes, os resultados na topologia irregular com seu próprio algoritmo de roteamento apresentaram melhores resultados do que a mesh-2D com o algoritmo de roteamento XY.
Tosun, Ar e Ozdemir (2012) propõem dois algoritmos para a geração de topologias irregulares com o objetivo de reduzir o consumo de energia da NoC e a diminuição da latência média dos pacotes. O primeiro, denominado TopGen é subdividido em duas fases
Figura 15: Fluxo de Construção da Rede em (CHOUDHARY et al., 2010)
distintas: a primeira decompõe o aplicativo fornecido em clusters baseados no tráfego de comunicação. Em seguida, ele mapeia os clusters nos roteadores e os conecta de maneira que o custo de comunicação da rede seja minimizado. O segundo método, denominado algoritmo de geração de topologia baseado em algoritmo genético (GATGA), cria um con-junto de soluções e usa operadores genéticos para gerar novas topologias a partir delas. Para os experimentos, é realizado o floorplaning da rede após a geração das topologias e avaliados os custos de comunicação e consumo de energia da NoC. Os resultados demons-tram que o desempenho do segundo algoritmo foi superior ao do primeiro algoritmo.
A UTNoC (Undefined Topology Network-on-Chip), proposta por Mesquita (2016), consiste em uma rede de topologia irregular na qual cada roteador pode estar conectado com qualquer outro roteador da rede e a um único core. Esta flexibilidade na ligação dos roteadores, conforme a Figura 16, permite uma vasta exploração e uma grande quantidade de experimentos.
Por se tratar de uma topologia irregular, a rede UTNoC não utiliza os algoritmos de roteamento convencionais, a exemplo do XY. Durante a etapa de comunicação, os rotea-dores (que incialmente só possuem informação sobre a sua adjacência) enviam mensagens de broadcasting até que tenham conhecimento de todos os outros, Figura 17. As infor-mações são utilizadas para a construção de uma tabela de roteamento que permitirá a comunicação entre quaisquer pares de roteadores na rede.
Figura 17: Etapa de broadcasting em (MESQUITA, 2016).
Os experimentos utilizaram um algoritmo genético para explorar o espaço de busca e obter redes UTNoCs considerando 4 aplicações sintéticas, que simulam o comportamento de aplicações com alto e baixo volume de comunicação de dados entre as tarefas. Os resultados alcançados demonstraram que é possível obter redes com desempenho próximo ao grafo da aplicação e com números reduzidos de conexões, resultando numa diminuição da área e do consumo de energia.
O trabalho de Oliveira (2018), visando reduzir latência média, realiza uma exploração de espaço de projeto para encontrar um conjunto de topologias de redes irregulares otimi-zadas para aplicações que suportam tarefas de tempo real e não tempo real. A exploração utiliza um algoritmo genético para otimizar as ligações entre os roteadores e diminuir a área da rede através da retirada de roteadores. O trabalho também utiliza roteadores heterogêneos para tentar diminuir o custo de latência média da rede e entregar os pacotes de tempo real dentro do prazo. Um tipo de roteador, Figura 18.a, possui uma porta local além de 4 portas para comunicação com outros roteadores, um árbitro centralizado, uma tabela de roteamento e um algoritmo de roteamento. O outro modelo de roteador, Figura
18.b, difere do primeiro por fazer uso da técnica de controle de fluxo de canais virtuais.
Figura 18: Modelos de roteadores utilizados por (OLIVEIRA, 2018)
As aplicações utilizadas nos experimentos deste trabalho são sintéticas e estão dividi-das em dois conjuntos: um com 10 tarefas associadividi-das e outro com 15 tarefas associadividi-das. Elas executaram num simulador de arquitetura de rede-em-chip desenvolvido em SystemC. Os experimentos iniciam com deadline de tempo real longo e vão diminuindo gradativa-mente até se descobrir quando a rede deixa de atender as necessidades do projeto. Os resultados mostraram que as topologias irregulares com roteadores heterogêneos atendem os requisitos de latência média, área e prazo de entrega dos pacotes de tempo real, e possuem desempenho superior a redes com topologia mesh-2D.
3.2 Topologias Tolerantes a Falhas
Koupaei, Khademzadeh e Janidarmian (2011) propõem uma NoC tolerante a falhas na qual é possível entregar 100% dos pacotes mesmo que um dos roteadores apresente falhas. O projeto explora a diversidade de caminhos entre roteadores adjacentes com a adição de um novo componente denominado Link Interface (LI), Figura 19. Na arquitetura proposta (Figura 20), cada núcleo é conectado ao seu roteador através da porta local principal, e aos links utilizando a LI através da porta local de backup. Quando duas portas de entrada solicitam simultaneamente uma porta de saída, o mecanismo de prioridade é acionado para resolver o problema.
Se ambos os roteadores estiverem funcionando corretamente, o principal será utilizado para o encaminhamento do pacote, caso o roteador principal esteja defeituoso, o caminho sobressalente será eleito. Tabelas de roteamento armazenam os caminhos possíveis na rede
Figura 19: Interface de link em (KOUPAEI; KHADEMZADEH; JANIDARMIAN, 2011).
Figura 20: Arquitetura proposta em (KOUPAEI; KHADEMZADEH; JANIDARMIAN, 2011)
e são utilizadas de acordo com as condições dos roteadores.
Tosun et al. (2014) apresentam um método para geração de topologias tolerantes a falhas capazes de entregar pacotes por um caminho alternativo em caso de falha de um canal, além de um algoritmo de mapeamento de aplicações visando minimizar o consumo de energia da NoC. Inicialmente, o método proposto gera de maneira aleatória uma to-pologia irregular não tolerante a falhas com um número mínimo de roteadores e canais, depois adiciona canais extras para obter uma versão tolerante a falhas da topologia. O projeto proposto pode ser aplicado para vários cenários de falhas, havendo redução no desempenho da rede em ambos os casos:
1. Falhas em canais causadas no processo de fabricação do chip; 2. Falhas em canais que ocorrem devido ao ciclo de vida do chip.
Os experimentos comparam o desempenho das topologias tolerantes a falhas com as versões que não são tolerantes a falhas executando a mesma aplicação, um decodificador MP3. Os resultados evidenciaram que o método conseguiu trazer a tolerância a falhas às topologias com um pequeno aumento na área e no consumo de energia da NoC.
O trabalho descrito em (SHAH; KANNIGANTI; SOUMYA, 2017) propõe um algoritmo
guloso baseado em teoria dos grafos para geração de topologias tolerância a falhas, focando na busca de topologias com o mínimo custo de comunicação e redundância de hardware de forma que suporte falha nos links.
Bezerra (2019) propõe um algoritmo para a geração de topologias tolerantes a falhas com foco na redundância de canais, garantindo que haja caminhos alternativos entre dois roteadores na NoC. Uma busca-tabu foi implementada para realizar essa tarefa, ela possui a capacidade de escapar dos ótimos locais e encontrar uma solução ideal global. A solução foi gerada com base em oito gráficos de tarefas: quatro sintéticos e quatro baseados em aplicativos reais. O algoritmo proposto possui três estágios principais: geração inicial da topologia, pesquisa da melhor solução e injeção de falhas. O primeiro passo realiza a geração aleatória de uma solução inicial viável dado um grafo de tarefas. A segunda etapa realiza uma busca-tabu para encontrar novas soluções locais através de operações de modificação na solução inicial, desempenhando uma busca na vizinhança (Figura 21). A lista-tabu previne que uma mesma solução seja visitada múltiplas vezes. O terceiro passo estressa a topologia gerada, escolhendo aleatoriamente uma quantidade de canais da rede para falhar.
Os experimentos executaram as topologias trinta vezes considerando cinco cenários diferentes, nos quais 10%, 15%, 20%, 25% e 30% do total dos canais foram removidos da NoC. Os resultados mostraram que a estimativa da latência média diminuiu à medida que se aumentou o número de canais da solução. Além disso, as topologias com alguns canais a mais do que uma topologia em anel resistiram de 10% a 30% de falha aleatória dos canais.
3.3 Mapeamento de Tarefas
No contexto de mapeamento de tarefas, Shi (2009) utiliza um algoritmo genético com duas funções fitness para otimizar o desempenho da rede, buscando alocações de tarefas que possam satisfazer os deadlines de tempo real da aplicação além de minimizar o consumo de energia da rede.
Figura 21: Cenários de Busca em (BEZERRA, 2019)
Os experimentos levaram em consideração uma aplicação automotiva contendo 33 tarefas e 39 trocas de comunicações, e uma aplicação sintética contendo 50 tarefas e 50 comunicações. Utilizando topologia mesh-2D de dimensões 4x4 e 5x5 e roteamento XY, foi possível executar a aplicação sem violações do deadline de tempo real e reduzir o consumo de energia da rede.
O trabalho descrito em (MESIDIS; INDRUSIAK, 2011) propõe um algoritmo genético
com o objetivo de encontrar um mapeamento onde todos os fluxos de tráfego de uma aplicação hard real-time sejam transmitidos dentro de seus respectivos deadlines, mesmo no pior caso de execução. A execução do algoritmo inicia com a geração de uma população de mapeamentos aleatórios. A etapa de seleção do algoritmo calcula o score de cada ma-peamento e a pontuação média de todos os mama-peamentos da geração atual, em seguida, descartando todos os mapeamentos com pontuação superior à média. Em seguida, a popu-lação é novamente equilibrada utilizando o operador de cruzamento para geração de novos indivíduos. Cada membro da população sofre mutação com uma probabilidade de 50%. Essas etapas são repetidas até uma solução adequada ser encontrada. Os experimentos consideraram aplicações veiculares e aplicações sintéticas executando em NoCs de dimen-sões 5x5, 4x4, 4x3 e 3x3. Com 15 execuções realizadas para cada cenário, o algoritmo só não conseguiu encontrar uma solução para a NoC de dimensões 3x3.
Em (AVELAR; PENNA; FREITAS, 2014), é proposta uma estratégia baseada no
uti-lizando o conceito de distância euclidiana mínima. A heurística apresenta resultados me-lhores quando comparada à estratégia de biparticionamento recursivo dual (PELLEGRINI,
2008) e à heurística gulosa proposta por Oliveira et al. (2011).
O algoritmo recebe como entrada uma matriz (C ) contendo o custo da comunicação de cada processo para os demais, o número de clusters (k) e a distância de comunicação mínima desejável entre os processos de um mesmo cluster (d). Um vetor (M ) indicando o mapeamento dos processos nos núcleos de processamento é retornado na saída do algo-ritmo. Durante a execução, os processos são distribuídos inicialmente de maneira aleatória entre os clusters. Em seguida, o centróide de cada cluster é calculado a partir da média dos custos de comunicação dos processos contidos neles. Depois, os processos são rea-grupados considerando sua distância euclidiana para os centróides de cada cluster, sendo atribuídos ao cluster mais próximo. O processo é realizado enquanto todos os processos se encontrarem a uma distância maior do que d do centróide do seu respectivo cluster.
Indrusiak, Dziurzanski e Singh (2016) apresentam uma heurística para realizar o ma-peamento de tarefas em uma aplicação no padrão AUTOSAR (AUTomotive Open System ARchitecture), que é composta por itens atômicos mapeados estaticamente chamados de runnables, os quais podem ser agrupados em clusters denominados como modes, cujos mapeamentos de tarefas são independentes uns dos outros. Devido às restrições de hard real-time dos sistemas automotivos, todas as tarefas precisam ser executadas dentro de um deadline de pior caso estabelecido. O mapeamento das tarefas é realizado estaticamente utilizando um algoritmo genético no qual novos indivíduos são obtidos e classificados por sucessivas gerações a partir de uma população de soluções pré-existentes. Uma função de avaliação é aplicada aos mapeamentos atribuindo penalidades nos resultados para cada violação de deadline apresentada nos indivíduos. Um torneio de seleção é realizado para a escolha dos indivíduos com a finalidade de gerar novas amostras através de cruzamento e mutação. Este processo é realizado por repetidas vezes até ser atingido o critério de parada.
3.4 Injeção de Falhas
O trabalho dos autores Sterpone, Sabena e Reorda (2012) propõe um ambiente de injeção de falhas que pode ser utilizado para avaliar a capacidade de tolerância a falhas de diferentes arquiteturas de NoC. A solução proposta é capaz de emular diferentes modelos de falhas que afetam as NoCs, além de oferecer a possibilidade de observação dos testes
uma vez que é possível monitorar o estado das interconexões e o comportamento dos roteadores durantes a injeção de falhas.
A arquitetura, ilustrada na Figura 22 é baseada em FPGA (Field Programmable Gate Array) e consiste em dois processadores: o primeiro dedicado à aplicação de teste, en-quanto o segundo realiza a injeção das falhas. A injeção de falhas não requer a adição de módulo intrusivo na arquitetura NoC, uma vez que as falhas são inseridas fisicamente alterando os bits do dispositivo FPGA.
Figura 22: Arquitetura proposta por (STERPONE; SABENA; REORDA, 2012)
Os experimentos foram realizados utilizando o NoCem (Network on Chip emulator), um simulador de código aberto baseado em FPGA que permite alterar parâmetros de configurações da rede, esquemas de bu⇥er e arbitragem. O simulador levou em média 73ms para injetar cada falha, tendo sido capaz de detectar mais de 90% delas. Comparando com o Tetramax fault simulation tool, a solução proposta reduziu em menos da metade o tempo total de execução da simulação.
Em (HORSTMANN; FRöHLICH, 2020), os autores propõem uma estrutura não intrusiva
para injetar e monitorar falhas em componentes de sistemas embarcados multicore de tempo real (sensores, sistema operacional e HPC (Hardware Performance Counters)) sem prejudicar as características temporais das tarefas que estão sendo executadas. O processo de injeção de falhas é independente da plataforma de hardware e pode definido em tempo de compilação ou em tempo de execução. O desempenho do framework foi avaliado em termos do overhead do tempo de execução e do impacto na execução de tarefas críticas. A
simulação apresentou overhead de tempo médio de execução de 4.864,33s em um tempo de execução médio de 4.857.654,85s, representando 0,1001% da execução, e um jitter médio não superior a 5,0096s. Na conclusão, o autor reforça que framework proposto é adequado para simular o comportamento de sistemas críticos diante de falhas.
3.5 Considerações Finais
Ao comparar este trabalho com os projetos que abordam geração topologias irregulares e topologias tolerantes a falhas, há semelhanças quando praticamente todos propõem uma abordagem heurística para explorar o espaço de busca dos canais e dos roteadores a fim encontrar novas topologias que apresentem desempenho otimizado para uma aplicação específica. As diferenças em relação aos trabalhos de Choudhary et al. (2010), Tosun, Ar e Ozdemir (2012) e Oliveira (2018), os quais tratam topologias irregulares, ocorrem quando não há neles a preocupação de construir topologias com a configuração tolerante a falhas, pois apenas o desempenho otimizado em uma aplicação específica é buscado.
O trabalho de Koupaei, Khademzadeh e Janidarmian (2011) possui semelhanças com este quando aborda conceito de redundância de hardware para mitigar falhas em um roteador (aqui este conceito é aplicado nos canais), porém não utiliza nenhum método de otimização combinatória para alocar os recursos extras de hardware de maneira mais eficiente. Embora este trabalho compartilhe com Bezerra (2019) a preocupação com a existência de múltiplos caminho para a entrega de um mesmo pacote numa topologia tolerante a falhas, ambos são distintos na abordagem heurística para a construção de topologias (aqui é utilizado algoritmo genético enquanto o autor utiliza busca-tabu). Além disso, também há uma diferenciação pelo fato de que este trabalho acrescenta aos critérios de busca a entrega dos pacotes de tempo real dentro do prazo estabelecido (deadline).
Em relação às propostas de injeção de falhas, este trabalho se assemelha a (STERPONE; SABENA; REORDA, 2012) e (HORSTMANN; FRöHLICH, 2020) quando ambos os trabalhos
selecionam uma característica específica para injetar falhas e analisar o impacto no desem-penho. Porém as principais diferenças ocorrem quando este trabalho realiza o processo de injeção das falhas apenas em tempo de compilação, com cenários que persistem do início até o final da compilação, enquanto os dois trabalhos citados inserem as falhas em tempo de execução.
4
Algoritmos Desenvolvidos
Este capítulo descreve os algoritmos desenvolvidos neste trabalho: um algoritmo que realiza uma exploração do espaço de projeto para obtenção de topologias irregulares cujas configurações sejam tolerantes a falhas, outro algoritmo genético que realiza o mapea-mento de tarefas em aplicações com deadline de tempo real, um algoritmo para o rotea-mento de pacotes nas topologias geradas, um módulo para injeção de falhas em topologias de redes-em-chip.
4.1 Exploração de Espaço de Projeto
As topologias são geradas através de um algoritmo genético que busca combinações de canais que constituam uma rede tolerantes a falhas e capazes de entregar pacotes respeitando o deadline de tempo real. A escolha dessa abordagem heurística se justifica tanto pela sua boa adaptabilidade ao problema proposto quanto pela objetividade na realização de testes e obtenção de resultados.
O algoritmo genético proposto realiza uma exploração de espaço de projeto (DSE -Design Space Exploration) nos canais de comunicação de uma topologia regular mesh-2D. O método de DSE é bastante difundido na construção de sistemas e permite ajustar os vários parâmetros de uma arquitetura com o objetivo de atender aos requisitos necessários de uma aplicação (PISCITELLI; PIMENTEL, 2012). Em NoC, este método permite avaliar
as características da rede durante a fase de design, construindo uma rede para obter desempenho otimizado (OLIVEIRA; KREUTZ, 2020).
A geração de novas topologias teve como ponto de partida uma topologia mesh-2D como a apresentada na Figura 23. Inicialmente, apenas os canais mais externos se en-contram ativados, de forma similar a uma topologia anel. A quantidade de roteadores e a quantidade de tarefas da aplicação fornecida como entrada não interferem no método aqui proposto, sendo possível haver uma diferença na quantidade de ambas com variação
