Departamento de Informática e Matemática Aplicada Bacharelado em Ciência da Computação
SONNE - Projeto de SDNoC para MPSoCs
Heterogêneos
Raul Silveira Silva
Natal-RN Junho de 2019
SONNE - Projeto de SDNoC para MPSoCs
Heterogêneos
Monografia de Graduação apresentada ao Departamento de Informática e Matemática Aplicada do Centro de Ciências Exatas e da Terra da Universidade Federal do Rio Grande do Norte como requisito parcial para a ob-tenção do grau de bacharel em Ciência da Computação.
Orientadora:
Prof
a. Dr
a. Monica Magalhães Pereira
Universidade Federal do Rio Grande do Norte – UFRN Departamento de Informática e Matemática Aplicada – DIMAp
Natal-RN Junho de 2019
Silva, Raul Silveira.
SONNE - Projeto de SDNoC para MPSoCs heterogêneos / Raul Silveira Silva. - 2019.
65f.: il.
Monografia (Bacharelado em Ciência da Computação)
-Universidade Federal do Rio Grande do Norte, Centro de Ciências Exatas e da Terra, Departamento de Informática e Matemática Aplicada. Natal, 2019.
Orientadora: Monica Magalhães Pereira.
1. Computação - Monografia. 2. MPSoC - Monografia. 3. RedesemChip Monografia. 4. SDNoC Monografia. 5. TLP
-Monografia. 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
rogêneos apresentada por Raul Silveira Silva e aceita pelo Departamento de Informática e Matemática Aplicada do Centro de Ciências Exatas e da Terra da Universidade Federal do Rio Grande do Norte, sendo aprovada por todos os membros da banca examinadora abaixo especificada:
Profa. Dra. Monica Magalhães Pereira
Orientador(a)
Departamento de Informática e Matemática Aplicada - DIMAp Universidade Federal do Rio Grande do Norte - UFRN
Prof. Dr. Márcio Eduardo Kreutz
Departamento de Informática e Matemática Aplicada- DIMAp Universidade Federal do Rio Grande do Norte - UFRN
Profa. Ma. Alba Sandyra Bezerra Lopes
Instituto Federal de Educação, Ciência e Tecnologia do Rio Grande do Norte - IFRN
Agradecimentos
Agradeço aos meus pais, Márcio Antônio e Alzeny, por todo o suporte e educação que me deram. Ao meu tio e padrinho, Antônio Marconi, que sempre acreditou no meu potencial e nunca me deixou desanimar com os problemas, sempre me aconselhando na vida acadêmica e pessoal.
Agradeço também à minha professora e orientadora, Profa Monica, por depositar
sua confiança em mim desde o início da minha graduação, me orientando tanto na vida acadêmica quanto na vida pessoal, me ajudando sempre a ser um cientista e ser humano melhor. Ao meu professor do IF (Instituto Federal), Prof. Alvaro, que me ajudou na transição do IF para a universidade, me apresentado aos professores e laboratórios para que eu pudesse dar os meus primeiros passos na graduação.
Ao meu amigo, Felipe Barbalho, que desde o IF trabalhou comigo em diversos projetos envolvendo Arduino e Raspberry Pi, nossas grandes ferramentas para grandes ideias. Ao meu amigo, Wanderson Medeiros, pela nossa grande amizade e a conquista de construir o Connected Garden e ganhar dois prêmios da Intel, sendo um nacional e outro mundial na China. Aos meus amigos que fiz durante a graduação, Breno, Débora, Gustavo "Koruja", Patrícia e Vitor Godeiro, pelas risadas, lágrimas e projetos que tivemos em todos esses anos. Aos meus amigos do LASIC (Laboratório de Sistemas em Chip), Adelino, Hélio, Hiago, Jefferson e João Paulo, pelo conhecimento compartilhado e pelas risadas. Aos amigos do PET, pelas oportunidades de participar de várias atividades.
Por fim, à todos os professores do DIMAp (Departamento de Informática e Matemá-tica Aplicada) e IMD (Instituto Metrópole Digital), por todo o aprendizado que adquiri durante minha graduação.
consegue imaginar. Alan Turing
Heterogêneos
Autor: Raul Silveira Silva Orientadora: Profa. Dra. Monica Magalhães Pereira
Resumo
Sistemas em Chip Multiprocessados (MPSoCs) são sistemas computacionais compostos por vários núcleos de processamento e agrupados em uma única pastilha de silício. A pos-sibilidade de construir sistemas desse tipo ocorre devido a miniaturização do transistor, causada principalmente pela evolução na tecnologia de fabricação dos circuitos integra-dos. Os MPSoCs permitem que uma aplicação possa ser executada de forma mais rápida através da distribuição de tarefas (segmentos da aplicação que podem ser executados simultaneamente) entre os seus núcleos de processamento. Contudo, essas tarefas geral-mente trocam informações entre si e, para isso, necessitam de um meio de comunicação. As redes-em-chip (NoCs) são exemplos de arquiteturas de comunicação utilizadas para esse objetivo. As NoCs são capazes de melhorar a comunicação entre os núcleos devido a sua natureza arquitetural, disponibilizando caminhos alternativos para troca de informação. Nas NoCs convencionais, é comum o uso de algoritmos de roteamento determinísticos que definem uma rota única para a comunicação, pois são melhores para evitar problemas de concorrência como deadlock e simples para serem integrados aos roteadores. Entretanto, o uso de rotas determinísticas pode causar um forte congestionamento na rede. Um outro paradigma de NoC é o paradigma de redes-em-chip definidas por software (SDNoCs), onde o roteamento é feito em software por um núcleo gerente capaz de construir e desconstruir circuitos virtuais, de forma a estabelecer uma comunicação entre os núcleos. Isso permite o uso de algoritmos de roteamento adaptativos e que também possam evitar deadlocks, pois o núcleo gerente conhece todo o comportamento da rede. Este trabalho descreve a proposta e implementação de uma SDNoC e apresenta uma investigação do comporta-mento ao intensificar o tráfego das mensagens trocadas entre os núcleos de processacomporta-mento. Além disso, também é feita uma comparação com uma NoC convencional.
MPSoCs
Author: Raul Silveira Silva Advisor: Profa. Dra. Monica Magalhães Pereira
Abstract
Multiprocessor Systems-on-Chip (MPSoCs) are computer systems composed by multiple processing cores and grouped into a single chip. The design of those systems occurs due to miniaturization of the transistor, caused by the evolution in the technology for design integrated circuits. The MPSoCs allows applications to run faster by distributing threads (application segments that can run simultaneously) over the processing cores. However, these tasks usually exchange information with each other, which require a communication method inside the MPSoC. Networks-on-Chip (NoCs) are examples of communication ar-chitectures used for this purpose. NoCs are able to improve communication between the processing cores, providing alternative paths to exchange information. In the conventional NoCs, it is common to use deterministic routing algorithms which define a single route for communication, since they try to avoid concurrent problems, as deadlock, and are simple to be integrated on the routers. However, the use of deterministic routes can cause network congestion. Another NoC’s paradigm is the Software-Defined Networks-on-Chip (SDNoCs), which the routing algorithms are implemented in software, executed in a core manager and it is possible to establish and unestablish virtual circuits to provide the communication between the cores. This allows the use of adaptive routing algorithms and also avoiding deadlocks, since the core manager knows the network’s behaviors. This work describes the proposal and implementation of an SDNoC, also presenting an investiga-tion on it’s behavior when the traffic message’s exchange increases. Besides, the SDNoC simulations are compared with a normal NoC.
Lista de figuras
1 MPSoCs homogêneos e heterogêneos . . . p. 19 2 Modelos de memória . . . p. 20 3 Exemplo de um grafo de tarefas . . . p. 22 4 Exemplos de topologias de rede . . . p. 23 5 Exemplos de algoritmos de roteamento . . . p. 27 6 Arquitetura de um roteador . . . p. 27 7 Exemplo de SDNoC . . . p. 29 8 Modelagem de comunicação com árbitro usando redes de Petri coloridas p. 31 9 Integração de uma NoC com uma arquitetura baseada em SDNoC . . . p. 33 10 Arquitetura do roteador com controle de configuração . . . p. 34 11 Processo de requisição de rota para troca de mensagens . . . p. 36 12 Comunicação do núcleo de processamento com gerente e roteador . . . p. 37 13 Grafo de rotas disponíveis . . . p. 38 14 Arquitetura do núcleo gerente . . . p. 39 15 Comunicação do núcleo gerente com roteador . . . p. 39 16 Arquitetura do roteador SONNE . . . p. 40 17 Conteúdo de um arquivo de tráfego SONNE . . . p. 44 18 Visualizações do grafo de tarefas gerado pelo TGFF . . . p. 47 19 Pesos das arestas do grafo com 16 tarefas . . . p. 47 20 Categorias dos grafos de tarefas . . . p. 48 21 Amostras de grafos de uma mesma categoria . . . p. 49 22 Grafo da categoria 2 em uma rede 4x4 . . . p. 49
24 Atraso médio na categoria 1 . . . p. 52 25 Atraso máximo na categoria 1 . . . p. 53 26 Tempo total de simulação na categoria 1 . . . p. 53 27 Rotas XY dos grafos da categoria 2 . . . p. 55 28 Atraso médio na categoria 2 . . . p. 56 29 Atraso máximo na categoria 2 . . . p. 57 30 Tempo total de simulação na categoria 2 . . . p. 57 31 Tempo total de simulação na categoria 3 . . . p. 59
Lista de abreviaturas e siglas
API – Application Programming Interface CPU – Central Processing Unit
CR – Core
DSP – Digital Signal Processor EPS – Encapsulated PostScript Flit – Flow Control Unit
FPGA – Field Programmable Gate Array GPU – Graphics Processing Unit
MPI – Message Passing Interface
MPSoC – Multiprocessor System-on-Chip ND – Network Dimensions
NoC – Network-on-Chip Phit – Physical Unit
SDNoC – Software-Defined Network-on-Chip SoC – System-on-Chip
SoCIN – SoC Interconnection Network TGFF – Task Graphs for Free
TLP – Thread-Level Parallelism
VCG – Visualization of Compiler Graphs VLSI – Very-large-scale Integration
Lista de algoritmos
1 XY . . . p. 42 2 Dijkstra . . . p. 43 3 CastNet (TOSUN et al., 2015) . . . p. 51
Sumário
1 Introdução p. 14
1.1 Organização do trabalho . . . p. 16
2 Fundamentação Teórica p. 18
2.1 Sistemas em Chip Multiprocessados . . . p. 18 2.2 Aplicações para MPSoCs . . . p. 20 2.3 Redes-em-Chip . . . p. 22
3 Trabalhos Relacionados p. 30
3.1 Redes-em-Chip Convencionais . . . p. 30 3.2 Redes-em-Chip Definidas em Software . . . p. 32 4 SONNE - Arquitetura e Organização da SDNoC p. 35 4.1 Arquitetura e Funcionamento . . . p. 36 4.2 Organização da Rede . . . p. 39 4.3 Algoritmos de Roteamento . . . p. 40 4.4 Simulações e Coleta de Resultados . . . p. 41 5 Resultados Experimentais p. 45 5.1 Modelagem das Aplicações . . . p. 45 5.2 Categoria 1 de Simulações . . . p. 50 5.3 Categoria 2 de Simulações . . . p. 54 5.4 Categoria 3 de Simulações . . . p. 56
1
Introdução
Em 1958, com a construção de um circuito integrado de um oscilador simples com-posto por um transistor, três resistores e um capacitor, Jack St. Clair Kilby, da Texas Instruments, demostrou que era possível construir circuitos complexos a partir da inte-gração de transistores com outros componentes eletrônicos ao invés de utilizar válvulas (DEFFREE, 2018). As válvulas são componentes eletrônicos, maiores que os transistores, e
que necessitam de um tempo de aquecimento para permitir o fluxo de corrente elétrica em um circuito. Por sua vez, os transistores são componentes eletrônicos de tamanho menor e que não necessitam de pré-aquecimento para transmissão de corrente elétrica. O projeto de Kilby serviu de inspiração para o primeiro microchip e causou uma mudança na tecnolo-gia de fabricação de circuitos, possibilitando a miniaturização dos mesmos (TEAM, 1999).
Atualmente, o transistor está presente em diversos computadores e sistemas embarcados em dispositivos do tamanho de um cartão de crédito.
Com as vantagens do transistor, os fabricantes de computadores começaram a migrar o uso de válvulas em circuitos eletrônicos para transistores. Junto a isso, a tecnologia de fabricação de chips foi evoluindo e miniaturizando o tamanho dos circuitos internos. Com o circuito menor, foi possível integrar uma maior quantidade de componentes eletrônicos em um único chip, aumentando a quantidade dos recursos de hardware disponíveis. Ob-servando esse avanço tecnológico na fabricação de chips, o cofundador da Intel, Gordon E. Moore, em 1965 fez uma previsão de que a capacidade de transistores em um único chip dobraria a cada 18 meses. Essa previsão ficou conhecida como a Lei de Moore (MOORE,
1965).
Com o passar do tempo, essa miniaturização tem permitido a construção de sistemas computacionais mais robustos, com mais recursos e maior poder de processamento. A grande quantidade de recursos está relacionada com a integração dos módulos computaci-onais como memória, processador, unidades de controle, entre outros. Esses sistemas são conhecidos como SoCs (Systems-on-Chip - Sistemas em Chip). Quanto ao poder de pro-cessamento, a relação é com a quantidade de núcleos de processamento integrados no chip,
formando os MPSoCs (Multiprocessor Systems-on-Chip - Sistemas em Chip Multiproces-sados) (WOLF; JERRAYA; MARTIN, 2008). Os MPSoCs contribuem para um aumento de
desempenho de aplicações computacionais por permitirem execuções simultâneas de dife-rentes aplicações, além de permitir a segmentação da aplicação em tarefas e executá-las, simultaneamente, nos diversos núcleos de processamento. Esse nível de execução simultâ-nea de tarefas é conhecido como TLP (Thread-Level Parallelism - Paralelismo em Nível de Tarefa).
No cenário de exploração em TLP, é possível que algumas tarefas necessitem trocar in-formações entre si. Para isso, faz-se necessário estabelecer um meio de comunicação entre os núcleos do MPSoC. Inicialmente, durante o surgimento dos MPSoCs, a comunicação entre os núcleos era feita por meio de barramentos, onde linhas de comunicação (canais) poderiam ser compartilhadas por mais de um núcleo. Embora isso provesse uma comuni-cação mais direta, o sistema poderia perder em desempenho de execução conforme fossem anexados mais núcleos ao barramento. Esse problema poderia ocorrer em cenários onde a comunicação entre as tarefas fosse mais intensa e o barramento, que era único para cada comunicação, estivesse sempre congestionado, aumentando o tempo de espera de cada tarefa para uso do canal. Uma solução para esse problema foi proposta através da obser-vação das estruturas e comportamentos das redes de computadores. Uma organização dos núcleos de processamento em estruturas de comunicação compostas por roteadores e ca-nais de transmissão de dados que interligam esses roteadores poderia permitir uma melhor forma de comunicação entre os núcleos do MPSoC. Tal estratégia evitaria o longo tempo de espera das tarefas para disponibilidade do canal de comunicação, uma vez que uma interconexão feita com roteadores permitiria estabelecer uma comunicação por caminhos alternativos. Esse conceito de redesemchip recebeu o nome de NoC (NetworkonChip -Rede-em-Chip) (ZEFERINO; SUSIN, 2003) e é utilizado em MPSoCs com muitos núcleos
integrados.
Contudo, ainda há, para as redes-em-chip, algumas desvantagens. As rotas de comu-nicação podem ser compartilhadas por mais de um par de núcleos de processamento, a depender do algoritmo de roteamento que devem evitar situações de deadlock, starvation, entre outros problemas de concorrência. Além disso, a arquitetura interna de um rotea-dor pode ser bastante complexa, impactando diretamente no seu tamanho. Nesse ponto, existe um outro paradigma de NoCs, as SDNoCs (SoftwareDefined NetworksonChip -Redes-em-Chip Definidas por Software). Diferente das NoCs convencionais, as SDNoCs possuem roteadores mais simples e menores, que estabelecem a comunicação interna atra-vés de um chaveamento por circuito chamado de circuito virtual. Essa virtualização dos
circuitos é definida em nível de software, por um núcleo de processamento central. As rotas são exclusivas para cada comunicação, permitindo uma troca de informação direta e mais rápida entre as tarefas. As SDNoCs são úteis na criação de canais dinâmicos de comunicação, uma vez que um circuito entre um recurso e outro é estabelecido apenas durante a troca de informação e liberado após a última mensagem ser recebida. Isso per-mite que o circuito possa ser criado apenas quando for necessário (BERESTIZSHEVSKY et al., 2017).
Nesse contexto de MPSoCs e SDNoCs, este trabalho apresenta uma investigação do comportamento de MPSoCs com arquitetura de comunicação baseada em SDNoCs. A hi-pótese sobre o comportamento do sistema é de que ao aumentar o tráfego de informações entre os núcleos do MPSoC, uma SDNoC consiga evitar por mais tempo um congestiona-mento na rede em comparação com uma NoC convencional.
1.1 Organização do trabalho
No Capítulo 2 é apresentada a fundamentação teórica, a fim de contextualizar o leitor sobre as arquiteturas e organizações dos sistemas computacionais explorados nesse trabalho. Nesse capítulo é feita uma contextualização sobre os MPSoCs, apresentando suas estruturas e aplicações computacionais divididas em tarefas. Em seguida, são apresentados os conceitos de redes-em-chip convencionais e SDNoCs, abrangendo topologias de redes, roteamento, arquitetura de roteadores e comunicação.
O Capítulo 3 apresenta uma revisão bibliográfica dos principais trabalhos que estão relacionados com esta monografia. Nesse capítulo as discussões estão divididas em duas seções. A primeira seção apresenta os trabalhos refentes à redes-em-chip. Já a segunda seção apresenta os mais recentes trabalhos que propõem o uso de SDNoCs.
No Capítulo 4 são apresentadas a arquitetura, organização e funcionamento da SDNoC proposta para a avaliação. Nesse capítulo, a arquitetura é descrita a composição de cada componente da rede e seu funcionamento. A organização é descrita pela estrutura de interconexão de cada um desses componentes formando a topologia da rede. Em seguida são apresentados os algoritmos de roteamento implementados, seguidos pela explicação de como as simulações podem ser feitas e analisadas.
Os experimentos realizados são apresentados e discutidos no Capítulo 5. Inicialmente são discutidas as formas de modelagem em grafos de tarefas das aplicações multicores, categorizando-as em 3 grupos. Em seguida são apresentados os resultados das simulações
dos grupos de grafos para avaliações de atraso médio e máximo de requisições de rotas na SDNoC, juntamente com comparações de tempo total de simulação entre os diferentes algoritmos da SDNoC e com uma rede convencional simulada pela ferramenta Noxim (CATANIA et al., 2015).
Por fim são apresentadas as considerações finais sobre o trabalho, concluindo a inves-tigação e apresentando as vantagens e desvantagens do uso de SDNoCs como arquiteturas de comunicação em MPSoCs. Além disso, são apresentadas propostas de trabalhos futuros que podem seguir a partir dessa investigação.
2
Fundamentação Teórica
Neste capítulo são apresentados os conceitos fundamentais para contextualizar o lei-tor em relação à esta monografia. Os conceitos descritos aqui estão divididos em três seções. A primeira seção aborda os conceitos sobre MPSoCs, apresentando suas principais características e os motivos que contribuíram para o seu surgimento. Na segunda seção são apresentados os conceitos sobre as aplicações de MPSoCs, detalhando suas estruturas e funcionamento. Por fim, a última seção introduz os conceitos referentes às redes-em-chip, apresentando sua arquitetura e organização em um MPSoC e as diferenças entre os paradigmas convencional e SDNoC.
2.1 Sistemas em Chip Multiprocessados
Com o advento dos sistemas em chips muitas das aplicações computacionais começa-ram a demandar mais desempenho de execução. Uma solução dos designers de hardware foi de aumentar a taxa de operação (clock) dos sistemas. Contudo, com uma frequência de operação mais alta, o sistema tendia a aquecer mais, desperdiçando energia em forma de calor (JERRAYA; WOLF, 2005).
Com a miniaturização dos transistores e o processo VLSI (Very-large-scale Integration - Integração em escala muito grande) de fabricação de circuitos integrados, o aumento da taxa de operação foi substituído pela integração de múltiplos núcleos de processamento em um único chip, os MPSoCs. Nessa abordagem, a taxa de operação não precisa de incremento, pois as aplicações podem se beneficiar dos múltiplos núcleos dividindo-se em pequenas tarefas que são executadas por cada núcleo. Uma exploração de paralelismo conhecida como paralelismo no nível de tarefas, que provê uma execução mais rápida em comparação à uma execução sequencial.
Os MPSoCs podem variar em diversos aspectos: uniformidade dos núcleos; organização de memória; modelo de interconexão; modelo de programação paralela; entre outros. O
modelo de interconexão e o modelo de programação paralela são discutidos de forma mais detalhada nas seções seguintes. Por esse, motivo não serão abordados nesta seção.
Com relação à uniformidade dos núcleos, os MPSoCs se classificam em homogêneos e heterogêneos. MPSoCs com a mesma arquitetura em cada núcleo são denominados homogêneos. Enquanto que os que possuem arquiteturas distintas entre os núcleos são de-nominados MPSoCs heterogêneos (SAPONARA; FANUCCI, 2012), (JERRAYA; WOLF, 2005).
Um MPSoC heterogêneo pode possuir tipos distintos de núcleos de processamento para realizar tarefas distintas. A Figura 1 ilustra os dois tipos de MPSoCs interconectados por um barramento compartilhado de comunicação para troca de mensagens entre os núcleos. Nesse exemplo, o MPSoC homogêneo em (a), é composto por quatro núcleos iguais e o MPSoC heterogêneo em (b), é composto por duas CPUs (Central Processing Units -Unidades Centrais de Processamento), uma GPU (Graphics Processing Units - -Unidades de Processamento Gráfico) e um DSP (Digital Signal Processors - Processadores Digitais de Sinais).
Figura 1: MPSoCs homogêneos e heterogêneos
(a) Homogêneo (b) Heterogêneo
Fonte: autoria própria.
Uma vez que a aplicação está sendo executada num MPSoC por meio de tarefas, al-gumas dessas tarefas podem compartilhar variáveis nas unidades de memória. Com isso o sistema deve implementar algum modelo organizacional de memória, que pode ser com-partilhada e/ou distribuída. Em um modelo de memória comcom-partilhada, o barramento de comunicação também se conecta aos módulos de memória do MPSoC, permitindo o acesso de cada núcleo individualmente. Já em um modelo de memória distribuída, cada núcleo possui um módulo de memória exclusivo. Porém, também é possível que existam modelos híbridos, onde os núcleos podem possuir uma memória menor exclusiva, mas também ter acesso à uma memória maior que é compartilhada (SAPONARA; FANUCCI, 2012), (
JER-RAYA; WOLF, 2005). A Figura 2 exemplifica os três tipos de modelos de memória em um
MPSoC homogêneo, (a) distribuída, (b) distribuída e compartilhada, (c) compartilhada. Figura 2: Modelos de memória
(a) Distribuída (b) Híbrida
(c) Compartilhada
Fonte: autoria própria.
Além das questões arquiteturais e organizacionais de um MPSoC, existem outros desa-fios que afetam diretamente as métricas do sistema. Tais desadesa-fios envolvem a programação da aplicação e divisão em tarefas, mapeamento das mesmas nos núcleos de processamento adequados, escalonamento das tarefas, entre outros (NOVAES; MOREIRA; CHAU, 2019),
(AKTURK; OZTURK, 2019).
2.2 Aplicações para MPSoCs
Nesse contexto de sistemas multiprocessados, o desenvolvimento de aplicações para uso desses recursos torna-se um desafio. Uma aplicação computacional é composta por uma série de instruções em sequência a serem executadas por um processador. Entretanto, subconjuntos dessas instruções podem ser executadas de forma paralela. Dessa forma, a aplicação pode se beneficiar de um MPSoC, sendo dividida em tarefas que contém esses subconjuntos de instruções e atribuindo cada tarefa à um núcleo de processamento. Em
um MPSoC heterogêneo, trechos das aplicações podem se beneficiar mais ainda ao serem executados em núcleos de processamento dedicados (WOLF; JERRAYA; MARTIN, 2008).
Dessa forma a execução paralela da aplicação poderá ser feita em um tempo menor em comparação com uma execução sequencial.
Em alguns casos, as tarefas distribuídas entre os núcleos precisam trocar informa-ções entre si. Essa troca pode ser realizada através do compartilhamento de variáveis em um MPSoC com modelo de memória compartilhada, ou através de troca de mensagens (WILKINSON; ALLEN, 2004).
O compartilhamento de variáveis é feito quando as tarefas possuem variáveis em co-mum, e que são armazenadas em uma memória onde todos os núcleos têm acesso. Um sistema semelhante ao que é representado em (c) e (b) na Figura 2. Uma das formas de construir aplicações paralelas com uso de memória compartilhada é através de frameworks e APIs (Application Programming Interface - Interface de Programação de Aplicações) como o OpenMP (DAGUM; MENON, 1998). Já na troca de mensagens, cada núcleo possui
sua memória associada e, quando necessário, envia mensagens contendo dados de opera-ções para outros núcleos. Um cenário em que isso poderia ser utilizado é exemplificado em (a) e (b) na Figura 2, onde os modelos de memória utilizados possuem uma memória local para cada núcleo. Um exemplo de padrão que pode ser utilizado para troca de mensagens é o MPI (Message Passing Interface - Interface de Troca de Mensagens) (SNIR et al., 1998).
Em um MPSoC com modelo de memória distribuído e com comunicação em rede, torna-se mais viável o uso de troca de mensagens entre as tarefas. Nesse cenário, o modelo organizacional de uma NoC permite um acesso mais adaptativo ao dado, quando compa-rado com uma estrutura de comunicação com barramento e uma memória compartilhada. Um forma abstrata de representar as trocas de mensagens entre as tarefas é por meio de grafos dirigidos (DICK; RHODES; WOLF, 1998). Em um grafo de tarefas, cada nó
representa uma tarefa da aplicação e cada aresta dirigida representa a comunicação entre duas tarefas, onde a mensagem parte de um nó até outro. Em cada aresta de comunicação pode haver um “peso” representando a quantidade de informação a ser transmitida, a duração da comunicação, etc. Na Figura 3 é ilustrado um exemplo de um grafo de tarefas de uma aplicação. Neste exemplo, a aplicação foi segmentada em 9 tarefas, onde algumas tarefas enviam mensagens para outras. Cada comunicação possui um peso associado, informando quantia de bits por segundo (bps) a ser transmitidos. A tarefa 1, por exemplo, envia 20 megabits (27 bits) a cada segundo para a tarefa 2.
Figura 3: Exemplo de um grafo de tarefas
Fonte: autoria própria.
algoritmos de mapeamento e escalonamento de tarefas nos núcleos de processamento do MPSoC, de forma a melhorar o desempenho de comunicação. Esses algoritmos buscam mapear, de forma que fiquem próximas, as tarefas que mais trocam mensagens entre si. Contudo, dependendo da quantidade de tarefas da aplicação, alguns algoritmos podem tomar muito tempo para apresentar a melhor solução de mapeamento. Nesse contexto, são feitas heurísticas e algoritmos aproximativos, no intuito de apresentar uma solução que se aproxime da solução ótima em um menor intervalo tempo (ROCHA, 2017). Tal mapeamento também está associado com a organização das estruturas de comunicação dos MPSoCs.
2.3 Redes-em-Chip
Diferente dos modelos de comunicação baseados em barramentos, as redes-em-chip disponibilizam canais de comunicação alternativos entre os núcleos de processamento de um MPSoC. Em sua arquitetura de comunicação, as NoCs são compostas por um conjunto de roteadores e enlaces bidirecionais de comunicação que conectam esses roteadores entre si e com os núcleos de processamento, similar ao que é feito nas redes de computadores (ZEFERINO, 2003a), (JANTSCH; TENHUNEN et al., 2003).
Nesse modelo de comunicação há vantagem em utilizar troca de mensagens como comunicação entre as tarefas que estão sendo executadas no MPSoC. O formato da men-sagem também é semelhante ao formato dos pacotes transmitidos nas redes de
computa-dores. A mensagem enviada possui um cabeçalho contendo informações sobre o início da transmissão e destino, o próprio conteúdo da mensagem (também chamado de carga útil) e um terminador indicando o fim da mensagem.
Quanto a organização, uma rede-em-chip é caracterizada pela disposição de seus rote-adores, enlaces e núcleos de processamento no MPSoC. A forma com que esses elementos são organizados recebe o nome de topologia e podem ser agrupados em duas classes (ZEFERINO, 2003b):
• Redes diretas: onde cada roteador está associado à um núcleo de processamento e também conectado à outros roteadores. Idealmente, uma rede direta possuiria todos roteadores conectados entre si. Contudo, dependendo da dimensão da rede, seria inviável disponibilizar uma grande área do MPSoC apenas para conexões. Dessa forma, surgiram alternativas de organização topológica para as NoC, como as redes (a) mesh, (b) torus e (c) anel, representadas na Figura 4;
• Redes indiretas: onde os roteadores podem ou não possuir núcleos de processa-mento associados. Exemplos de redes indiretas são a (d) crossbar e (e) árvore gorda na Figura 4.
Figura 4: Exemplos de topologias de rede
(a) Mesh (b) Torus (c) Anel (d) Crossbar
(e) Árvore gorda
Fonte: autoria própria.
Para que as mensagens possam ser transmitidas entre cada par de núcleos de proces-samento, as mesmas precisam trafegar pelos enlaces conectados aos roteadores seguindo um percurso estabelecido. Os mecanismos necessários para estabelecer esse percurso estão
inseridos na arquitetura dos roteadores. Em uma arquitetura convencional de roteadores de uma NoC, estão presentes os seguintes módulos de controle:
• Controle de fluxo: responsável por gerenciar o tráfego na rede, armazenando tem-porariamente as mensagens até que possuam rotas disponíveis e estabelecendo as conexões para a transmissão das mensagens. Um exemplo de protocolo de controle de fluxo é o handshake (ZEFERINO; SUSIN, 2003), onde o controlador verifica se pode
transmitir uma mensagem para o próximo nó no percurso (podendo ser um roteador ou um núcleo de processamento), se for possível a mensagem é transmitida;
• Roteamento: define para qual caminho a mensagem deve seguir até atingir o seu destino. Nesse módulo podem ser utilizados algoritmos de roteamento determinísti-cos e adaptativos:
– Determinísticos: são algoritmos que definem um único caminho para cada comunicação. São vantajosos ao evitarem problemas de concorrência como dea-locks. Porém, a ausência de adaptabilidade pode ocasionar um atraso na entrega de outras mensagens, uma vez que mais de uma comunicação pode fazer uso de um mesmo trecho de rota e ter que esperar por sua disponibilidade. Exemplos de algoritmos são:
⇤ XY: utilizado em redes com topologia mesh, onde a rede é pode ser abs-traída como um plano cartesiano e a rota é definida percorrendo inicial-mente os roteadores no eixo X, para depois percorrer os roteadores no eixo Y e atingir o destino (ZEFERINO; SUSIN, 2003). Uma representação de rota desse algoritmo pode ser observada, destacada em vermelho, em (a) na Figura 5;
⇤ YX: similar ao XY, mas com uma abordagem oposta. A rota é definida percorrendo inicialmente os roteadores no eixo Y, para que em seguida possa percorrer os roteadores no eixo X (ROCHA, 2017).
– Adaptativos: diferentemente dos determinísticos, os algoritmos adaptativos buscam por rotas alternativas em caso de encontrarem algum canal indisponí-vel. Exemplos de algoritmos adaptativos são:
⇤ West-First: também utilizado em redes com topologias mesh, onde o ro-teamento é feito baseado em pontos cardeais da rede, buscando sempre rotas disponíveis no lado oeste da rede (esquerda), para em seguida buscar, nessa sequência, por rotas disponíveis ao sul (baixo), leste (direita) e norte
(cima). A adaptabilidade está em encontrar uma rota alternativa, seguindo a sequência, caso o enlace não esteja disponível no momento (GLASS; NI,
1992). Em (b) na Figura 5, é possível observar um caso de duas rotas, destacadas em vermelho e azul, determinadas pelo algoritmo West-First, no qual houve a necessidade de adaptação;
⇤ North-Last: é similar ao West-First. Porém, em sua sequência de buscas por rotas alternativas a direção norte deve ser sempre a última escolha (GLASS; NI, 1992).
• Árbitro: responsável por gerenciar quais mensagens podem ser transmitidas por um canal, em cenário que mais de uma necessita de um mesmo trecho de rota. A função do árbitro é evitar outros problemas de concorrência como starvation, onde a mensagem pode nunca ser transmitida pelo fato do canal estar sempre ocupado. O modelo de arbitragem pode ser distribuído entre cada canal de comunicação do roteador, ou centralizado, possuindo uma visão global da rede. A seguir são apre-sentados alguns critérios de prioridades para arbitragem que podem ser utilizados em ambos os modelos:
– Round-Robin: é um critério de prioridade rotativa, que pode ser implemen-tado com o uso de uma fila circular que armazena as mensagens. Dessa forma, um ponteiro percorre a fila buscando por mensagens que podem ser transmiti-das por um canal (CARARA, 2004);
– Oldest-First: é um critério de prioridade baseado na idade da mensagem, isto é, a ordem das mensagens em uma fila de requisições de rota é sua ordem de chegada, onde a mensagem com a requisição mais antiga, terá prioridade sobre as demais (CARARA, 2004), (DALLY, 1990).
• Chaveamento: é responsável por realizar as conexões entre os canais de entrada e saída de um roteador. Os mecanismos de chaveamento são um conjunto de multiple-xadores que selecionam quais canais de entrada formarão uma rota com o canal de saída associado ao roteador. Há duas técnicas de chaveamento de rotas (ZEFERINO,
2003b), são elas:
– Chaveamento por circuito: para cada rota definida é criado um circuito dedicado entre os dois núcleos da comunicação, passando pela sequência de roteadores do caminho. A vantagem nessa técnica é que a mensagem a ser transmitida por esse circuito não irá precisar aguardar por uma rota disponível.
Entretanto, outras comunicações podem ter que aguardar para obter uma rota disponível, ocasionando uma contenção de outras mensagens na rede;
– Chaveamento por pacote: as mensagens são divididas em pacotes, que por sua vez são divididos em unidades menores chamadas de Flits (Flow Control Units - Unidades de Controle de Fluxo). Um Flit também pode ser dividido em partes menores chamadas de Phits (Physical Units - Unidades Físicas), que geralmente possui o tamanho, em bits, da largura dos canais de comunicação. Com a mensagem dividida em partes menores, o roteador armazena essas partes e às transmitem pelos canais de saída. Essa técnica permite uma atendimento mais distribuído entre as requisições de rotas. Exemplos de chaveamento por pacotes:
⇤ Store-and-Forward: onde o roteador armazena todos os Flits de um pacote e os transmite pelo canal de saída quando houver disponibilidade; ⇤ Wormhole: busca diminuir o tamanho da memória temporária do
ro-teador, armazenando os Flits de um pacote ao longo dos roteadores do percurso, em caso de contenção. Por mais que essa técnica possa diminuir a área no roteador ocupada pela memória, a probabilidade de ocorrer pro-blemas de deadlock é maior. Contudo, isso pode ser contornado através de canais virtuais, onde um canal físico pode ser simulado como mais de um canal com coleções de filas de menor profundidade para comportar os Flits.
• Memória temporária: para armazenamento das mensagens antes das transmis-sões, os roteadores necessitam de uma memória interna, chamada de buffer, para armazenar os pacotes ou Flits de uma mensagem. Essa memória pode ser adicionada ao roteador de duas formas (ZEFERINO, 2003b):
– Distribuída: onde cada canal de entrada e/ou saída do roteador está associado à um buffer. Dessa forma, cada canal poderá ter um árbitro associado para realizar o controle de armazenamento e envio dos pacotes. A Figura 6 representa a arquitetura de um roteador com buffers distribuídos em cada canal de entrada e associado à um árbitro;
– Centralizada: o roteador possui uma única memória compartilhada por cada canal de comunicação. Essa memória deve possuir duas portas de acesso para cada canal bidirecional, de forma a permitir mais de um acesso ao mesmo tempo.
Figura 5: Exemplos de algoritmos de roteamento
(a) XY (b) West-First
Fonte: autoria própria.
Figura 6: Arquitetura de um roteador
Fonte: autoria própria.
Com o objetivo de minimizar a complexidade da arquitetura dos roteadores, disponibi-lizar rotas adaptativas sem deadlock e melhorar o controle de tráfego na rede, o paradigma de redes-em-chip definidas por software propõe a centralização das funções do roteador em um núcleo de processamento dedicado. Esse núcleo gerente possui uma visão global da rede, permitindo realizar um controle adaptativo do tráfego. Dessa forma, a arquite-tura dos roteadores pode ser reduzida à apenas um conjunto de multiplexadores e canais
de entrada/saída (BERESTIZSHEVSKY et al., 2017). Em alguns casos, os canais do
rotea-dor podem ou não possuir pequenos buffers apenas para reforçar o sinal da mensagem, evitando perda de informação.
Dedicar o controle da rede à um núcleo gerente permite a criação de circuitos virtuais dedicados para cada comunicação. Similar ao chaveamento por circuito, um circuito virtual define uma rota dedicada apenas à uma comunicação. Ao finalizar o envio das mensagens, a comunicação é encerrada e a rota torna a ser disponível novamente à outras comunicações. A requisição das rotas, nesse paradigma é feita por cada núcleo de processamento ao núcleo gerente, que por sua vez armazena as requisições em uma fila e, através de um mecanismo de arbitragem, verifica as requisições que podem ser atendidas para estabele-cer as rotas com um algoritmo de roteamento. Devido a visão global da rede por parte do núcleo gerente, o algoritmo de roteamento pode levar em consideração os circuitos virtuais já criados e buscar por rotas alternativas para a comunicação, distribuindo as comunicações ao longo da rede para tentar minimizar o atraso de entrega das mensagens. Em contrapartida, a criação dos circuitos virtuais pode causar um atraso no aten-dimento das requisições de comunicação. Em cenários onde não há rotas disponíveis, as requisições de comunicação terão que aguardar até que uma comunicação já estabelecida seja encerrada e o circuito virtual destruído. Dessa forma, ainda existe a possibilidade de ocorrer atraso na entrega das mensagens.
Embora o tamanho do roteador possa ser reduzido pela simplificação de sua arquite-tura, o núcleo gerente necessita de um canal de comunicação com cada núcleo e roteador da rede para receber as requisições de comunicação e ativar o circuito virtual, respecti-vamente. Logo, sua arquitetura pode compensar essa simplificação em relação à área do processador gerente. Dependendo da dimensão da rede, a quantidade de vias de comuni-cação com roteadores e núcleos aumenta proporcionalmente. Da mesma forma, o tamanho da memória que representa a fila de requisições também aumenta proporcionalmente. A Figura 7 representa um exemplo de SDNoC com topologia mesh e de dimensões 2x2. Nesse exemplo a quantidade de vias de requisição de rotas e vias de chaveamento de cir-cuitos virtuais é relativamente pequena, sendo 4 pares de vias. Entretanto, em uma mesma rede de dimensões 8x8, a quantidade de vias aumentaria para 64 pares, consequentemente aumentando a área do MPSoC.
Em relação à avaliação de desempenho de uma rede-em-chip, algumas métricas podem ser utilizadas para mensurar a eficiência da mesma em cenários de aplicações multicore com tráfego de mensagens. Segundo (ZEFERINO, 2003b), o desempenho de uma NoC pode
Figura 7: Exemplo de SDNoC
Fonte: autoria própria. ser avaliado por três métricas:
• Largura de banda: é capacidade máxima de informações que os canais de comu-nicação da rede podem transmitir a cada instante de tempo. Geralmente, a largura de banda é definida em bps (bits por segundo);
• Vazão: é a quantidade média da entrega de mensagens na rede. Diferente da largura de banda, a vazão mensura a quantidade de mensagens que foram recebidas pelos núcleos de destino durante todo o tempo de simulação;
• Latência: representa o tempo gasto para transmitir uma mensagem por um núcleo até que chegue ao destino. Nesse caso, a latência leva em consideração o atraso de roteamento da mensagem, atraso por contenção de pacote, tempo gasto pela distân-cia a percorrer e tempo de transferêndistân-cia entre os canais. Normalmente a avaliação de latência é exibida como uma média de todas as comunicações, podendo ser re-presentada em quantidades de ciclos de relógio (clocks) ou em unidades de tempo como nanosegundos ou microssegundos.
3
Trabalhos Relacionados
Este capítulo apresenta um conjunto dos trabalhos que estão relacionados ao tema da presente monografia. A revisão bibliográfica aqui presente está dividida em duas seções. Na primeira seção são apresentados trabalhos referentes aos MPSoCs com modelos de comunicação baseados em NoCs convencionais. Na segunda seção são apresentados os trabalhos que fazem uso do paradigma de SDNoCs como modelo de comunicação de MPSoC, com roteamento das mensagens definido em nível de software por um núcleo central.
3.1 Redes-em-Chip Convencionais
Na literatura, é possível encontrar um vasto estudo sobre redes-em-chip, que foi ini-ciado entre o final da década de 1990 e início da década de 2000 (HEMANI et al., 2000). Ao londo dos anos, surgiram vários projetos de redes-em-chip, levando em consideração diferentes aspectos, como desempenho, potência, área, segurança, tolerância a falhas, qua-lidade de serviço, entre outros (BJERREGAARD; MAHADEVAN, 2006), (AGARWAL; ISKAN-DER; SHANKAR, 2009), (OFORI-ATTAH; AGYEMAN, 2017), (ZEFERINO et al., 2002), (ABBAS et al., 2014). Dessa forma, com o objetivo de manter este capítulo dentro do contexto da
proposta, foram selecionados alguns trabalhos que abordam aspectos de desempenho de comunicação em NoCs, considerando cenários com diferentes topologias e modelagens abstratas dos sistemas.
Em (CZEKSTER et al., 2016), é proposto um modelo em alto nível de abstração
utili-zando redes de Petri coloridas temporizadas para uma análise mais acurada do desempe-nho do sistema. O principal objetivo é poder mensurar a latência média do roteamento dos pacotes em um tempo de validação de projeto mais curto e com resultados mais próximos de uma implementação em VHDL (VHSIC Hardware Description Language - Linguagem de Descrição de Hardware VHSIC). O modelo em uma rede de Petri consiste de um grafo formado por vértices e arestas dirigidas. Cada vértice representa um módulo do sistema,
podendo ser um processador, buffer ou árbitro. Esses módulos são interconectados pelas arestas dirigidas, que representam transações como inserir ou remover um flit de um buf-fer. Um exemplo, está ilustrado na Figura 8, retirada do trabalho de (CZEKSTER et al., 2016). Em sua abordagem, foi seguido o modelo de chaveamento por pacotes wormhole para estabelecer as comunicações entre as portas de entrada e saída de cada roteador. O algoritmo de roteamento utilizado foi o XY, aplicado à uma topologia mesh-2D. As ava-liações dos experimentos foram feitas em modelos com dimensões 4x4 e 5x5, executando aplicações multimídia e padrões de tráfego sintéticos hotspot (as mensagens são enviadas para um único nó) e aleatórios (as mensagens são enviadas para nós aleatórios). Nos re-sultados obtidos, a latência média de comunicação se aproximou bastante dos rere-sultados das simulações em VHDL, com uma variação de menos de 1%.
Figura 8: Modelagem de comunicação com árbitro usando redes de Petri coloridas
Fonte: (CZEKSTER et al., 2016).
O modelo proposto por (ZEFERINO; SUSIN, 2003) é de uma rede-em-chip com
topo-logia mesh-2D ou torus-2D chamada de SoCIN (SoC Interconnection Network - Rede de Interconexão de Sistemas em Chip). A SoCIN possui canais bidirecionais entre os rotea-dores e entre roteador e núcleo de processamento. Cada canal pode possuir uma largura de banda de 8, 16 ou 32 bits. Em sua abordagem foi utilizado o chaveamento por pacote Wormhole com o algoritmo de roteamento XY. Em cada canal de saída possui um árbi-tro round-robin que escolhe qual pacote será transmitido. Em seus resultados de síntese em uma FPGA (Field Programmable Gate Array - Matriz de Portas Programáveis em Campo) foi avaliada a quantidade de células lógicas utilizadas para construir duas NoCs 2D de ordem 2 com topologias mesh e torus, variando a largura de banda e o tamanho dos buffers de entrada. Os resultados obtidos apresentam um aumento de área proporcional ao buffer. Além disso, a síntese das duas topologias apresentaram uma economia de 45% de área na topologia mesh em relação à torus, demonstrando que a quantidade de enlaces na rede impacta diretamente na área do circuito.
Em (ADRIAHANTENAINA et al., 2003) é feita uma análise comparativa entre dois
mo-delos de comunicação de um MPSoC, sendo um o PI-Bus (SIEMENS; INITIATIVE et al.,
1994) com comunicação baseada em barramentos, e o outro modelo a rede-em-chip SPIN. A organização da rede SPIN segue a topologia de árvore gorda, onde os nós da árvore são roteadores e as folhas os núcleos de processamento. Os roteadores são organizados, de forma balanceada, em níveis da árvore, os enlaces são estabelecidos de um nível para o outro em crossbar. A SPIN utiliza chaveamento por pacote e possui um buffer para cada porta de entrada do roteador e dois buffers compartilhados, um para as saídas do nível superior e outro para as saídas do nível inferior. A rede faz uso de dos dois tipos de roteamento, o adaptativo é feito ao utilizar os enlaces superiores e o determinístico ao utilizar os enlaces inferiores. Durante os experimentos em modelos com 32 núcleos de processamento, a rede SPIN mostrou-se vantajosa em relação ao PI-Bus. Observando a latência média percebeu-se que o modelo PI-Bus satura com uma carga de 4% e a SPIN em 30%, sendo essa carga a representação percentual da taxa de requisição de pacotes pelos núcleos de origem.
3.2 Redes-em-Chip Definidas em Software
(BERESTIZSHEVSKY et al., 2017) propõe uma rede em chip com o paradigma de SDNoC
com o controle de roteamento feito em um núcleo de processamento. Nesse trabalho é feito um comparativo de desempenho entre a implementação de SDNoC e uma implementação de roteamento adaptativo centralizado proposto por (MANEVICH et al., 2011). Em algumas aplicações a SDNoC apresentou um desempenho inferior em cenários onde o tamanho da mensagem era curto e o tamanho dos phits se aproximava do tamanho da mensagem. Entretanto, a SDNoC apresentou resultados melhores quando as mensagens são mais longas, indicando um cenário de aplicações que podem se beneficiar dos circuitos virtuais. Em (RUARO et al., 2018), é proposta uma rede-em-chip que utiliza o paradigma de
SDNoC. Em sua abordagem a rede segue uma topologia mesh-2D, onde cada núcleo de processamento possui três roteadores associados, sendo dois roteadores configuráveis pelo núcleo gerente da rede e um roteador com chaveamento por pacote para requisitar os circuitos virtuais e envio de pacotes, em caso de indisponibilidade dos canais. A Figura 9 apresenta a integração (c) da NoC padrão em (a) com a SDNoC proposta em (b). Em cada roteador configurável há 4 buffers simples (1 por enlace), apenas para reforçar o sinal do clock ao longo do percurso. Os resultados comparam as latências de busca por rotas de duas implementações dos controles de gerência de rotas, onde a configuração dos
roteadores pode ser feita pelo núcleo gerente ou por um módulo local de sonda paralela, responsável por achar os caminhos disponíveis. O tamanho dos percursos encontrados nas duas abordagens foram bem próximos para os experimentos em redes de dimensões 6x6, 8x8, 12x12 e 16x16 divididas em clusters. Porém, a abordagem de configuração por um núcleo central tende a tomar mais tempo quanto para encontrar uma rota disponível em comparação com a abordagem de sondagem, onde maior média de atraso foi de 5.453 ciclos de clock do núcleo central contra 501 ciclos de clock das sondas.
Figura 9: Integração de uma NoC com uma arquitetura baseada em SDNoC
Fonte: (RUARO et al., 2018).
A proposta apresentada em (CONG; WEN; ZHIYING, 2014) é de uma SDNoC com o
controle de configuração da rede distribuído nos roteadores ao invés de estar centrali-zado em um núcleo dedicado. Porém cada plano de controle de cada roteador se comunica diretamente com o plano de controle dos roteadores vizinhos, ainda permitindo um conhe-cimento geral da rede, como pode ser observado na Figura 10. O cálculo de rotas feito em software utiliza o protocolo OpenFlow (MCKEOWN et al., 2008) para manter uma tabela de roteamento que indica o caminho pelo qual a mensagem deve seguir. A configuração das rotas feitas pelo plano de controle pode se adaptar às características da mensagem, dedicando todo o canal através dos circuitos virtuais ou reservando uma largura de banda para a transmissão e liberando após o fim da transmissão. Em seus experimentos, foi feita uma comparação de latência média, em uma rede com dimensões 16x16, aumentando a taxa de injeção de pacotes, entre a SDNoC e o modelo de rede-em-chip da Noxim ( CA-TANIA et al., 2015) com roteamentos XY e DyAD (HU; MARCULESCU, 2004) (adaptativo
e determinístico). Os resultados apresentados apontam latências iguais em taxas de inje-ção de pacotes menores, mas um ganho de desempenho da SDNoC conforme essa taxa aumenta.
Em (SANDOVAL-ARECHIGA et al., 2016) foram feitas simulações em uma
Figura 10: Arquitetura do roteador com controle de configuração
Fonte: (CONG; WEN; ZHIYING, 2014).
et al., 2015), avaliando o comportamento da rede com o uso de algoritmos adaptativos e
de-terminísticos em um sistema homogêneo. Em seus resultados, foram observadas métricas de desempenho como latência, vazão e tempo de configuração de rotas. Nas três métricas foi possível observar que os algoritmos se comportam de forma semelhante em taxas de injeção de pacotes menores. Porém, os algoritmos determinísticos, como o XY, apresen-tam um atraso menor quando comparados com algoritmos adaptativos ou parcialmente adaptativos, como o north-last.
Os trabalhos aqui descritos apresentam exemplos de abordagens utilizadas para mode-lagem de sistemas computacionais multicore, buscando avaliar o desempenho de execução de aplicações computacionais, economia de área e propondo técnicas para aumentar esse desempenho. Em relação ao presente trabalho, as referências aqui citadas servem como inspiração para a modelagem de uma SDNoC mesh-2D, em SystemC (ACCELLERA, 2018),
com o objetivo de avaliar o comportamento da rede ao aumentar o tráfego, além de uma comparação com modelos de NoCs convencionais.
A SDNoC proposta nesse trabalho se diferencia das que foram aqui apresentadas em relação centralização do gerenciamento da rede, os algoritmos de roteamento, arquitetura dos roteadores e aplicação em MPSoCs heterogêneos, onde o tráfego na rede pode se tornar mais intenso, a depender do tempo de execução das tarefas em cada núcleo de pro-cessamento. No próximo capítulo são apresentados os detalhes sobre a SDNoC proposta.
4
SONNE - Arquitetura e
Organização da SDNoC
Diante do contexto de redes-em-chip como modelos de comunicação para MPSoCs e após apresentados os benefícios do paradigma de SDNoCs, foi proposta uma rede-em-chip definida por software. É importante destacar que a Software-Defined NoC foi escolhida neste trabalho pelo seu potencial de reduzir tempo de comunicação, quando comparada a uma NoC convencional. Este potencial pode ser explorado por MPSoCs com núcleos de alto desempenho, através da adoção de núcleos como GPUs ou pelo uso de acelera-dores acoplados aos núcleos. A escolha do paradigma de SDNoC para a avaliação está relacionada com a abstração do roteamento feito em software por um núcleo dedicado e a adaptabilidade na criação de rotas, uma vez que o roteamento feito baseia-se na atual configuração da rede.
A rede SONNE (em alemão, Sol), um acrônimo para Software on Network-on-Chip, foi implementada em C++ utilizando a biblioteca SystemC (ACCELLERA, 2018) para
descrição dos módulos de hardware e simulação com contagem de ciclos. Sua estrutura segue uma topologia mesh-2D, composta por roteadores simplificados, núcleos de proces-samento e um núcleo gerente, externo à mesh, dedicado à criação de circuitos virtuais para comunicação entre os núcleos de processamento.
De forma alternativa às SDNoCs apresentadas no Capítulo 3, a SONNE possui um roteamento adaptativo com o algoritmo Dijkstra, que usa teoria de grafos para encontrar o menor caminho, sendo uma alternativa aos algoritmos adaptativos de NoCs. Além disso, o método de arbitragem é um híbrido de duas abordagens existentes, sendo elas o Round-Robin e o Oldest-First, onde as requisições de rota são armazenadas em uma fila circular e atendidas conforme a ordem de chegada. Por fim, a arquitetura dos roteadores são um conjunto de multiplexadores em crossbar com buffers de uma posição em cada porta de entrada.
da rede, o modelo de organização e interconexão dos componentes, os algoritmos de rote-amento disponíveis e como são feitas as simulações e coleta de resultados.
4.1 Arquitetura e Funcionamento
A rede SONNE é uma proposta de modelo de comunicação para MPSoCs, onde os núcleos do sistema, que executam as tarefas das aplicações computacionais, fazem uso da SDNoC para troca de mensagens entre si. Para que isso possa acontecer, o núcleo origem que deseja transmitir a mensagem requisita um caminho ao núcleo de gerenciamento da rede. Por sua vez, o núcleo gerente armazena essa requisição em uma fila de requisições para que em seguida possa criar um circuito virtual entre os roteadores, definindo um caminho para a comunicação entre o núcleo de origem e o de destino. A Figura 11 repre-senta o processo de requisição de rota, feito por um núcleo de processamento ao núcleo gerente, para que a tarefa em execução possa enviar mensagens a uma outra tarefa em um outro núcleo de processamento.
Figura 11: Processo de requisição de rota para troca de mensagens
Fonte: autoria própria.
Cada núcleo de processamento possui quatro vias de comunicação conectadas ao núcleo gerente, sendo duas vias para informar o núcleo de destino da mensagem (coordena-das X e Y na rede) a ser enviada, uma via para receber a confirmação de rota estabelecida e uma via para informar a chegada do último pacote. Além disso, cada núcleo possui duas vias de comunicação com o roteador associado, sendo uma via para envio das mensagens e outra pra recepção, formando um enlace bidirecional com o roteador. A Figura 12 apre-senta esse esquema de interconexão do núcleo de processamento com o núcleo gerente e o roteador.
Após enviar as coordenadas do núcleo de destino, o núcleo de origem recebe a confir-mação de circuito virtual estabelecido entre os roteadores que compõem a rota e, através
Figura 12: Comunicação do núcleo de processamento com gerente e roteador
Fonte: autoria própria.
da porta de saída no enlace com o roteador, inicia a transmissão dos pacotes que compõem a mensagem de forma serializada. Cada pacote possui um identificador que são ordenados de forma decrescente, sendo o último pacote com identificador 0. Ao receber o último pacote, o núcleo de destino notifica o núcleo gerente que a mensagem foi transmitida, permitindo que o circuito possa ser desativado.
No núcleo gerente os módulos existentes são todos abstrações em nível de software, onde a arquitetura de hardware é a mesma dos outros núcleos dispostos no MPSoC. Dentre esses módulos abstratos, existe um buffer, em formato de fila circular, dedicado a armazenar as requisições de rotas feitas por cada núcleo de processamento. Sempre que é feita uma solicitação, a mesma é inserida no final da fila e o atendimento à elas é feito através de um árbitro. O critério de prioridades do árbitro baseia-se nos critérios do Round-Robin e do Oldest-First, onde a requisição mais antiga, isto é, a que se encontra na cabeça da fila, possui maior prioridade sobre as demais. Consequentemente, a segunda requisição possui a segunda maior prioridade e assim por diante. Se a requisição de maior prioridade não tiver disponibilidade de rota, devido a ausência de caminhos alternativos disponíveis, o árbitro fará uma busca pelas requisições com prioridades subsequentes até encontrar uma que possua uma rota disponível. Após atender a requisição, o árbitro repete o processo desde o início da fila, mantendo a prioridade.
A verificação de disponibilidade de rota pelo núcleo gerente é feita através de uma representação em grafo do atual cenário de configurações dos roteadores presentes na rede. Cada roteador é representado por um nó e os enlaces por duas arestas dirigidas e opostas que conectam os roteadores em pares. Quando uma rota é definida, a mesma é armazenada
em um buffer de rotas. Em seguida, o circuito virtual é estabelecido, com base nessa rota criada, e as arestas da rota são removidas do grafo, impossibilitando que possam ser utilizadas por outras comunicações enquanto o circuito virtual ainda está ativo. Após o encerramento da comunicação e o circuito virtual desfeito, as arestas são recolocadas no grafo com base na rota guardada na memória. A Figura 13 representa dois cenários de rotas disponíveis na rede, onde em (a) todas as rotas estão disponíveis e nenhum circuito virtual foi estabelecido e em (b) onde há o circuito virtual R6 ! R7 ! R8 ! R5 ! R2.
Figura 13: Grafo de rotas disponíveis
(a) Sem circuitos virtuais (b) Um circuito virtual
Fonte: autoria própria.
O cálculo para criar uma rota é feito utilizando um algoritmo de roteamento imple-mentado em software. Os algoritmos disponíveis nessa versão da SONNE serão discutidos na seção 4.4. Após definida a rota e removidas as arestas do grafo, o núcleo gerente con-figura cada roteador do percurso através de duas vias de comunicação. Uma via para os seletores dos multiplexadores e outra via para habilitar a transmissão pelas portas de saída. A Figura 14 representa o funcionamento interno do núcleo gerente e a Figura 15 as vias de comunicação com os roteadores.
A arquitetura de cada roteador é menos complexa em relação à arquitetura de um roteador de rede-em-chip convencional. Sua composição é feita por cinco multiplexadores, um para cada porta de saída, com seleção para quatro entradas conectadas em crossbar com buffers de uma posição. Cada buffer está associado à uma das cinco porta de entrada e possuem espaço para armazenar um pacote de 32 bits. O uso de buffers serve apenas para reforçar o sinal da mensagem e evitar problemas de sincronia de clock em rotas mais longas. Em cada roteador pode haver até cinco enlaces bidirecionais, sendo um dedicado a comunicação com o núcleo de processamento, e quatro para comunicações
Figura 14: Arquitetura do núcleo gerente
Fonte: autoria própria.
Figura 15: Comunicação do núcleo gerente com roteador
Fonte: autoria própria.
com os roteadores vizinhos norte, sul, leste e oeste. A Figura 16 ilustra a arquitetura simplificada do roteador utilizado na SDNoC.
4.2 Organização da Rede
A estrutura organizacional da rede SONNE segue uma topologia de redes mesh-2D, onde cada roteador possui um núcleo de processamento conectado através do enlace local. As conexões entre roteadores são feitas através dos enlaces que formam a estrutura mesh. Cada roteador e núcleo de processamento possui um identificador em coordenadas representado pela tupla (X, Y ), onde X representa sua posição no eixo horizontal da rede e Y no eixo vertical. Cada núcleo de processamento e roteador possui uma conexão direta com o núcleo gerente através das vias de comunicação descritas na seção 4.1.
Figura 16: Arquitetura do roteador SONNE
Fonte: autoria própria.
O núcleo gerente fica separado da estrutura em mesh da rede, de forma que em uma rede de dimensões 3x3 há 9 núcleos de processamento mais um núcleo gerente, totalizando 10 núcleos. A organização da rede SONNE é similar à que está representada na Figura 7 da seção 2.3.
4.3 Algoritmos de Roteamento
De forma a apresentar as vantagens de uma SDNoC, foram implementados dois algo-ritmos de roteamento para comparação entre resultados de desempenho de comunicação, sendo um determinístico e outro adaptativo. O algoritmo determinístico foi o XY, devido ser bastante comum entre as NoCs convencionais. Já o algoritmo adaptativo escolhido foi o algoritmo de Dijkstra (GOLDBARG; GOLDBARG, 2012), pela função de identificar o caminho mais curto entre os vértices de um grafo e pela sua facilidade de implementação e execução em nível de software.
No Algoritmo 1 está a representação do pseudocódigo do roteamento XY. O rotea-mento consiste em criar uma rota buscando no grafo de rotas disponíveis por enlaces que possam ser utilizados para formar um circuito virtual. Como explicado na seção 2.3, a busca ocorre inicialmente pelos enlaces no eixo X e em seguida no eixo Y. Caso algum enlace nesse caminho esteja indisponível, o algoritmo retorna ao árbitro a informação de
que a rota não pode ser estabelecida no momento. Em caso de sucesso, os enlaces que compõem a rota são removidos no grafo e o percurso é adicionado na memória de rotas para a criação dos circuitos virtuais.
O Algoritmo 2 é representação do pseudocódigo do roteamento Dijkstra de caminho mais curto. A busca é feita utilizando o grafo de rotas disponíveis, contabilizando apenas os enlaces que podem ser utilizados. Com isso, o algoritmo busca pelo caminho mais curto entre o roteador de origem e o de destino, estabelecendo a rota somente se o roteador com o núcleo de destino foi atingido. Caso contrário, o algoritmo retorna ao árbitro a informação de que a rota não pode ser estabelecida no momento. Assim como no XY, se houver sucesso, o caminho é adicionado à memória de rotas e os enlaces que o compõem são removidos do grafo de rotas disponíveis.
4.4 Simulações e Coleta de Resultados
A rede SONNE permite realizar simulações em topologias mesh-2D, definindo as di-mensões da rede e a largura dos enlaces em bits antes da compilação. Ao iniciar uma simu-lação, o arquivo executável da rede necessita de dois argumentos de entrada. O primeiro argumento refere-se ao algoritmo de roteamento que se deseja utilizar. Na versão atual da SONNE, estão disponíveis os dois algoritmos apresentados na seção 4.3. O segundo argumento é o arquivo de entrada que contém o tráfego das mensagens. Nesse arquivo são descritas as informações sobre o envio de mensagens dos núcleos de processamento.
A Figura 17 é um exemplo de arquivo de tráfego de uma rede 8x8. Em um arquivo de tráfego são necessárias duas informações, a dimensão da rede utilizada e informações sobre as mensagens a serem enviadas. As dimensões da rede servem apenas para confirmar que a quantidade de núcleos descritos no arquivo respeitam as dimensões da rede que foi compilada. Essa informação é descrita pela tag ND: (Network Dimensions - Dimensões da Rede) com os valores das dimensões em largura e altura, respectivamente. Já as in-formações sobre as mensagens descrevem a origem, destino, quantidade de pacotes que compõem a mensagem e tempo de espera (em ciclos de clock) antes do envio de cada uma. Esse tempo de espera é uma abstração para o tempo que a tarefa leva de processamento antes de iniciar uma troca de mensagens.
As informações sobre as mensagens dos núcleos são seguidas pela tag CR: (Core -Núcleo), onde a ordem dos dados são as posições, em coordenadas, dos núcleos de origem e destino da mensagem, seguidos pelo tamanho da mensagem, descrito em número de
Algoritmo 1 XY
Entrada: origem(X, Y ) e destino(X, Y )
Saída: Lista encadeada P de roteadores com a rota ou rota indisponível
1: adiciona origem(X, Y ) à lista P 2: Xatual := origem(X)
3: Yatual := origem(Y )
4: enquanto Xatual < destino(X)faça
5: se existe rota entre (Xatual, Y ) e (Xatual+ 1, Y ) então
6: Xatual := Xatual+ 1
7: adiciona (Xatual, Y ) à lista P
8: senão
9: return rota indisponível 10: fim se
11: fim enquanto
12: enquanto Xatual > destino(X)faça
13: se existe rota entre (Xatual, Y ) e (Xatual 1, Y )então
14: Xatual := Xatual 1
15: adiciona (Xatual, Y ) à lista P
16: senão
17: return rota indisponível 18: fim se
19: fim enquanto
20: enquanto Yatual < destino(Y ) faça
21: se existe rota entre (X, Yatual)e (X, Yatual+ 1) então
22: Yatual := Yatual+ 1
23: adiciona (X, Yatual)à lista P
24: senão
25: return rota indisponível
26: fim se 27: fim enquanto
28: enquanto Yatual > destino(Y ) faça
29: se existe rota entre (X, Yatual)e (X, Yatual 1)então
30: Yatual := Yatual 1
31: adiciona (X, Yatual)à lista P
32: senão
33: return rota indisponível 34: fim se
35: fim enquanto
36: adiciona destino(X, Y ) à lista P
37: remove do grafo de rotas disponíveis as aresta que formam a rota P 38: adiciona a lista P na memória de rotas
Algoritmo 2 Dijkstra
Entrada: origem(X, Y ) e destino(X, Y )
Saída: Lista encadeada P de roteadores com a rota ou rota indisponível
1: seja d[(X, Y )] um vetor que guarda a distância entre origem(X, Y ) e o roteador (X, Y ) 2: seja ⇡(X, Y ) um vetor com o roteador vizinho necessário para atingir o roteador (X, Y ) 3: para todo roteador r(X, Y ) presente na rede faça
4: d[r(X, Y )] :=1
5: ⇡[r(X, Y )] := ( 1, 1)
6: fim para
7: d[origem(X, Y )] := 0
8: para todo roteador r(X, Y ) vizinho de origem(X, Y ) faça 9: d[r(X, Y )] := 1
10: ⇡[r(X, Y )] := origem(X, Y )
11: fim para
12: seja Q o conjunto de roteadores diferentes de origem(X, Y ) 13: enquanto Q 6= ; faça
14: seja r(X, Y ) 2 Q, tal que mind[r(X, Y )]
15: remove r(X, Y ) de Q
16: para todoroteador r0(X, Y ) vizinho de r(X, Y ) faça
17: se d[r0(X, Y )] > d[r(X, Y )] + 1 então 18: d[r0(X, Y )] := d[r(X, Y )] + 1 19: ⇡[r0(X, Y )] := r(X, Y ) 20: fim se 21: fim para 22: fim enquanto 23: se ⇡[destino(X, Y )] 6= ( 1, 1) então
24: P := subconjunto de roteadores que formam a rota entre origem(X, Y ) e destino(X, Y )
25: remove do grafo de rotas disponíveis as aresta que formam a rota P 26: adiciona a lista P na memória de rotas
27: senão
28: return rota indisponível 29: fim se
Figura 17: Conteúdo de um arquivo de tráfego SONNE
Fonte: autoria própria.
pacotes, e o tempo de espera da tarefa antes da requisição de rota ao núcleo gerente, expresso em número de ciclos. No exemplo da Figura 17, existem 7 mensagens a serem transmitidas por 7 núcleos de origem para 7 núcleos de destino. Na primeira mensagem por exemplo, o núcleo representado pelas coordenadas (0, 0) aguarda durante um ciclo de clock antes de requisitar uma rota ao núcleo gerente, de forma a enviar uma mensagem contendo 50 pacotes, direcionada ao núcleo representado pelas coordenadas (7, 7).
Ao final da simulação, a rede SONNE exibe um conjunto de estatísticas contendo informações sobre o atraso médio das solicitações de rota, o tempo de maior atraso para uma solicitação ser atendida e o tempo total de simulação, todos os valores expressos em ciclos de clock.
5
Resultados Experimentais
Neste capítulo são apresentadas as modelagens dos grupos de grafos de tarefas uti-lizados nos experimentos e os resultados das simulações com os dois algoritmos de ro-teamento em quatro cenários de redes-em-chip, com dimensões 4x4; 5x5; 8x8; e 10x10. Nas simulações realizadas foram observados os comportamentos da SDNoC SONNE, com os dois algoritmos de roteamento, à medida que diminui o tempo de espera das tarefas ao iniciarem uma troca de mensagens. Além disso, foram realizadas comparações com o comportamento de um mesmo padrão de tráfego em uma rede convencional configurada no simulador Noxim (CATANIA et al., 2015).
Para mensurar o comportamento das redes-em-chip foram avaliados, apenas para a SDNoC SONNE, o tempo de atraso médio e máximo das requisições de rota de cada tarefa ao núcleo gerente. Além disso, em ambas as redes, foi avaliado o tempo total de simulação do tráfego, de forma a identificar em qual abordagem houve uma comunicação mais rápida entre as tarefas.
A modelagem e categorização dos grafos de tarefas são descritas na seção 5.1. Já os resultados e discussões das simulações, são realizados nas seções em seguida.
5.1 Modelagem das Aplicações
Devido a dificuldade em encontrar ferramentas para extração automática de grafos de tarefas de aplicações multicore, que fossem fáceis de utilizar e que os grafos refletissem os cenários necessários para a avaliação neste trabalho, optou-se pela geração de grafos alea-tórios a partir da ferramenta TGFF (Task Graphs for Free - Grafos de Tarefas Gratuitos) (DICK; RHODES; WOLF, 1998).
A ferramenta baseia-se em uma série de parâmetros de configuração para gerar grafos de tarefas aleatórios. Dentre eles, destacam-se os principais:
