Arquitetura de NoC tolerante a falhas com compartilhamento de roteadores

UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE CENTRO DE CIÊNCIAS EXATAS E DA TERRA

DEPARTAMENTO DE INFORMÁTICA E MATEMÁTICA APLICADA BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO

Arquitetura de NoC Tolerante a Falhas com

Compartilhamento de Roteadores

Dogival Ferreira da Silva Junior

Natal-RN Novembro 2018

ii

Dogival Ferreira da Silva Junior

Arquitetura de NoC Tolerante a Falhas com

Compartilhamento de Roteadores

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 obtenção do grau de bacharel em Ciência da Computação.

Orientadora

Dra. Monica Magalhães Pereira

Universidade Federal do Rio Grande do Norte – UFRN Departamento de Informática e Matemática Aplicada – DIMAp

Natal-RN Novembro 2018

Silva Junior, Dogival Ferreira da.

Arquitetura de NoC tolerante a falhas com compartilhamento de roteadores / Dogival Ferreira da Silva Junior. - 2018.

43f.: 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, Curso de Ciência da Computação. Natal, 2018. Orientadora: Monica Magalhães Pereira.

1. Computação - Monografia. 2. Rede-em-chip - Monografia. 3. Tolerância a falhas - Monografia. 4. Latência - Monografia. 5. SystemC - Monografia. 6. TLM - Monografia. I. Pereira, Monica Magalhães. II. Título.

RN/UF/CCET CDU 004

iii

Monografia de Graduação sob o título Arquitetura de NoC tolerante a Falhas

com Compartilhamento de Roteadores apresentada por Dogival Ferreira da

Silva Junior 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:

__________________________________________ Dra. Monica Magalhães Pereira

Orientadora

DIMAp UFRN

__________________________________________ Dr. Márcio Eduardo Kreutz

DIMAp UFRN

__________________________________________ Ma. Alba Sandyra Bezerra Lopes

IFRN

iv

Aos maiores responsáveis por esta conquista. Especialmente minha mãe, Dalvina, meu pai Dogival, e minha esposa Fernanda, por toda dedicação, confiança e paciência.

v

Agradecimentos

Primeiramente a Deus por me conceder determinação, saúde e sabedoria para concluir com sucesso esta jornada.

Aos meus pais Dogival Ferreira e Dalvina Francisca, por todo amor, companheirismo, apoio e dedicação. Essa graduação eu devo e ofereço a vocês. Essa não é a minha, mas sim a nossa vitória.

A minha avó Luzia, às minhas tias, tios, primos e primas. A todos os outros familiares que me encorajaram e incentivaram a seguir em frente.

A minha orientadora Prof. Dra. Monica Magalhães Pereira, por toda a sua constante atenção, apoio, cobrança, conhecimento e, antes de tudo, pela confiança que me foi depositada.

Aos meus colegas do laboratório LASIC. Além de companheiros de trabalho, vocês tornaram-se muito bons amigos.

Aos meus amigos que, direta ou indiretamente, contribuíram com a concretização deste sonho, em especial a Marcos Oliveira e Gabriel Sebastian.

A minha esposa Fernanda Saadna, por ter vivido comigo nos últimos anos, os melhores momentos da minha vida. Por sempre estar ao meu lado, me apoiar e acreditar na minha capacidade.

vi

Os conformistas transformam fracassos em

medo; os determinados transformam

derrotas em garra.

vii

Arquitetura de NoC Tolerante a Falhas com

Compartilhamento de Roteadores

Autor: Dogival Ferreira da Silva Junior Orientador(a): Dra. Monica Magalhães Pereira

R

ESUMO

Com a evolução da tecnologia CMOS e o aumento na densidade dos circuitos integrados, a probabilidade de falhas e defeitos aumentou de maneira considerável. Por esse motivo, tornou-se necessário incorporar tolerância a falhas em tempo de design nos projetos de circuitos, principalmente, em projetos complexos como os de rede em chip (NoCs). Neste trabalho, apresentamos uma NoC com uma solução de tolerância a falhas permanente e de baixo impacto, em que roteadores com falha se tornam switches, ao passo que o processador local se liga a um dos roteadores vizinhos para que a rede se mantenha funcional mesmo sob falhas. Para isso, foi modelada uma NoC em nível TLM (Transaction-level Modeling), utilizando a biblioteca SystemC, e foram feitos testes de latência em diferentes níveis de falha da rede, identificando os pontos chave desta solução de tolerância a falhas.

Palavras-chave: rede-em-chip, tolerância a falhas, latência, SystemC, SoCIN,

8

Fault Tolerant NoC Architecture With Router

Sharing

Author: Dogival Ferreira da Silva Junior Advisor: Dr. Monica Magalhães Pereira

A

BSTRACT

With the evolution of the CMOS technology and the increase of integrated circuits density, the failure probability and faulty rate has increased in a sizeable manner. For this reason, it became necessary to incorporate fault tolerance at the design time in integrated circuits project, especially in complex projects like Network-on-chip ones. In this work, we present a NoC design, with a low impact solution for permanent fault tolerance, where faulty routers become a switch, while the local processor connects to the neighbor routers, so the network can keep working even under faults. To this, we modeled a NoC at the TLM (Transaction-level Modeling) level, using SystemC library, and run some network latency tests at different faulty scenarios, identifying key points for our solution on the tolerating faults.

9

Lista de figuras

Figura 1. MPSoC heterogêneo interligado por uma NoC... 15

Figura 2. NoC na topologia grelha 2d... 16

Figura 3. Diagrama de casos de uso, estilos e mecanismos do SystemC TLM 2.0... 19

Figura 4. Visão geral dos roteadores da NoC proposta... 26

Figura 5. Disposição dos elementos adjacentes de um roteador no núcleo da NoC... 27 Figura 6. Visão objetiva dos componentes da NoC... 27

Figura 7. Componentes da porta do roteador... 28

Figura 8. Disposição dos componentes do roteador... 29

Figura 9. Rotina de recuperação de falhas passo I... 30

Figura 10. Rotina de recuperação de falhas passo II... 31

Figura 11. Rotina de recuperação de falhas passo III... 32

Figura 12. Conexões adicionais para um roteador. 33 Figura 13. Diagrama de blocos de todos os módulos do simulador... 34

Figura 14. Formato do endereço dos pacotes... 35 Figura 15. Latência média para 100 pacotes gerados em

diferentes

configurações...

10

Figura 16. Latência média para 1.000 pacotes gerados em

diferentes configurações... 37 Figura 17. Latência média para 10.000 pacotes gerados em

11

Lista de abreviaturas e siglas

AT - Approximately Timed BIST - Buit-in-Self-Test

CMOS - Complementary Metal Oxide Semiconductor CRC - Cyclic Redundancy Check

ECC - Error Correction Code EP – Elemento de Processamento

DIMAp – Departamento de Informática e Matemática Aplicada IP - Intellectual Property

LT - Loosely Timed

MPSoC - MultiProcessor System-on-Chip NI – Network Interface

NoC - Network-On-Chip PEs – Processing Element SAF - Store-and-forward

TBBD - Time Dependent Dielectric Breakdown TLM - Transaction-Level Modeling

12

Sumário

4.1 Arquitetura da Rede em Chip 25 4.2 Mecanismo de Tolerância a Falhas Proposto 29

5 Resultados 34

5.1 Implementação da Simulação 34

5.2 Resultados obtidos 36

6 Considerações finais 39

13

1 Introdução

Com a evolução da tecnologia do CMOS (Complementary Metal Oxide

Semiconductor) houve um aumento na densidade dos circuitos integrados

permitindo assim a criação de sistemas com vários processadores em um único chip, chamados MPSoCs (MultiProcessor System-on-Chip). O MPSoC contém múltiplos elementos de processamento, que podem ter diferentes funcionalidades de acordo com a aplicação, classificados como heterogêneos, ou ser todos do mesmo tipo, classificados como homogêneos.

Todos esses componentes do MPSoC são tradicionalmente interligados por meio de barramentos, porém essa solução se mostra pouca escalável à medida que aumentamos o número de elementos conectados. Com isso foi introduzido um novo meio de comunicação, as NoCs (Network-On-Chip) ou em português, redes em chip. O desenvolvimento das redes em chip vem atrelado a necessidade dos MPSoCs de um novo tipo de comunicação no chip que seja escalável e que permita um melhor gerenciamento das características principais como desempenho, energia e tolerância a falhas (KIM et al., 2006).

Além de toda evolução que a diminuição do tamanho do transistor trouxe, como um menor consumo de área e potência, a diminuição do tamanho dos fios representa uma maior chance de quebra e distúrbios nos sinais, em conjunto com outros problemas físicos, como o TBBD (Time

Dependent Dielectric Breakdown), eletromigração, entre outros. Esses

problemas impactam diretamente na confiabilidade desses sistemas, segundo BORKAR et al. (2004), 20% das taxas de falhas estão na fabricação e 10% atreladas ao uso do dispositivo, para dispositivos com mais de 100 bilhões de transistores.

Por esse motivo, um projeto de MPSoC atual deve ser pensado desde sua concepção para que contenha mecanismos de detecção e prevenção de falhas, aliado a um projeto visando balancear desempenho, consumo de energia e custo. Tais aspectos devem ser considerados principalmente

14

quando falamos de sistemas embarcados, onde há muitas restrições quanto ao consumo de energia, custo, área, eficiência, dentre outros (VAHID e GIVARGIS 2002).

Este trabalho tem como objetivo principal propor e implementar um modelo de uma rede em chip com tolerância a falhas permanentes em roteadores. A solução de tolerância a falhas permitirá aumentar a confiabilidade da rede em chip (NoC), com atenção quanto o aumento da área ocupada no chip e a dissipação de energia. Para validar a solução propostam foi construído um modelo arquitetural conceitual de alto nível de abstração utilizando a biblioteca SystemC TLM (INITIATIVE, 2011). Esse modelo servirá para exploração de projeto usando diversas métricas aplicáveis, como latência de pacotes, taxa de ocupação, entre outras.

O modelo arquitetural da NoC foi baseado na SoCIN (ZEFERINO e SUSIN, 2003), com a adição do mecanismo de tolerância de falhas proposto neste trabalho e, com os devidos ajustes. O modelo foi implementado em SystemC TLM para manter o foco nas transações da rede, sendo esse o nosso objeto para testes do projeto.

1.1 Motivação

Um dos importantes aspectos quando falamos de muitos componentes integrados é a confiabilidade desse sistema. Quando temos um projeto que envolve muitos componentes, a confiabilidade deve fazer parte do design, pensado desde o início do projeto. Sistemas de missão-crítica, por exemplo, precisam de uma garantia de que esses componentes vão funcionar por muitos anos sem falhas, mantendo sua funcionalidade e desempenho original durante o tempo de vida.

O aumento na taxa de falhas dos circuitos integrados causado pelo aumento da densidade dos transistores e a importância dos métodos de interconexão intra-chip em sistemas com múltiplos elementos, são razões pelas quais NoCs devem ser robustas para enfrentar problemas com componentes defeituosos (DUMITRAS, KERNER, e MARCULESCU, 2003). Uma NoC tolerante a falhas contém mecanismos que mantêm a operação

15

correta do sistema na presença de falhas permanentes.

A aplicação disso no mundo real é muito ampla, já que muitos produtos usam sistemas embarcados de alguma forma. Um exemplo disso são os sistemas auxiliares de carros ou, num futuro próximo, os sistemas de visão computacional de carros autônomos. Um sistema como esse é classificado como missão-crítica, e a confiabilidade é uma peça chave para que acidentes não ocorram devido a falhas de hardware. Vale salientar que tal hardware consiste em múltiplos MPSoCs que devem garantir seu funcionamento mesmo na presença de falhas (JO, et al., 2014). Por isso a importância de pesquisas nessa área.

1.2 Organização do trabalho

O segundo capítulo deste texto apresenta a problemática a qual este trabalho se propõem a tratar. No capítulo 2, o referencial teórico traz toda a conceituação necessária para o entendimento da solução proposta. Em seguida, o capítulo 3 apresenta uma análise da literatura, com outros trabalhos baseados em tolerância a falhas em redes em chip. Logo após, o capítulo 4 apresenta a proposta, com todos as características descritas. Por conseguinte, no capitulo 5, são apresentados os resultados obtidos, a partir da implementação da solução proposta. Por fim, o capítulo 6 conclui o tema com uma análise geral do trabalho.

16

2 Referencial Teórico

2.1 Redes em Chip

A partir da necessidade de atender a demanda por escalabilidade, alto desempenho e baixo custo, e também, devido ao crescimento no número de núcleos dos MPSoCs, desenvolveu-se as redes em chip. Um modelo de comunicação baseado em canais ponto-a-ponto compartilhados, que tem como principal vantagem a reusabilidade e o paralelismo que possibilita alcançar um melhor desempenho.

Através das redes em chip, os componentes do MPSoC são interligados por meio de roteadores. Com um enlace conectando esses roteadores formando uma rede ponto-a-ponto (Figura 1). Sendo utilizados para o envio de pacotes, tipicamente usando canais simplex, ou seja, um canal unidirecional. Outras técnicas de enlace podem e são empregadas como mostra Pande, et al. (2005), tais como, o uso de canais virtuais, ou ainda canais full duplex.

Figura 1. MPSoC heterogêneo interligado por uma NoC.

Tipicamente, em um roteador padrão, nós temos as portas de entrada e saída com os buffers para memorização. Normalmente, uma crossbar interligando as portas, além de árbitros para controle de escalonamento dos

17

pacotes e algum mecanismo para o controle de fluxo da rede.

Uma vantagem das redes em chip é a variedade de possibilidades de topologia da rede. Na literatura há diversos tipos e formatos (SALMINEN; KULMALA; HAMALAINEN, 2008). Para esse trabalho, o foco é no modelo mais clássico, a grelha 2D, onde os roteadores são rearranjados em formato de matriz de duas dimensões, com os enlaces de tamanhos iguais, ilustrado na Figura 2. Essa é uma das topologias mais simples e uma das mais utilizadas na literatura.

Figura 2. NoC na topologia grelha 2d.

2.2 Falhas em NoCs

O aumento da integração entre os componentes trouxe grandes vantagens como diminuição da área e aumento de desempenho. Porém, com a miniaturização, os problemas de falhas nesses mesmos componentes aumentaram significantemente, incorporando tolerância a falhas como parte do projeto de hardware (ITRS, 2015).

Segundo Dumitras (2003, p.226), as falhas podem ser de natureza temporária, como por exemplo, um bit flip. Sendo classificadas ainda como dois tipos, falhas de omissão, quando, por exemplo, links perdem a mensagem ou os nós deixam de comunicar. Ou do tipo arbitrária, como no primeiro exemplo em que um componente desvia do comportamento especificado. As falhas de natureza temporária podem ser transitórias ou

18

intermitentes. Nas falhas transistórias, após o efeito causador da falha ser dissipado, o sistema retorna ao seu estado anterior ao da falha. Estas falhas são normalmente causadas por partículas de radiação. No caso de falhas intermitentes, estas se manifestam repetidamente. Em muitos casos, não é possível prever o momento em que ocorrerá normalmente. As falhas intermitentes são comumente causadas por erros de projeto (KOREN; KRISHNA, 2007).

Existem também as falhas de natureza permanente, como quando por um problema no processo de fabricação, o componente tem sua vida útil encurtada. Além disso, durante a vida útil do dispositivo, efeitos físicos podem afetar o chip e causar danos permanentes. Esse é o caso de problemas como electromigration, oxide breakdown, negative bias

temperature instability, dentre outros (MARCULESCU, 2009).

Para falhas especificamente em NoCs, temos a divisão por componentes, os quais uma possível falha afeta de maneira distinta cada um deles. As falhas são normalmente detectadas por um dispositivo, que pode ser externo ao sistema que está sendo testado ou interno. Neste último caso, o componente é chamado BIST (Built In Self Test), que, normalmente, faz checagens periódicas para garantir o funcionamento livre de falhas.

Neste trabalho trataremos de falhas permanentes nos buffers dos roteadores. Mais detalhes sobre o tipo de falhas e a solução proposta podem ser encontrados no capítulo 5.

2.3 SystemC TLM

Para uso de simulação de hardware utilizaremos a biblioteca SystemC, aprovado como padrão IEEE Std 1666-2005, atualmente na versão 2011 (INITIATIVE, 2011). O SystemC oferece um motor de simulação e um conjunto de funções para modelagem de sistemas tanto de hardware quanto de software, por utilizar a linguagem C++, tornou-se uma ferramenta simples e eficiente para o projeto e simulação de modelos arquiteturais.

19

blocos de hardware. Cada um desses módulos se comunica entre si através de estruturas e chamadas de função. Cabe ao programador regular a temporização da simulação. No caso deste trabalho, usaremos a classe TLM (Transaction-Level Modeling) versão 2.0. Essa classe define simulações para a modelagem de performance e exploração de arquitetura de projeto, onde não são necessários todos os detalhes de um modelo RTL (Register Transfer

Level). Podemos modelar por exemplo transações em modelos de

comunicação, tais como uma rede em chip. Como vantagens, apresenta a maior facilidade de abstração do hardware e uma maior velocidade para implementação e simulação dos modelos.

O padrão TLM define algumas funções e estruturas, sendo elas, os

sockets de comunicação, canais entre dois ou mais módulos do SystemC que

permitem a comunicação utilizando uma interface de transporte. Além disso, define também o generic payload, uma estrutura padrão representando o pacote de comunicação. A utilização desses padrões aumenta o grau de compatibilidade com outros blocos de diferentes implementações, desde que adaptados para utilizar os mesmos mecanismos.

Cada módulo do TLM é representado como uma thread no C++. O motor de simulação controla a execução desses módulos de maneira a executar todos eles sem preempção. Isto porque o SystemC executa um modelo multitarefas cooperativo, onde cada módulo deve ceder tempo de execução para que o próximo execute, e assim por diante.

Para controle do tempo de simulação, podemos definir dois estilos distintos de comunicação, o AT (Approximately Timed) e o LT (Loosely Timed). No primeiro caso, a sincronização é feita individualmente em cada módulo, com uma chamada para o método wait toda vez que for necessário avançar o tempo de simulação. Seu uso é apropriado para manter um tempo bem definido para cada atividade que for necessário seguir a sincronização. Porém, torna toda a simulação mais lenta, com uma troca de contexto para toda vez que ocorrer a chamada ao método wait. No modo LT apenas anotações de tempo são passadas entre os métodos, sem necessidade de sincronização explícita para todos os componentes. Além disso, o modo LT

20

pode implementar o modo de desacoplamento temporal, onde um módulo pode rodar por um tempo futuro definido a frente da simulação geral. Permitindo a simulação de sistemas complexos que executam sistemas operacionais completos com um tempo de simulação satisfatório.

Figura 3. Diagrama de casos de uso, estilos e mecanismos do SystemC TLM 2.0.

Além das escolhas do modelo de temporização, o TLM oferece duas interfaces de transporte distintas, blocking transport e non-blocking transport. As duas interfaces estão ligadas diretamente ao estilo de comunicação escolhido, LT e AT respectivamente. A diferença entre os dois é que o

non-blocking transport divide o transporte do pacote em fases que delimitam

pontos de sincronização, já o blocking transport utiliza apenas as anotações de tempo que são passadas para o método. Na Figura 3 é possível ver o diagrama de uso dos mecanismos do SystemC TLM de acordo com tipo de simulação, no nosso caso, como uma análise arquitetural, utilizamos toda a parte desde generic payloads, até o blocking interface.

Uma vez que esse trabalho se trata de uma proposta de tolerância a falhas, a escolha pela descrição arquitetural em SystemC TLM se deu pela necessidade de ter uma forma de explorar diferentes estratégias de forma mais simples e rápida. É importante salientar que o nível de abstração

21

escolhido permite realizar simulações e avaliar latência, que é o principal aspecto a ser afetado pela técnica de tolerância a falhas. Apesar disso, um outro aspecto importante que não pode ser avaliado nesse nível de abstração é a área, cuja análise ficou para trabalhos futuros.

22

3 Trabalhos Relacionados

As soluções de tolerância a falhas da literatura passam por todos os componentes da NoC em todos os níveis. Desde propostas baseadas no algoritmo de roteamento, tais como em (ZOU; PASRICHA, 2010), onde é proposto um algoritmo de roteamento adaptativo que evita roteadores com falha. Até soluções que envolvem os buffers de entrada de cada roteador (REN et al., 2013), proposta em que os buffers das unidades vizinhas são utilizados quando o buffer do roteador atual falha.

Todas as propostas apresentam vantagens e desvantagens. No caso de soluções através de roteamento adaptativo, a vantagem é poder evitar alterações no modelo arquitetural. Porém, a desvantagem é a possibilidade de aumentar as chances de travamento da rede devido ao bloqueio mútuo de pacotes. Já no caso de soluções como (REN et al., 2013) na qual é utilizado espaço do buffer vizinho como em um empréstimo, a vantagem é a utilização de outros componentes do sistema sem necessidade de alterar o algoritmo de roteamento. A desvantagem, porém, vem da necessidade de adicionar todo o aparato do algoritmo de troca de mensagens associado, para fazer o sistema funcionar.

Como descrito no capítulo anterior, uma classe de técnicas de tolerância a falhas baseado na redundância de hardware consiste na replicação de recursos. Uma técnica muito conhecida, na qual, quando um determinado componente falha, um novo, de funcionalidade semelhante, toma seu lugar e permite manter o sistema em seu funcionamento normal. Em (DA SILVA JÚNIOR; PEREIRA, 2015), do autor deste texto, é descrito um método para replicar os roteadores da NoC, acrescentando 50% roteadores extras, de modo a aumentar a confiabilidade do sistema como um todo. Além disso, os autores também apresentam uma análise de confiabilidade versus área, que avalia o impacto da replicação de roteadores em ambos os aspectos. O estudo envolve uma modelagem matemática de confiabilidade. Essa técnica já havia sido utilizada por (REN, et al., 2013), no qual é possível

23

encontrar propostas com 50%, 75%, 100% de aumento de área. Porém, os autores não apresentam o estudo de confiabilidade. Em ambos os trabalhos, quanto maior o número de réplicas maior a confiabilidade. Em contrapartida, a área cresce de maneira proporcional, impactando também no custo, potência e energia do sistema.

Ainda na replicação de recursos do chip, existem propostas que replicam apenas certos elementos dentro do roteador, como buffers e

crossbars (LATIF et al., 2012). Ativando esses elementos sob demanda, caso

haja uma falha em um componente semelhante. Não tão efetivo como os anteriores, podem evitar maiores problemas prevenindo a falha total dos roteadores que impediriam o funcionamento da rede, mas apenas cobrem um tipo de falha parcial. Os links entre os roteadores também são explorados. Nesse caso, utilizando técnicas como canais virtuais, onde o link pode ser compartilhado a partir de alguma técnica de multiplexação. Assim, permitindo que canais parcialmente com falhas possam ser aproveitados (KOIBUCHI, 2008). A principal desvantagem do uso de canais virtuais é a potência relativamente alta, aumentando o consumo energético do sistema como um todo (REDDY; VASANTHA, 2016).

A replicação física de canais também pode ajudar na tolerância a falhas do sistema. (JAFRI et al., 2013) apresenta uma proposta em que canais adicionais são criados como um backup. Normalmente os elementos mais complexos, como os roteadores ou as próprias unidades de processamento, são muito mais suscetíveis a falhas devido à complexidade maior de seus componentes, uma técnica desse tipo, no entanto pode ser de grande ajuda quando combinada com outras de replicação de roteadores, fornecendo uma robustez extra ao sistema aliado ao baixo custo de implementação.

Algoritmos de detecção e correção de erros como o ECC (Error Correction

Code) (HSIAO et al., 1969) também são técnicas conhecidas utilizadas para

tratamento das falhas chamadas transientes, são as falhas temporárias normalmente causadas por radiação eletromagnética (REDDY; VASANTHA, 2016). Podem causar uma inversão (ou flip) de bits ou, no pior dos casos, uma falha momentânea nos componentes. Para esses tipos de situações,

24

quando o projeto de hardware tiver essas especificações, esse tipo de técnica de detecção e correção de erros é a melhor maneira de fazer o tratamento de falhas.

Para trabalhos de tolerância a falhas, a maioria dos autores assumem a existência de um mecanismo de detecção de falhas. Um exemplo desse tipo de sistema é o BIST (Buit-in-Self-Test), utilizado em quase todas as técnicas aqui citadas. O componente com o módulo BIST faz um teste de hardware de maneira periódica a fim de detectar falhas no hardware e, a partir disso, realizar alguma ação. O módulo BIST pode estar presente em cada roteador, ou também em uma NoC completa, fazendo uso de técnicas mais complexas como em (GRECU et al., 2006). A proposta desses autores é incorporar um sistema decentralizado que, com técnicas de broadcast, consegue informar toda a rede sobre a presença de falhas. Uma vez detectado, o controle do sistema faz a troca necessária, normalmente, incluindo vários multiplexadores e demultiplexadores na rede. Um grande problema desse tipo de técnica é o aumento da área do chip.

Algoritmos de detecção e correção de erros como o ECC (Error Correction

Code) (HSIAO et al., 1969) também são técnicas conhecidas utilizadas para

tratamento das falhas chamadas transientes, são as falhas temporárias normalmente causadas por radiação eletromagnética (REDDY; VASANTHA, 2016). Podem causar uma inversão (ou flip) de bits ou, no pior dos casos, uma falha momentânea nos componentes. Para esses tipos de situações, quando o projeto de hardware tiver essas especificações, esse tipo de técnica de detecção e correção de erros é a melhor maneira de fazer o tratamento de falhas.

Os trabalhos apresentados nesse capítulo compreendem alguns exemplos de soluções encontradas na literatura voltada ao aumento de confiabilidade das NoCs. Diversas outras propostas podem ser encontradas (RADETZKI et al., 2013) e (WERNER et al., 2016). O principal diferencial deste trabalho em relação às propostas da literatura é de não perder a comunicação com os elementos de processamento quando seus roteadores falham. Para tal, a estratégia proposta consiste em conectar os elementos de processamento a

25

todos os roteadores vizinhos. Assim, quando o seu roteador falhar, um dos vizinhos poderá assumir a comunicação do elemento de processamento com o restante da rede. Além disso, o roteador falho passa a ser utilizado como um switch, e não há necessidade de acrescentar roteadores extras à rede.

26

4 Proposta

Para este trabalho idealizamos uma NoC, baseada na SoCIN (ZEFERINO e SUSIN, 2003), com um sistema de tolerância a falhas baseado no compartilhamento de roteadores por duas unidades processantes. A ideia central da proposta é poder redistribuir as unidades processantes entre os roteadores que são vizinhos ao roteador com falha. Além disso, este roteador passa a atuar apenas como um switch, encaminhando mensagem entre portas. Com isso, conseguimos manter a NoC funcional em um cenário de falhas nos buffers do roteador.

Este trabalho trata de falhas permanentes nos buffers do roteador. É possível também aplicar a mesma técnica nos controladores de fluxo. Para o mecanismo de tolerância a falhas funcionar, assume-se que os outros componentes do roteador, como portas e crossbar, bem como os links da NoC não falham. Para esses componentes, outras técnicas podem ser incluídas no futuro.

Nas seções a seguir, será detalhada a arquitetura da rede em chip e o modelo de tolerância a falhas proposto.

4.1 Arquitetura da Rede em Chip

A NoC construída utiliza os conceitos da SoCIN, ou seja, utiliza uma topologia em grelha 2D, onde cada roteador é posicionado como em uma célula de uma matriz de duas dimensões, interconectados por meio de dois canais simplex (unidirecionais), um para cada direção, como ilustrado na Figura 4. O roteador possui quatro portas, uma para cada direção cardeal (norte, sul, leste e oeste), no total de quatro portas, além de uma porta local, todas elas de entrada e saída.

27 Figura 4. Visão geral dos roteadores da NoC proposta.

Um elemento essencial para o funcionamento da NoC e para o mecanismo de tolerância a falhas proposto neste trabalho é a interface de rede (NI - Network Interface).

A NI serve como um adaptador de comunicação entre o roteador e o IP (Intellectual Property) a ele conectado, que neste trabalho, trata-se do elemento de processamento (EP). Porém neste trabalho, mais que isso, a interface de rede faz parte da solução de tolerância a falhas, pois esse componente é o responsável por reconectar um EP vizinho na rede quando o roteador do EP falha. O conceito de vizinho se define aqui como um componente adjacente na topologia. Devido a natureza da topologia grelha 2D, o número máximo de elementos de processamento suportados simultaneamente por cada interface de rede é limitado por cinco EPs conectados, sendo um o próprio EP do nó, e os outros quatro dos vizinhos adjacentes. De maneira análoga, NIs de nós localizados na borda da NoC terão menos vizinhos que os do centro da rede. Logo, o número de elementos de processamento que a NI das bordas pode receber é reduzido de acordo. A Figura 5 ilustra um nó da rede, chamado de Referência, conectado aos nós adjacentes. As conexões são estabelecidas através dos roteadores (blocos cinza). Conectado à porta loca do roteador está a NI (bloco verde). Cada roteador está conectado a uma única NI. Os elementos de processamento foram ocultados para simplificar a figura.

28 Figura 5. Disposição dos elementos adjacentes de um roteador no núcleo da NoC.

Como tratado anteriormente, uma NoC pode receber qualquer tipo de IP (Intellectual Property) na sua interface. Neste trabalho, os IPs são os elementos de processamento (EPs). Para simplificar a solução apresentada, consideramos todos esses elementos como. Porém, a solução também se aplica para redes heterogêneas. Os EPs são conectados às interfaces de rede, e por conseguinte cada uma delas possui inicialmente um EP conectado na sua porta local. A Figura 6 ilustra um nó da grelha 2D. É possível obersavar um roteador conectado a uma interface de rede e esta conectada a um EP. Cada um deles, apesar da representação de apenas um canal interligando-os, são dois canais simplex, representados na forma compacta para melhor visualização dos componentes.

Figura 6. Visão objetiva dos componentes da NoC.

29

• Algoritmo de roteamento XY: onde a mensagem trafega na rede primeiro na direção X e depois Y. Considerando na topologia grelha 2D o X como o índice de colunas e Y o de linhas, esse algoritmo é muito utilizado por ser simples e livre de deadlocks, ou seja, evita situações de travamento de mensagens.

• Modelo de chaveamento SAF (Store-and-forward): um método simples de chaveamento. Com as mensagens no formato de pacotes idênticos, cada roteador recebe um pacote por completo e armazena em um dos buffers. Para a implementação deste chaveamento, cada roteador possui um buffer para cada porta, menos a porta local, num total de quatro buffers.

• Roteador com um controlador de fluxo em cada porta: sendo este baseado em créditos que medem a capacidade de receber pacotes em um determinado instante. A Figura 7 ilustra os componentes necessários para o chaveamento SAF e o controlador.

Figura 7. Componentes da porta do roteador.

• Modelo de arbitragem centralizado, com o algoritmo de escalonamento round-robin. Este algoritmo escolhe uma porta de entrada por vez para enviar a saída.

30

• Conexão entre portas via rede crossbar 5x5, conectando todas as portas entre si. A conexão entre portas é ilustrada na Figura 8. • Componente BIST: um componente utilizado para testar o

roteador. Este componente, ilustrado na Figura 8, não foi implementado neste trabalho.

Figura 8. Disposição dos componentes do roteador.

4.2 Mecanismo de Tolerância a Falhas Proposto

Para implementação de tolerância a falhas utilizamos um conjunto de técnicas que trabalham para manter a rede funcionando em certos cenários de falhas permanentes.

A proposta apresentada neste trabalho visa lidar com um tipo específico de falhas, as falhas permanentes nos buffers. Devido a utilização constante desses elementos, suas chances de falhas são maiores de acordo com as regras de tempo de vida dos componentes (FIORIN, SAMI, 2014).

31 Figura 9. Rotina de recuperação de falhas passo I.

O mecanismo de tolerância a falhas funciona em três fases. Na primeira fase, quando um roteador é diagnosticado com falhas através de um módulo BIST a ser implementado, o modo de recuperação é acionado. Imediatamente, o roteador bloqueia todas as entradas, e nenhum pacote é recebido. A rotina de recuperação envia um pacote especial para todas as unidades vizinhas. Esse pacote viaja até as respectivas interfaces de rede. A partir desse evento é ativada a segunda fase da rotina. A primeira fase é ilustrada na Figura 9.

Na segunda fase, apresentada na Figura 10, todas as interfaces de rede com unidades livres, isto é, que ainda não tiveram todas as portas preenchidas, enviam de volta uma nova mensagem reportando a disponibilidade de recebimento de mais um EP. O roteador com falha nos buffers recebe essas mensagens, e escolhe a qual NI irá conectar sua EP. A NI escolhida é aquela cuja mensagem de retorno chegou primeiro (a mais rápida a responder).

Logo após, é iniciada a terceira e última fase, ilustrada na Figura 11. O roteador após selecionar o novo destino do seu EP, envia um pacote para confirmação de anexação a uma nova interface de rede. O roteador vizinho, que informou disponibilidade, recebe o pacote e configura sua tabela de roteamento para a nova EP na porta local. O pacote então é enviado para a interface de rede, que de maneira análoga, configura sua tabela de

32

roteamento e aumenta em uma unidade seu buffer de saída para evitar descartes de pacotes. Por fim, o roteador original passa a trabalhar apenas como um switch, redirecionando pacotes de entrada para uma saída sem nenhum tipo de controle de fluxo. Esse modo de operação é chamado de modo de segurança, e serve apenas para manter a funcionalidade básica da rede.

Figura 10. Rotina de recuperação de falhas passo II.

Esse método de recuperação foi escolhido pelo baixo custo de implementação e acima de tudo, a minimização do impacto na rede. Não há qualquer mudança na estratégia de roteamento. A interrupção na NoC afeta somente o roteador defeituoso e seus vizinhos, que gastam algum tempo trocando mensagens de recuperação. Com o roteador defeituoso em modo de segurança, o fluxo da rede é distribuído para os nós adjacentes, ou seja, a capacidade de reter pacotes nos buffers da rede é reduzida. Dessa forma a performance da rede degrada de forma suave e previsível.

33 Figura 11. Rotina de recuperação de falhas passo III.

Com essa estratégia planejada, precisamos adicionar mais alguns elementos ao hardware para que seja possível o seu funcionamento, são eles:

1. Quatro fios adicionais para cada interface de rede, um para cada elemento vizinho que possivelmente possa ser adicionado.

2. Multiplexadores na entrada das NIs, para fazer a seleção dos elementos de processamento.

3. No roteador, é adicionada toda a lógica de recuperação no seu controlador. Esta lógica será futuramente somada a parte de detecção de falhas feita pelo BIST, quando este for implementado. 4. Registradores: tanto a interface de rede quanto o roteador devem receber registradores para fazer a memorização da tabela de roteamento.

5. Tabela de roteamento: quando um EP muda de roteador devido a falha, para rotear as mensagens para o novo roteador, foram utilizadas tabelas de roteamento. Essas tabelas informam qual o novo destino do pacote, uma vez que o roteador original não está mais conectado ao EP.

A Figura 12 ilustra a arquitetura da NoC com a conexão dos elementos de processamento vizinhos às NIs, bem como os multiplexadores necessários para selecionar qual EP está se comunicando com a NI no momento.

34 Figura 12. Conexões adicionais para um roteador.

35

5 Resultados

5.1 Implementação da Simulação

Nosso projeto foi implementado em SystemC utilizando a linguagem de programação C++. Primeiramente foi feito o levantamento dos módulos necessários para a simulação. Para isso, implementamos os módulos do elemento de processamento, o qual envia transações como um iniciante da comunicação.

Um pacote sempre é originado por um EP e tem como destino outro EP da rede. O próximo elemento incluído foi a interface de rede, que faz a comunicação entre o EP e os roteadores. Por conseguinte, chegamos no roteador, também representado como um módulo do SystemC. Esse roteador, em especial, precisa de componentes extras, como buffers para cada porta e um árbitro que gerencia as saídas dos pacotes. Para gerar os pacotes foi adicionado um gerador de tráfego. E a cola de todos esses módulos que é o módulo top, responsável por conectar todos os outros componentes com suas respectivas portas. A organização de todos os módulos pode ser visualizada na Figura 13.

Figura 13. Diagrama de blocos de todos os módulos do simulador.

O modelo é completamente baseado no blocking transport, ou seja, existe apenas uma anotação de tempo que é passado entre os módulos e, ao

36

final da transação, esse atraso de processamento é contabilizado. Existem vários parâmetros que podem ser customizados para a criação da NoC, tais qual o tamanho da rede; a capacidade dos buffers; quantidade de transações ativas na rede; etc. Todo o modelo é conectado na chamada fase de elaboração, onde os módulos são inicializados e a simulação começa de fato.

Para representar as tabelas de roteamento, foi criado um mapa de chave, valor. Todo o protocolo de recuperação de falhas foi incluído no modelo de simulação. Além disso, utilizamos o campo de endereço de 32 bits para gravar algumas informações importantes. No pacote detalhado na Figura 14, estão inclusos o endereço da unidade de destino e o requisitante, além de informações sobre a recuperação de falhas. São 4 bits para endereço por coordenada, x e y.

Figura 14. Formato do endereço dos pacotes.

O procedimento de simulação se inicia no gerador de tráfego, que gera um determinado número de pacotes de acordo com um parâmetro definido. Cada pacote recebe um endereço de destino e o EP de partida. Esses dois endereços são sempre diferentes e gerados de maneira aleatória. Os pacotes gerados são passados por uma interface ao EP correspondente. Esse, por sua vez, somente envia um pacote por vez.

Quando há cenários de falhas, também configurado por meio de parâmetro, é definido um número máximo de unidades com falha. Os pacotes de falha são obrigatoriamente gerados no início da simulação e não contam na quantidade de pacotes total. As unidades a falhar são escolhidas aleatoriamente pelo gerador de tráfego.

37

5.2 Resultados obtidos

Os experimentos foram feitos usando um agregado de configurações diversas. Primeiramente, foram definidos três tamanhos de NoCs: 3x3, 6x6 e 9x9. A segunda característica utilizada foi a variação no número de pacotes injetados, sendo estes 100, 1.000 e 10.000 pacotes. Por último, foi determinada a porcentagem de falhas, com 0, 10% e 25%, sempre arredondado para baixo.

A partir desta sorte de configurações, extraímos a latência de cada pacote injetado na rede, ou seja, o tempo que leva o pacote para chegar no destino. A implementação tem tempos fixos de 1 nanosegundo para cada ação realizada. Foi feito dessa forma para melhorar a reprodutibilidade dos experimentos. Apesar disso, a injeção de pacotes é feita de maneira aleatória utilizando a função rand do C++. Os tempos finais correspondem a latência média. Além disso, cada configuração é executada seis vezes, fazendo novamente a média entre as execuções.

Na primeira configuração geramos 100 pacotes, como pode ser visto na Figura 15. Como o número de pacotes é relativamente baixo, a latência média também acompanha a tendência, pois há menos pacotes ocupando os buffers dos roteadores. Logo, a latência dependerá apenas da quantidade de

hops necessários para enviar um pacote da origem ao destino. Com relação

ao número de falhas, fica claro que 25% de uma NoC 3x3 impacta muito mais que nas outras redes maiores. Devido a redução no número de caminhos possíveis, os pacotes se acumulam mais rapidamente nos buffers dos roteadores, gerando um maior atraso nos pacotes como consequência. Porém, o impacto da solução é limitado em qualquer uma das três configurações com um aumento médio de 20% na latência com o aumento de falhas. Mesmo com esse impacto, a rede com um quarto de roteadores com falha, no pior caso, tem seu desempenho limitado a metade.

38 Figura 15. Latência média para 100 pacotes gerados em diferentes configurações.

No segundo experimento, ilustrado na Figura 16, aumentamos o número de pacotes para 1.000. A NoC 3x3 não suporta uma taxa de injeção dessa magnitude, por isso foi removida dos resultados. Com um maior número de pacotes, temos o aumento natural da latência. O impacto nesse caso é maior na NoC 9x9 com um aumento de 40% na latência média já nos 10% de roteadores com falha. A diferença é ainda mais substancial, ultrapassando a barreira dos 50% de degradação de desempenho.

39

No último experimento, ilustrado na Figura 17, pelo mesmo motivo de do experimento anterior, a NoC 6x6 foi removida da comparação. Agora resta apenas a NoC 9x9 com 10.000 pacotes sendo injetados na rede. Nesta situação, o impacto é substancial. Com 25% de roteadores com falha, o atraso fica na casa dos 100ms, na média dos acessos a memória RAM (VAHID, 2002). Porém, a rede está funcionando com 40% de seu desempenho total. Para manter uma base, a rede está com 20 roteadores funcionando com switches, e mesmo assim está funcionando com quase metade da capacidade total.

40

6 Considerações finais

Este trabalho apresentou um novo modelo de NoC tolerante a falhas com compartilhamento de roteadores entre elementos de processamento. A solução apresentada permite manter todos os elementos de processamento conectados à rede, mesmo quando roteadores precisam ser desativados devido às falhas.

Para avaliação inicial de viabilidade, a solução foi implementada e simulada em SystemC TLM. Isso permitiu criar uma implementação parametrizada, onde diversos cenários foram testados e a relação entre cobertura de falhas e latência foi avaliada.

Os resultados obtidos mostraram um impacto máximo de 40% na latência no pior dos casos, com 25% das unidades com falha. Para a evolução do modelo, por utilizar SystemC TLM, temos a opção de rodar um

microkernel com um sistema operacional completo, e a partir disso utilizar

benchmarks e aplicações do mundo real. Além disso, outras técnicas de tolerância a falhas podem ser acrescentadas ao modelo, bem como, comparar com outros trabalhos da literatura. Por fim, o desenvolvimento do módulo de detecção de falhas também é parte dos trabalhos futuros.

41

Referências

BORKAR, Shekhar. et al. Microarchitecture and design challenges for gigascale integration. MICRO. 2004. p. 3-3.

BROWN, Stephen D. et al. Field-programmable gate arrays. Springer Science & Business Media, 2012.

DA SILVA JÚNIOR, Dogival Ferreira; PEREIRA, Monica Magalhães. A Transparent Fault Tolerance Solution for NoCs. 2014

DUMITRAS, Tudor; KERNER, Sam; MARCULESCU, Radu. Towards on-chip fault-tolerant communication. Asia and South Pacific Design Automation Conference. Proceedings of the ASP-DAC 2003. IEEE, 2003. p. 225-232. FIORIN, Leandro; SAMI, Mariagiovanna. Fault-tolerant network interfaces for networks-on-Chip. IEEE Transactions on Dependable and Secure Computing, v. 11, n. 1, p. 16-29, 2014.

GRECU, Cristian et al. BIST for network-on-chip interconnect infrastructures. VLSI Test Symposium, 2006. Proceedings. 24th IEEE. IEEE, 2006. p. 6 pp.-35.

HSIAO, Mu-Yue; TOU, Julius T. Application of error-correcting codes in computer reliability studies. IEEE Transactions on Reliability, v. 18, n. 3, p. 108-118, 1969.

INITIATIVE, OSCI Open SystemC. IEEE 1666 Language Reference Manual. 2011.

ITRS, ITRS 2015 Roadmap. Tech. rep., International Technology Roadmap for Semiconductors 2.0, 2015.

42

addressing multiple traffic classes. Microprocessors and Microsystems, v. 37, n. 8, p. 811-822, 2013.

JO, Kichun et al. Development of autonomous car—Part I: Distributed system architecture and development process. IEEE Transactions on Industrial Electronics, v. 61, n. 12, p. 7131-7140, 2014.

KIM, Jongman et al. A gracefully degrading and energy-efficient modular router architecture for on-chip networks. ACM SIGARCH Computer Architecture News, v. 34, n. 2, p. 4-15, 2006.

KOHLER, Adán; SCHLEY, Gert; RADETZKI, Martin. Fault tolerant network on chip switching with graceful performance degradation. IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems, v. 29, n. 6, p. 883-896, 2010.

KOIBUCHI, Michihiro et al. A lightweight fault-tolerant mechanism for network-on-chip. Proceedings of the Second ACM/IEEE International Symposium on Networks-on-Chip. IEEE Computer Society, p. 13-22, 2008. KOREN, Israel; KRISHNA. Fault-Tolerant Systems. Morgan Kaufmann, 2007. LATIF, Khalid et al. Designing a High Performance and Reliable Networks-on-Chip Using Network Interface Assisted Routing Strategy. Digital System Design (DSD), 2012 15th Euromicro Conference on. IEEE, p. 34-41, 2012. LEHTONEN, Teijo; LILJEBERG, Pasi; PLOSILA, Juha. Fault tolerance analysis of NoC architectures. IEEE International Symposium on Circuits and Systems. IEEE, p. 361-364, 2007.

MARCULESCU, Radu et al. Outstanding Research Problems in NoC Design: System, Microarchitecture, and Circuit Perspectives. Em: IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems, v. 28, n. 1, p. 3-21, 2009.

PANDE, Partha Pratim et al. Performance evaluation and design trade-offs for network-on-chip interconnect architectures. IEEE transactions on

43

Computers, v. 54, n. 8, p. 1025-1040, 2005.

RADETZKI, Martin et al. Methods for fault tolerance in networks-on-chip. ACM Computing Surveys (CSUR), v. 46, n. 1, p. 8, 2013.

REDDY, B. Naresh Kumar; VASANTHA, M. H. Survey on Performance and Energy consumption of Fault Tolerance in Network on Chip. International Journal of Reconfigurable and Embedded Systems, v. 5, n. 1, 2016.

REN, Yu et al. A fault tolerant NoC architecture using quad-spare mesh topology and dynamic reconfiguration. Journal of Systems Architecture, v. 59, n. 7, p. 482-491, 2013.

SALMINEN, Erno; KULMALA, Ari; HAMALAINEN, Timo D. Survey of network-on-chip proposals. white paper, OCP-IP, v. 1, p. 13, 2008.

VAHID, Frank; GIVARGIS, Tony. Embedded system design: a unified hardware/software introduction. New York: Wiley, 2002.

WERNER, Sebastian; NAVARIDAS, Javier e LUJÁN, Mikel. A Survey on Design Approaches to Circumvent Permanent Faults in Networks-on-Chip. ACM Comput. Surv. v. 48, n. 4, artigo 59, 2016.

ZEFERINO, Cesar Albenes; SUSIN, Altamiro Amadeu. SoCIN: a parametric and scalable network-on-chip. 16th Symposium on Integrated Circuits and Systems Design. IEEE, p. 169-174, 2003.

ZOU, Yong; PASRICHA, Sudeep. NARCO: neighbor aware turn model-based fault tolerant routing for NoCs. IEEE Embedded Systems Letters, v. 2, n. 3, p. 85-89, 2010.