Avaliação da execução de aplicações orientadas à dados na arquitetura de redes em chip IPNoSys

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

DEPARTAMENTO DE INFORMÁTICA E MATEMÁTICA APLICADA PROGRAMA DE PÓS-GRADUAÇÃO EM SISTEMAS E COMPUTAÇÃO

MESTRADO EM SISTEMAS E COMPUTAÇÃO

CHRISTIANE DE ARAÚJO NOBRE

Avaliação da Execução de Aplicações Orientadas à Dados

na Arquitetura de Redes em Chip IPNoSys

CHRISTIANE DE ARAÚJO NOBRE

Avaliação da Execução de Aplicações Orientadas à Dados

na Arquitetura de Redes em Chip IPNoSys

Dissertação submetida ao Programa de Pós-Graduação em Sistemas e Computação do Departamento de Informática e Matemática Aplicada da Universidade Federal do Rio Grande do Norte como parte dos requisitos para obtenção do título de Mestre em Sistemas e Computação (MSc.)

Orientador: Prof. Dr. Márcio Eduardo Kreutz

Catalogação da Publicação na Fonte. UFRN / SISBI / Biblioteca Setorial Especializada do Centro de Ciências Exatas e da Terra – CCET.

Nobre, Christiane de Araújo.

Avaliação da execução de aplicações orientadas à dados na arquitetura de redes em chip IPNoSys / Christiane de Araújo Nobre. – Natal, 2012.

63 f. : il.

Orientador: Prof. Dr. Márcio Eduardo Kreutz.

Dissertação (Mestrado) – Universidade Federal do Rio Grande do Norte. Centro de Ciências Exatas e da Terra. Departamento de Informática e Matemática Aplicada. Programa de Pós-Graduação em Sistemas e Computação.

1. Arquitetura de redes - Dissertação. 2. Redes em chip - Dissertação. 3. Sistemas embarcados – Dissertação. 4. Processamento paralelo - Dissertação. 5. Paralelismo em nível de instruções - Dissertação. 6. Aplicações orientadas a dados. I. Kreutz , Márcio Eduardo. II. Título

Agradecimentos

À Deus, pela vida, por ter me dado capacidade, sabedoria e persistência para realizar este trabalho.

À minha mãe Edinilse, por ter me ensinado a ser sempre generosa, modéstia, ter paciência, esperança e saber perdoar. Ao meu pai Sérgio, por sempre ter me incentivado a aperfeiçoar meus conhecimentos e a buscar novas conquistas.

Ao meu orientador Márcio Kreutz, pela compreensão, confiança, incentivo, pelos exemplos de competência e dedicação e por ter aceitado me orientar no mestrado. Agradeço pelo constante bom humor, e pelo apoio dado nesta conquista.

Aos professores que, de uma forma ou de outra, apresentaram sugestões, ideias e direcionamentos que foram de grande valia na continuidade e finalização do trabalho.

Ao meu esposo, Thiago, amigo e companheiro incansável, fonte de carinho e força nos momentos mais difíceis. Pessoa fundamental na minha e na concretização deste trabalho.

Às minhas irmãs Valéria e Isabela, e aos demais familiares, pelo apoio incondicional dado em todas as etapas da minha vida.

Aos amigos e colegas Sílvio, Jefferson e Jonathan, com quem muito aprendi e cujo trabalho, ajuda e sugestões serviram como base para os resultados aqui apresentados.

As amigas e colegas Alba, Aparecida, Dayanne, Eliselma, Katyanne, que muito admiro e com quem sempre posso contar a qualquer hora.

RESUMO

A crescente complexidade dos circuitos integrados impulsionou o surgimento de arquiteturas de comunicação do tipo Redes em chip ou NoC (do inglês, Network-on-Chip), como

alternativa de arquitetura de interconexão para Sistemas-em-Chip (SoC; Systems-on-Chip). As

redes em chip possuem capacidade de reuso de componentes, paralelismo e escalabilidade, permitindo a reutilização em projetos diversos. Na literatura, têm-se uma grande quantidade de propostas com diferentes configurações de redes em chip. Dentre as redes em chip estudadas, a rede IPNoSys possui arquitetura diferenciada, pois permite a execução de operações, em conjunto com as atividades de comunicação. Este trabalho visa avaliar a execução de aplicações orientadas a dados na rede IPNoSys, focando na sua adequação frente às restrições de projeto. As aplicações orientadas a dados são caracterizadas pela comunicação de um fluxo contínuo de dados sobre os quais, operações são executadas. Espera-se então, que estas aplicações possam ser beneficiadas quando de sua execução na rede IPNoSys, devido ao seu elevado grau de paralelismo e por possuírem modelo de programação semelhante ao modelo de execução desta rede. Uma vez observadas a execução de aplicações na rede IPNoSys, foram realizadas modificações no modelo de execução da rede IPNoSys, o que permitiu a exploração do paralelismo em nível de instruções. Para isso, análises das execuções de aplicações data flow foram realizadas e comparadas.

Palavras-chave: Redes em chip, arquiteturas de sistemas embarcados, processamento

ABSTRACT

The increasing complexity of integrated circuits has boosted the development of communications architectures like Networks-on-Chip (NoCs), as an architecture; alternative for interconnection of Systems-on-Chip (SoC). Networks-on-Chip complain for component reuse, parallelism and scalability, enhancing reusability in projects of dedicated applications. In the literature, lots of proposals have been made, suggesting different configurations for networks-on-chip architectures. Among all networks-on-chip considered, the architecture of IPNoSys is a non conventional one, since it allows the execution of operations, while the communication process is performed. This study aims to evaluate the execution of data-flow based applications on IPNoSys, focusing on their adaptation against the design constraints. Data-flow based applications are characterized by the flowing of continuous stream of data, on which operations are executed. We expect that these type of applications can be improved when running on IPNoSys, because they have a programming model similar to the execution model of this network. By observing the behavior of these applications when running on IPNoSys, were performed changes in the execution model of the network IPNoSys, allowing the implementation of an instruction level parallelism. For these purposes, analysis of the implementations of dataflow applications were performed and compared.

Lista de Figuras

Figura 1 – Topologias diretas: (a)Grelha 2D; (b) Torus 2D; (c) Cubo 3D; (d) Cubo 4D ou

Hipercubo; (e) Totalmente Conectada ... 17

Figura 2 – Topologias indiretas: (a) Crossbar; (b) rede multiestágio Ômega ... 17

Figura 3 – Exemplos de algoritmos de roteamento e suas rotas para enviar uma mensagem do nodo A para o nodo B ... 18

Figura 4 – Composição de uma mensagem: pacotes; flit; phits ... 20

Figura 5 – Abordagens para implementação de árbitros: (a) centralizada; (b) distribuída...21

Figura 6 – Estratégias de memorização utilizando roteador com quatro buffers: (a)SAFC; (b)SAMQ; (c)DAMQ...21

Figura 7 – Arquitetura IPNoSys...23

Figura 8 – MAU na Arquitetura IPNoSys...24

Figura 9 – RPU na Arquitetura IPNoSys...25

Figura 10 – Spiral Complement: (a) 1ª espiral; (b) 2ª epiral; (c) 3ª espiral; (d) 4ª espiral...26

Figura 11 – Formato do pacote da rede IPNoSys...27

Figura 12 – Programa básico na linguagem a fluxo de dados...32

Figura 13 – Visão geral do sistema ...36

Figura 14 – Formato do pacote modificado para programação...39

Figura 15 – Formato do pacote modificado para execução...40

Figura 16 – Etapa de programação da rede IPNoSys Dataflow – Parte 1...42

Figura 17 – Etapa de programação da rede IPNoSys Dataflow – Parte 2...43

Figura 18 – Etapa de programação da rede IPNoSys Dataflow – Parte 1...44

Figura 19 – Etapa de execução da rede IPNoSys Dataflow – Parte 1...45

Figura 20 – Etapa de execução da rede IPNoSys Dataflow – Parte 2...46

Figura 21 – Etapa de execução da rede IPNoSys Dataflow – Parte 3...46

Figura 22 – Tempo de Execução da Aplicação SDF: (a) 1 Pacote; (b) 2 Pacotes...48

Figura 24 –Potência da Rede IPNoSys: (a) 1 Pacote; (b) 2 Pacotes…...50

Figura 25 – Potência da Rede IPNoSys: (a) 3 Pacotes; (b) 4 Pacotes...51

Figura 26 – Quantidade de RPUs percorrido no Spiral Complement...55

Figura 27 – Roteamento com bloqueio da rede...56

Figura 28 – Desempenho estimado para variações da rede com dimensões 4x4...57

LISTA DE ABREVIATURAS E SIGLAS

DAMQ Dynamically Allocated Multi-Queue

DCT Discrete Cosine Transform

FIFO First in First Out

IPNoSys Integrated Processing NoC System

IP Intellectual Property

MAU Memory Access Unit

MDFM Manchester Data Flow Machine

MoC Model of Computation

MTTDA MIT Tagged Token Architecture

NoC Network-on-Chip

PDL Package Description Language

QNoC Quality of Service Network-on-Chip

QoS Quality of Service

RPU Routing and Processing Unit

SAFC Statically Allocated Fully Connected

SAMQ Statically Allocated Multi-Queue

SDF Synchronous Data Flow

SoCIN System-on-Chip Interconnection Network

SoC System-on-Chip

ULA Unidade Lógica e Aritmética

Sumário

1. INTRODUÇÃO ... 13

1.1.

1.2.

2. REFERENCIAL TEÓRICO ... 16

2.1.

2.1.1.

2.1.1.1.

2.1.1.2.

2.1.1.3.

2.1.1.4.

2.1.1.5.

2.1.1.6.

2.1.2.

2.2.

2.2.1.

2.2.1.1.

2.2.1.2.

2.2.1.3.

2.2.1.4.

3. ESTADO DA ARTE ... 30

3.1.

3.1.1.

3.1.2.

3.2.

3.3.

4. PROPOSTA DE MODELO DE EXECUÇÃO ORIENTADA A DADOS PARA REDE IPNOSYS ... 38

4.1.

4.1.1.

4.1.2.

4.2.

4.3.

5. RESULTADOS ... 47

5.1.

5.2.

6. CONSIDERAÇÕES FINAIS ... 59

6.1.

6.2.

13

1.

INTRODUÇÃO

Nas ultimas décadas cresceu a necessidade de estudos relacionados com o projeto de computadores e sistemas periféricos. Contudo, a ênfase de pesquisa tem se deslocado para uma área muito mais ampla: a de sistemas eletrônicos de uso específico. Sistemas embarcados são sistemas computacionais que possuem a mesma estrutura geral de um computador, mas a especificidade de suas tarefas faz com que não sejam usados nem percebidos como um computador.

HAMMOND (1997) e PATT (1997) já afirmavam que em poucos anos seria admissível existirem circuitos integrados compostos por mais de um bilhão de transistores, e atualmente, tal afirmação foi comprovada. Devido a esta capacidade de integração é possível incluir um sistema computacional completo em um único chip, compondo os chamados SoC

(System-on-Chip) ou Sistemas integrados.

Os SoC são baseados na arquitetura de barramento, que é a forma usual de interconexão entre os componentes do sistema. A interconexão por barramento é simples, sob o ponto de vista de implementação, mas apresenta diversas desvantagens (BENINI, 2002): (i) somente uma troca de dados é realizada por vez, já que o meio físico é compartilhado por todos os núcleos, provocando a redução do desempenho global do sistema; (ii) necessidade de mecanismos inteligentes de arbitragem para evitar desperdício; (iii) a escalabilidade é limitada, ou seja, o número de núcleos que podem ser ligados ao barramento é muito baixo.

Para controlar a complexidade de criar chips contendo bilhões de transistores, é necessário separar a comunicação da computação. Assim, as NoCs (Network-on-Chip) estão

emergindo como um alternativa para interconexões existentes nos chips, onde a abstração das camadas de protocolos é utilizada para modularizar o projeto de comunicação. Além disso, a NoC é uma rede de interconexão chaveada, apresenta largura de banda escalável, usa conexões ponto a ponto curtas e utiliza o paralelismo na comunicação.

Vários grupos de pesquisa estão estudando as possibilidades arquiteturais das NOCs, sugerindo soluções para topologias de rede, algoritmos de roteamento, comunicação paralela, dentre outros. Um dos primeiros resultados efetivos sobre rede em chip foi alcançado usando a rede NoC SPIN (GUERRIER, 2000), que propôs um modelo de arquitetura baseado em rede integrada de comutação. E explica porque o barramento compartilhado não cumpre os requisitos de desempenho e apresenta uma alternativa de interligação que tem origem da computação paralela.

14 indústria de sistemas embarcados. Encontrando soluções adequadas, as redes em chip são capazes de lidar com as mais diversas áreas, como: sistemas multimídia e de reconhecimento de voz, jogos 3D, aplicações de tempo-real e algoritmos de codificação e decodificação de vídeo.

Em uma rede em chip, a topologia é uma das suas principais características, consistindo na organização da rede sob a forma de grafo, onde os roteadores são os vértices e os canais os arcos. Um estudo de topologias de NoC irregulares e adaptáveis conforme a necessidade da aplicação é proposto por STENSGAARD (2008). A arquitetura possibilita a minimização generalizada da plataforma SoC, incluindo ligações longas e ligações direta entre blocos IP (Intellectual Property). A topologia é configurada por meio inserção de uma

camada entre roteadores e links, possibilitando uma diminuição de 56% no consumo de energia em comparação com uma topologia em malha estática 2D.

O chaveamento em NoCs é necessário para definir como as mensagens são transferidas da entrada dos roteadores para os seus canais de saída. Uma das técnicas de chaveamento mais importante é a por canais virtuais, já que reduz o bloqueio de um canal por um determinado pacote na rede. O surgimento de uma arquitetura de buffer centralizado possibilitou a alocação de canais virtuais em tempo real de acordo com as condições de trafego da rede, maximizando a taxa de transmissão e a diminuição do buffer, tendo como resultado a redução da área total e do gasto de energia, obtendo um desempenho semelhante ao de um roteador genérico (NICOPOULOS et al., 2006).

Em 2004, um grupo de pesquisadores do Israel Institute of Tecnology desenvolveu uma arquitetura de NoC provendo QoS (Quality of Service). A rede QNoC, foi apresentada

por BOLOTIN et al. 2004, a qual utiliza uma topologia irregular que atende às estruturas típicas de SoC heterogêneos, usa o chaveamento por pacotes do tipo wormhole e o

mecanismo de controle de fluxo é baseado em créditos combinado com canais virtuais. A QoS fornecida pela QNoC ocorre por meio da análise do tráfego de comunicação e distribuição das mensagens em seus níveis de serviço. Uma arquitetura QNoC personalizada pode ser criada por meio da modificação da sua arquitetura de rede genérica; tal processo de customização minimiza o custo da rede, mantendo a QoS desejada.

A rede SoCIN (ZEFERINO, 2003) apresenta uma arquitetura de rede em chip, podendo ser dimensionada para atender aos requisitos de custo e desempenho de sistemas integrados. Esta rede tem como diferencial um núcleo roteador configurável, que pode ser dimensionado em função dos requisitos do sistema.

15 das demais redes em chip encontradas na literatura, pois a mesma utiliza seus próprios roteadores como elemento de processamento, permitindo a execução de aplicações orientada à dados. Portanto, a rede IPNoSys pode trazer resultados interessantes para aplicações especificas, como as aplicações genéricas SDF (Synchronous Data Flow).

1.1.

OBJETIVOS

O objetivo mais relevante deste trabalho é avaliar execuções de aplicações SDF na rede IPNoSys. Pretende-se propor modificações na estrutura da rede visando otimizar as restrições de projeto.

Como objetivos específicos, este trabalho apresenta:

· Realizar estudos arquiteturais das NoCs.

· Realizar comparações da arquitetura da rede IPNoSys com outras NoCs. · Mapear aplicações SDF para a rede IPNoSys.

· Analisar a viabilidade da rede IPNoSys, investigando suas vantagens como

NoC ao executar aplicações SDF.

· Propor soluções arquiteturais para rede IPNoSys.

1.2.

ESTRUTURA DO TRABALHO

Este trabalho está organizado da seguinte forma: no CAPÍTULO 2 são apresentados conceitos básicos sobre redes em chip, focando na rede IPNoSys, que foi a NoC utilizada para o desenvolvimento deste trabalho. O CAPITULO 3, faz uma introdução ao modelo de computação data flow, e também, é abordada a caracterização

16

2.

REFERENCIAL TEÓRICO

Nesse capítulo são apresentados os conceitos fundamentais sobre as redes em chip, discutindo suas principais características e apresentando suas vantagens e desvantagens sobre as outras redes de interconexão. Além disso, é feita uma revisão sobre a definição do modelo de computação data flow. Nessa revisão, também são apresentadas as principais variações do

modelo data flow em termos de modelos de execução.

2.1.

REDES EM CHIP

A rede em chip vem sendo utilizada como uma nova proposta para conectar múltiplos processadores em sistemas distribuídos, onde se aplica as ideias de rede de computadores para dentro de um único chip, conectando-se através de arquiteturas de interconexão muitos núcleos (Guerrier e Greiner, 2000).

Nos sistemas em chip, a solução ideal é utilizar a rede em chip como mecanismo de interconexão permitindo um rápido dimensionamento do sistema e um grau maior de escalabilidade (BENINI; DE MICHELI, 2002). Isso é devido também a sua capacidade de comunicação paralela entre os elementos do sistema, através da multiplicidade de caminhos possíveis existentes nela.

2.1.1 Características das Redes em Chip

Uma rede de interconexão pode ser caracterizada pela sua topologia e pelas estratégias empregadas para roteamento, controle de fluxo, chaveamento, arbitragem utilizada, dentre outras características. Abaixo serão brevemente definidos e classificados os principais componentes e algoritmos que constitui uma rede em chip (DUATO, 1997) (ZEFERINO, 2003):

2.1.1.1.Topologia

A topologia de uma rede em chip é a disposição dos nodos e canais sob a forma de um grafo. Segundo (CARARA, 2004), as topologias podem ser classificadas em duas classes principais: as redes diretas e as redes indiretas.

17 Figura 1. Topologias diretas: (a) Grelha 2D; (b) Torus 2D; (c) Cubo 3D; (d)Cubo 4D ou Hipercubo;

(e) Totalmente Conectada. Fonte: REGO, 2006.

Nas topologias de redes indiretas, nem todos os roteadores estão conectados a um núcleo de processamento, como acontece na topologia de rede direta, pois alguns são utilizados como pontes entre os roteadores que estão conectados aos núcleos (DALLY, TOWLES, 2004). A FIGURA 2 apresenta as duas topologias de redes indiretas que mais se destacam: a crossbar e a rede multiestágio.

18 2.1.1.2.Roteamento

O algoritmo de roteamento define como um pacote elege um caminho dentro desse grafo. Para que o pacote chegue ao seu destino, é preciso que ele siga na rede o caminho indicado pelo algoritmo de roteamento. Podem ser classificados como determinísticos (algoritmo XY), adaptativos (algoritmo baseado em tabelas) e parcialmente adaptativos (West-First, North-Last, Negative-Firts) (DUATO, 1997).

Figura 3. Exemplos de algoritmos de roteamento e suas rotas para enviar uma mensagem do nodo A para o nodo B.

Fonte: MATOS, 2010

De acordo com (DALLY e TOWLES, 2004), é interessante escolher de forma correta o roteamento mais apropriado para a transmissão do pacote, pois o uso dos recursos da rede será otimizado; além disso, reduz o caminho percorrido pelo pacote. Logo, a latência da rede e o tempo necessário para o pacote chegar ao destino são diretamente influenciados pelo algoritmo de roteamento escolhido.

O objetivo do roteamento é distribuir a circulação de pacotes entre os diversos caminhos disponibilizados pela topologia de rede, evitando situações de deadlock, livelock e starvation. Deadlock refere-se a uma interdependência cíclica dos recursos entre os nodos que

bloqueiam indefinidamente certos caminhos da infraestrutura de comunicação. Livelock

19 definido como uma postergação indefinida de acesso aos recursos de comunicação, ou seja, um canal de saída fica sempre ocupado (DUATO, 1997).

2.1.1.3.Controle de fluxo

O controle de fluxo determina a alocação de canais e buffers para os pacotes que circulam na rede em chip. Para diminuir os requisitos de memorização e a latência da NoC é interessante escolher o mecanismo de controle de fluxo mais apropriado.

A utilização de buffers nos canais de entrada para armazenar os pacotes é a forma mais comum de controle de fluxo, assegurando que os pacotes não sejam rejeitados e privando que eles sejam retransmitidos, reduzindo a disputa pelos roteadores ou trafego da rede. Esta técnica ocasiona a otimização no uso dos recursos da rede.

Os tipos de controle de fluxo mais utilizados existentes na literatura são: handshake,

controle baseado em canais virtuais e controle baseado em créditos (ZEFERINO, 2003). No mecanismo handshake, o controle define quando um pacote pode ser armazenado nos buffers,

sem verificar o espaço disponível do receptor. Um sinal de ack é enviado do receptor para o

emissor, caso tenha espaço disponível para armazenamento do pacote nos buffers do roteador

receptor. Mas, se não houver buffers disponíveis no roteador, ele envia um sinal nack para o

roteador que emitiu o pacote. O controle de fluxo baseado em canais virtuais realizar a repartição do buffer de entrada dos roteadores em filas independentes, mas com tamanhos

menores, formando os canais virtuais. Tal mecanismo, tenta resolver os problemas de

deadlock das redes em chip. No controle baseado em créditos o transmissor recebe do

receptor a quantidade de espaço disponível no buffer de entrada, só assim, o transmissor sabe

a quantidade de créditos estão disponíveis para envio de pacotes. 2.1.1.4.Chaveamento

O chaveamento é responsável por determinar como e quando um canal de entrada é conectado a um canal de saída escolhido pelo algoritmo de roteamento. Antes de explicar os tipos de chaveamentos, é interessante esclarecer que as mensagens que circulam nas redes em chip, são quebradas em pacotes, e que cada pacote é dividido em pedaços menores, chamados de flits, do inglês flow control unit. Todo flit é constituído por um ou mais phits, onde cada phit é do tamanho da largura do canal físico de dados. A organização da mensagem pode ser

melhor entendida pela FIGURA 4.

20 Figura 4. Composição de uma mensagem: pacotes; flit; phits.

Fonte: MATOS, 2010.

O chaveamento por pacote é baseado na divisão das mensagens em pacotes, onde a alocação de canais é feita de forma dinâmica, na medida em que o pacote for percorrendo até o seu destino. Os principais métodos de chaveamento por pacotes são: store-and-forward, virtual-cut-through e wormhole (RIJPKEMA, 2001). O mecanismo armazena e repassa (store-and-foward) geralmente é usado quando as mensagens são frequentes e pequenas, pois

cada pacote designa o percurso preciso até o roteador receptor usando as informações de roteamento contidas no seu cabeçalho.

No tipo de chaveamento transpasse virtual (virtual cut-through) o pacote será enviado

no momento em que o canal de comunicação pelo qual o mensagem será transportada ficar acessível para receber o pacote, e assim, a latência da comunicação será reduzida. O tamanho do buffer deve ser, no pior caso, dimensionado para suportar um pacote inteiro. Uma variação do chaveamento virtual cut-through, é o chaveamento por pacote wormhole que tem como

característica principal diminuir o tamanho do buffer necessário para suportar pacotes

bloqueados na rede. Nas redes baseadas nesta técnica, os pacotes são divididos em flits e um

canal só é liberado depois que todos os flits que formam o pacote passarem pelo canal de

comunicação. 2.1.1.5.Arbitragem

O mecanismo de arbitragem é responsável por controlar as disputas por uma porta de saída, ou seja, define qual canal de entrada pode usar um canal de saída específico. Tal mecanismo resolve esses problemas para que não ocorram situações de starvation. A

arbitragem pode ser distribuída ou centralizada, mostrada na FIGURA 5.

21

buffers que concorrem pelo canal de saída .

Figura 5. Abordagens para implementação de árbitros: (a) centralizada; (b) distribuída. Fonte: ZEFERINO, 2003.

2.1.1.6.Memorização

É o mecanismo de filas utilizado para armazenar os pacotes designados aos canais de saída que já fizeram solicitações por outro pacote, e por causa disso, estão bloqueados na rede. Existem diversas estratégias de memorização, da mais simples (buffer FIFO) às mais

complexas como SAFC (Statically Allocated Fully Connected), SAMQ (Statically Allocated Multi-Queue) e DAMQ (Dinamically Allocated Multi-Queue). As alternativas de

memorização apresentadas aqui são encontradas em (TAMIR, 1992), onde é feita uma comparação entre elas.

Figura 6. Estratégias de memorização utilizando rotador com quatro buffers: (a) SAFC; (b) SAMQ; (c) DAMQ.

22 2.1.2 Vantagens e Desvantagens das NoCs

A cada dia, as redes em chip estão se tornando um dos mais promissores meios de interconexões chaveadas dentro do chip. E tem como principais vantagens com relação a barramentos: desempenho constante do relógio com o aumento de núcleos do sistema (GERRIER; GREINER, 2000); aumento de reuso tanto dos núcleos como da plataforma de comunicação; largura de banda escalável; canais de comunicação em forma de pipeline;

arbitragem distribuída. A circulação dos pacotes ou dados é de responsabilidade destas redes de comunicação e, portanto, tem a capacidade de retratar um gargalo ou o forte diferencial de desempenho entre as propostas de arquiteturas de processadores.

Essas redes possibilitam a estruturação e o gerenciamento dos fios em tecnologias submicrônicas, ou seja, são utilizados fios mais curtos, ponto a ponto e com uma menor capacitância parasita (CALAZANS, 2007) e seu compartilhamento possibilita sua utilização de maneira mais eficiente. Outra vantagem, é que ela permite a reusabilidade dando à possibilidade de se aproveitar a mesma estrutura de comunicação em aplicações distintas.

Porém, a utilização de NoCs apresenta algumas desvantagens (GERRIER; GREINER, 2000): em relação aos barramentos oferece um considerável consumo de área de silício, possui maior complexidade de projeto e o elevado tempo para transmissão de pacotes causado por contenções da rede, podendo aumentar a latência.

2.2.

REDE IPNOSYS

A rede IPNoSys (FERNANDES, OLIVEIRA et al., 2008) é um exemplo de NoC, que oferece um novo modelo arquitetural, onde o processamento das instruções que compõem as aplicações é realizado durante o roteamento dos pacotes. Percebe-se que essa arquitetura, é utilizada como sistema de processamento, além da capacidade de interconexão comum nas redes em chip convencionais.

Para que tais contribuições funcionem, a rede IPNoSys tem características especificas como: a inclusão de uma ULA em cada processador da rede chamados de Unidades de Acesso a Memória (MAU – Memory Access Unit); os roteadores tornaram-se Unidades de

Processamento e Roteamento (RPU – Routing and Processing Unit); os dados e instruções

23 Figura 7. Arquitetura IPNoSys

Fonte: ARAÚJO, 2012.

A rede IPNoSys é configurada com topologia Grelha 2-D de dimensão quadrada, possui dois canais virtuais, roteamento do tipo XY, memorização na entrada, controle de fluxo baseado em créditos e arbitragem distribuída. Tal rede combina o chaveamento VCT com o wormhole. Suas aplicações precisam estar descritas em formato de pacotes, e durante o

trajeto entre a origem e o destino não é preciso usar os processadores comum nos nós da NoC, já que as aplicações serão executadas de roteador em roteador.

Para tanto, foi criado um algoritmo chamado por spiral complement, possibilitando o

roteamento de todas as instruções existentes nos pacotes. A utilização desse algoritmo pode ajudar a resolver grandes desafios do projeto de sistemas integrados em chip. As próximas seções apresentam as estruturas dos elementos arquiteturais (MAU e RPU), algoritmo spiral complement, e o formato do pacote.

2.2.1

Elementos Arquiteturais

2.2.1.1.

24 Figura 8. MAU na Arquitetura IPNoSys

FONTE: ARAÚJO, 2012.

As MAUs, além de injetar os pacotes na rede para iniciar a execução das aplicações, são também, responsáveis pelo estabelecimento da comunicação e sincronização dos resultados encontrados após a execução dos pacotes em cada RPU. A MAU é o único elemento da arquitetura que tem acesso a memória, possibilitando a leitura e escrita de dados que estão armazenados na mesma.

2.2.1.2.

A unidade de roteamento e processamento (RPU) é cada nodo da rede IPNoSys, tem como objetivos, o processamento e encaminhamento dos pacotes para as próximas RPUs. A execução pela RPU, das instruções contidas no inicio do pacote, só é possível quando as aplicações estiverem no formato de pacote.

25 A RPU possui uma estrutura composta por: uma ULA (Unidade Lógica e Aritmética), uma SU (Unidade de Sincronismo), buffers nas entradas, um crossbar e árbitros nas saídas

Como ilustrado na Figura 9. A execução das instruções contidas nos pacotes é realizada pela ULA. A Unidade de Sincronismo produz um pacote de controle, com a instrução encaminhada pelo árbitro. Em seguida, o pacote de controle gerado pela SU, é encaminhado para a MAU que executa a instrução por meio do seu canal virtual.

Os buffers estão localizados nas 5 portas de entrada da RPU, e fazem memorização do

tipo FIFO. O crrossbar tem a função de chavear o pacote da porta de entrada para a porta de

saída do RPU. O domínio das solicitações e entrega dos dados dos canais de saída para MAC ou para ULA, é feita pelos árbitros de saída.

Figura 9. RPU na Arquitetura IPNoSys Fonte: ARAÚJO, 2012.

2.2.1.3.

A

O algoritmo de roteamento Spiral Complement foi desenvolvido para a rede IPNoSys,

baseado no padrão de tráfego complement e no roteamento XY. Admite a execução de

aplicações de qualquer tamanho, pois o algoritmo foi criado para rotear pacotes enquanto tiver instruções para serem executadas.

Segundo (FERNANDES, OLIVEIRA et al., 2008), é possível injetar na rede pacotes por meio dos quatro cantos da rede. A Figura 10, apresenta os caminhos feitos por pacotes injetados simultaneamente pelas quatro MAUs,o spiral complement, permite que um mesmo

26 Figura 10.Spiral Complement: (a) 1a. espiral; (b) 2a. espiral; (c) 3a. espiral (d) 4a. espiral.

FONTE: ARAUJO, 2008

Para descobrir o destino do pacote que foi injetado por uma das MAUs que estão localizadas em um dos cantos na rede, é preciso saber a localização da sua origem para depois fazer seu complemento, dessa forma, o destino inicial é encontrado. Se o pacote que estava sendo roteado chegar ao destino, e ainda, existir instruções nele, um novo cálculo para encontrar o próximo destino deve ser feito. O roteamento do pacote termina quando o número de instruções contidas no pacote for igual à zero, ou seja, quando não tiver no pacote instruções a serem executadas.

A utilização deste algoritmo proporciona um avanço do paralelismo, já que, permite o roteamento e execução de até 4 pacotes no mesmo instante na rede, e suas instruções são executadas de acordo com a disponibilidade dos operandos. Além disso, diminui o agrupamento de dados no centro da rede, conseguindo difundir o tráfego dos pacotes por toda rede IPNoSys.

2.2.1.4.

A rede IPNoSys utiliza um formato de pacote baseado no pacote desenvolvido para a

27 indispensáveis, devido a rede IPNoSys utilizar o algoritmo Spiral Complement e a

modificação do formato do pacote com as instruções da aplicação.

Cada pacote transportar instruções que serão executadas pelas RPUs por onde o pacote passar. Internamente, o pacote apresenta os seguintes tipos de palavras: cabeçalho, instrução, operandos e fim de pacote. A descrição completa dos campos de cada palavra pode ser encontrada em (ARAUJO, 2008).

Figura 11. Formato do pacote da rede IPNoSys Fonte: ARAÚJO, 2008

Em cada palavra, os 32 bits de largura são utilizados para armazenar informações sobre as RPUs, os números dos pacotes, e sobre a aplicação (instruções, operando e resultados), de acordo com seu tipo. Antes dos 32 bits de largura da palavra, são utilizados 4 bits de controle que especifica o tipo de palavra que estar sendo transportada.

28 A arquitetura da IPNoSys possui modelo de execução compatível com modelos de computação orientados à dados (como data flow), uma vez que os dados trafegam junto com

as instruções em pacotes dedicados à execução de operações. Seus roteadores são compostos por uma unidade lógica e aritmética e uma unidade de sincronização, enquanto que os núcleos de processamento foram substituídos por núcleos de acesso à memória. Utiliza-se um modelo de computação baseado em passagem de pacotes entre os roteadores, caracterizando um

pipeline e explorando o paralelismo das transmissões. Portanto, a alternativa apresentada pela

IPNoSys para aumentar o desempenho, ocorre através do processamento de instruções da aplicação nos roteadores da NoC.

De acordo com os resultados, a rede IPNoSys permite um aumento de desempenho na execução das aplicações, pois o processamento das instruções ocorre durante o deslocamento do pacote da origem até o destino. Ressalta-se ainda, que ao executar aplicações que tratam ocorrências de deadlock, é possível verificar a aceleração na execução das aplicações, pois

seu algoritmo de roteamento previne a interrupção da transmissão e do processamento dos pacotes pela rede.

Na rede IPNoSys, é possível implementar a adição de ponto flutuante baseada no padrão IEEE 754, permitindo observar e avaliar casos onde serão utilizados rotinas conjunto de pacotes (software) para execução de uma instrução que não existe implementação especifica no hardware. Com isso, todas as vezes que existir instruções de ponto flutuante nas aplicações, o sistema suportará esse tipo de instrução por meio da execução das rotinas de tratamento, e não será necessário inserir na rede IPNoSys, uma unidade aritmética de ponto flutuante em hardware.

Além disso, Araujo (ARAUJO, 2008) implementou a Transformada Discreta do Cosseno (DCT – Discrete Cosine Transform) no sistema IPNoSys para verificar o

comportamento da arquitetura, e em seguida, realizou comparações de desempenho com a plataforma STORM. Desse experimento, pode-se observar que o sistema IPNoSys oferece um aumento de eficiência em tempo de execução nas diversas condições de paralelismo intrínseco por causa dos múltiplos canais ponto-a-ponto disponíveis na NoC.

A linguagem SystemC (OSCI, 2005) foi utilizada para o desenvolvimento da ferramenta de simulação e validação funcional do sistema IPNoSys. Para tolerar uma maior acuracidade em relação ao modelo real, a ferramenta foi desenvolvida em nível de precisão de

clock. A dependência de dados foi representada por meio do grafo de fluxo de dados utilizado

como linguagem intermediária para a descrição de pacotes.

29 relacionados às redes em chip.

A proposta deste trabalho consiste em analisar o comportamento de execução de aplicações orientadas a dados, na arquitetura da rede IPNoSys, indicando modificações na sua estrutura e organização, visando, torná-la compatível com restrições de projeto como desempenho.

Inicialmente, foi feito um estudo de arquiteturas de NoCs existentes e se observou que a rede IPNoSys apresenta diversas características, como: a execução de aplicações em paralelo por meio da injeção concorrente de pacotes, reduzindo o tempo de execução, em comparação com outras plataformas e tratamento de deadlocks.

Considerando-se as características anteriormente comentadas, essa arquitetura pode ser favorável para a execução de aplicações orientadas a dados.

Partindo da rede IPNoSys (FERNANDES, OLIVEIRA et al., 2008) e aplicações orientadas a dados, será interessante analisar a execução desses algoritmos na rede IPNoSys, investigando as vantagens e desvantagens dessa rede.

Como a rede IPNoSys apresenta um novo paradigma de programabilidade, é necessário desenvolver as aplicações em um conjunto de pacotes com operações e dados. Nessa metodologia, a linguagem intermediaria empregada é o grafo de fluxo de dados da aplicação, onde é explicitado o paralelismo e a dependência de dados da aplicação. Em seguida, é utilizada a linguagem de descrição de pacotes, que a partir do grafo, gera os pacotes propriamente ditos.

Pode-se perceber que por meio de estudos e experimentos realizados com a rede IPNoSys, a mesma tem-se mostrado um importante e eficiente sistema integrado baseado em NoCs. Resultados têm mostrado a aceleração no tempo de execução das aplicações, devido à possibilidade de se explorar paralelismo entre as operações (ARAUJO, 2008).

30

3.

ESTADO DA ARTE

Neste capítulo, serão estudados os conceitos relacionados ao estado da arte do trabalho proposto, mais especificamente o modelo de computação baseado em fluxo de dados, as arquiteturas com suas varações, e as aplicações do tipo dataflow, que serão utilizadas no

trabalho.

3.1.

MODELO DE COMPUTAÇÃO BASEADO EM FLUXO DE

DADOS

Um modelo de computação (MoC) é uma formulação que possibilita expressar a dinâmica da computação dos dados de um sistema. Os modelos podem abranger os conceitos de dependência, concorrência e o tempo parcial ou completo do sistema.

Em geral, entende-se MoC como o modelo para a representação do tempo e da semântica de comunicação e sincronização entre as entidades comportamentais de um sistema, tais como: processos, funções, operações lógicas e/ou aritméticas, estados e etc.

Somente assumindo certo modelo de computação é possível analisar os recursos computacionais requeridos, como tempo de execução e espaço de armazenamento, ou discutir as limitações dos algoritmos. Alguns exemplos de modelos de computação estabelecidos na literatura técnica são: Máquina de Turing, Redes de Processos Kahn, Redes Petri e o Modelo baseado em fluxo de dados.

Como o objetivo do trabalho é estudar os diferentes comportamentos do modelo data flow, e apresentar uma proposta de uma arquitetura IPNoSys baseada em fluxo de dados,

abaixo serão apenas definidas e classificadas as principais variações que constituem o modelo de computação baseado em fluxo de dados.

O modelo baseado em fluxo de dados foi apresentado em meados da década de 70 por Dennis, e desde então, ele tem sido tema de intensa pesquisa. Esse interesse deve-se principalmente, à facilidade com que o paralelismo existente nas aplicações pode ser aproveitado pelo modelo (DENNIS, 1998). No inicio dos anos 80, houve um enorme interesse pelo modelo em função do alto paralelismo apresentado, surgindo diversos projetos, como:

Manchester Data Flow Machine (MDFM) da Universidade de Manchester (GURD, 85), o

projeto Sigma-1 no Japão (SHIMADA, 86) (HIRAKI, 87), a MIT Tagged Token Architecture

31 O interesse ao modelo baseado em fluxo de dados ressurgiu no início da década de 90, pois foi percebido que os problemas anteriormente detectados, ou são passiveis de solução com as novas tecnologias, ou são inerentes ao processamento paralelo. Vários projetos de pesquisa surgiram, apresentando algumas modificações visando sanar os problemas apresentados anteriormente como: a arquitetura EM-X/4 (YAMAGUCHI, 91) que surgiu do projeto Sigma-1 e projeto Monsoon (CULLER, 91) que evoluiu da MTTDA.

O modelo baseado em fluxo de dados suporta a exploração de paralelismo de granularidade bastante fina, no nível de instrução. Um programa deixa de ser representado por uma sequencia de instruções com um controle central impondo a ordem da execução, como é feito no modelo von Neumann. Nas arquiteturas baseada em fluxo de dados não existe o

conceito de memória como nas arquiteturas von Neumann. O conceito de memória em

arquitetura von Neumann torna esse modelo sequencial, pois a passagem dos dados entre as

instruções ocorre pelas atualizações em áreas de memória e um ponteiro de instruções é responsável por estabelecer o fluxo de controle de uma instrução para outra. Devido a esse fato, o modelo von Neumann também é chamado de modelo baseado em fluxo de dados de

controle ou control flow (TRELEAVEN et al., 1982).

Segundo (VEEN, 1986) no modelo baseado em fluxo de dados não existe o conceito de armazenamento de dados em memória. Os dados são simplesmente produzidos por uma instrução e consumido por outra. A chegada dos dados serve como sinal para habilitar a execução de uma instrução, excluindo a necessidade de controle de fluxo. Cada instrução é considerada como um processo separado e quando a instrução produz dados como resultado, são apresentados ponteiros apontando para todos os seus receptores. Visto que uma instrução em um programa baseado em fluxo de dados somente contem referencias para outras instruções, este programa pode ser visto como um grafo.

O modo de execução do modelo baseado em fluxo de dados comporta-se como um grafo dirigido a dados (data-driven). As operações são atendidas como habilitadas para a

execução com a chegada de todos os dados de entrada. Este tipo de construção exibe todo paralelismo implícito do programa. Nessa notação de grafo, cada nó representa uma operação (instrução) e os arcos que interligam esses nós representam a dependência entre as operações.

Nas arquiteturas baseadas em fluxo de dados, as instruções são conhecidas como nós e os dados como tokens. Um nó emissor é conectado a um nó receptor por um arco e o local no

32 Figura 12. Programa básico na linguagem a fluxo de dados

A FIGURA 12 esboça um grafo a fluxo de dados, composto por quatro nós. Quando há tokens nas entradas dos nós eles podem ser processados e geram um token de saída. Os nós

habilitados podem ser disparos em tempos não especificados, em qualquer ordem ou concorrência. O disparo envolve a retirada dos tokens de entrada e a computação do resultado.

3.1.1 Fluxo de Dados Síncrono

É o modelo de computação onde se determina uma ordem de ativação para o processamento dos dados, garantindo uma sequencia pré-determinada de operações. O controle de dados é completamente previsível em tempo de compilação.

Esse modelo faz uso de bufferização estática, onde cada nodo da aplicação pode iniciar o seu processamento assim que um número suficiente de dados estiver disponível nas suas entradas (chamado também de tokens). Sendo assim, é possível determinar estaticamente os requisitos de buffer (profundidade das FIFOs) necessários para a aplicação.

Dessa forma, o modelo é orientado a dados síncronos. À medida que dados estejam disponíveis as instruções podem ser executadas. Sendo assim, a execução não é feita sequencialmente, mas em função da disponibilidade de dados. Logo, serve para à manipulação de computações regulares que operam em fluxo sequencial e são capazes de determinar a ordem de execução da aplicação.

É muito eficiente e não onera os recursos do sistema com dados extras, tendo em vista que, antes de iniciar a execução em si, uma pré-analise das execuções da aplicação é realizada. E para alcançar uma boa eficiencia, os valores dos dados consumidos e produzidos de cada pacote devem ser constantes e declarados.

É um modelo de computação simples que assegura a computação de cada aplicação na ordem correta. Um pacote consome e produz um número fixo de dados por execuçao. Essa informação estática torna possível a avaliação da execução antes de executar de fato. É um modelo adequado para processamento de sinais, onde o baixo overhead de execução é

33 3.1.2 Fluxo de Dados Assíncrono

Faz uso de buffers ilimitados, onde suas aplicações podem produzir e consumir

números variáveis de tokens. Como a produção e o consumo de tokens podem mudar no

tempo de execução, o modelo não pode ser programado estaticamente.

A comunicação (transmissão das mensagens) ocorre através de canais para comunicar valores de dados entre blocos lógicos de computação.A execução dos dados não são sincronizados por um sinal de clock global, portanto, todos as execuções procedem

concorrentemente.

3.1.3 Fluxo de Dados Dinâmico

A abordagem do modelo baseado em fluxo de dados dinâmico baseia-se na solução

tagged-token do modelo baseado em fluxo de dados tradicional. Onde os tokens transportam,

além do valor de interesse, um tag que os agrega a certo contexto de execução –

caracteristicamente loops, iterações ou chamadas de funções.

Nesse modelo, não há o controle estático e, assim sendo, uma tarefa pode mudar a quantidade de informação produzida ou consumida a cada execução. É indicado para aplicações que utilizam no seu fluxo de execução, laços, ramificações ou outras estruturas de controle. Em geral, o modelo DDF (Dinamic Data Flow) é uma ótima escolha para se

gerenciar fluxo de execução que contenham o tipo de estrutura if-then-else, onde a interação

depende dos dados ou que exista recursividade.

O modelo baseado em fluxo de dados dinâmico admite que se tenham vários dados, não apenas um, em cada arco. Na sua implementação é possível que novas instâncias dos operadores sejam originadas para cada dado que vai chegando ao arco. Assim, é aceitável que diversas instâncias de um operador sejam geradas.

Conclui-se que o modelo fluxo de dados dinâmico apresenta uma lógica bastante complexa, com computação paralela e sua execução é bem distribuída.

3.2.

APLICAÇÕES DATAFLOW

34 O modelo de computação baseado em fluxo de dados sempre despertou interesse na área de pesquisa devido a sua elegância em explorar e simular de forma simples o paralelismo encontrado em tarefas de computação. No passado existiram várias experiências de se implementar máquinas de propósito geral fundamentadas no modelo. No entanto, as dificuldades em se alcançar uma máquina a fluxo de dados de propósito geral sempre se revelaram grandes (LEE; HURSON, 1993).

Embora as pesquisas não tenham levado a uma arquitetura de propósito geral largamente comercial, o modelo baseado em fluxo de dados é amplo o suficiente para ser aplicado em diversas áreas, como linguagens de programação, no projeto de processadores, processamento digital de sinais e, computação reconfigurável (NAJJAR; LEE; GAO, 1999) (COMPTON; HAUCK, 2002).

Esse modelo foi projetado para a execução de aplicações de fluxo de dados, onde é possível maximizar o fluxo de dados e minimizar a utilização das RPUs. Nesse modelo, é possível atender o desempenho da aplicação e a racionalização da utilização dos recursos, permitindo a execução da aplicação no menor tempo possível.

Então, a aplicação síncrona data flow genérica é a que faz soma sucessivas. Para realização dos testes foram feitas as seguintes variações: diferentes tamanhos, em relação ao número de instruções e de pacotes. Dessa forma, será possível avaliar o desempenho da rede em chip IPNoSys, ao executar experimentos data flow, onde as aplicações utilizam o máximo

do datapath e o mínimo do controle.

Tais variações particulares da aplicação foram necessárias para que fosse possível estimar o desempenho da rede IPNoSys. Essas variações serão apresentadas nos casos a seguir, enquanto os resultados serão mostrados no CAPITULO 4.

Caso 1: Número de instruções por RPU

Neste caso, é possível variar a quantidade de instruções executadas por cada RPU, antes de encaminhar o restante do pacote para a próxima RPU. Esse parâmetro é definido em tempo de compilação das aplicações, possibilitando que cada pacote ou aplicação tenha sua própria quantidade de instruções executadas por RPU. O número de instruções usadas em cada simulação foi de 2, 4, 8,16, 32, 64, 128 e 254.

Caso 2: Número de instruções por pacote

35

Caso 3: Número de pacotes

Este caso, permite avaliar o desempenho da rede IPNoSys, ao variar o número de pacotes executados na rede IPNoSys. O número de pacotes usadas em cada simulação variou de 1 até 4 pacotes.

3.3.

ARQUITETURAS DATAFLOW

São estruturas globais onde se pode encontrar n elementos de processamento (PE),

interconectados por uma rede de interconexão. Em geral, o sistema suporta mecanismos de interconexão pipeline. Assim, em todos os PE existem um mecanismo para disparo de

instruções, que dispara somente aquelas cujos dados (tokens) já estão disponíveis. (SILVA e

LOPES, 2010).

As instruções são armazenadas em memória de programa, e após serem executadas geram novos taggeg tokens, que são transmitidos para outras operações. Percebe-se que essa

estrutura em pipeline permite múltiplos dados fluindo pelos arcos, e múltiplas instruções

sendo executadas em paralelo.

As arquiteturas dataflow podem ser classificadas como estáticas e dinâmicas. Na

arquitetura estática é permitido apenas um dado no grafo dataflow, ocasionando uma grande

dificuldade no gerenciamento dos arcos, já que não é permitido mais que um dado presente no arco, levando a um overhead de comunicação, que mantém apenas um dado em cada arco.As

arquiteturas dinâmicas permitem mais que um dado por arco no grafo dataflow, onde cada

dado recebe um tag, e os dados passam a ser chamados de tagged token. Logo, os dados com

o mesmo tagged token, disparam as instruções em uma máquina dataflow dinâmica.

Na literatura, é possível encontrar diversas referencias de arquiteturas baseada em fluxo de dados como WASMII - What A Steap Machine Is It (LING & AMANO, 1993). Arquitetura que utiliza o conceito de hardware virtual, onde é possível ocorre a execução com

apenas uma ou várias unidades de processamento reconfigurável (RPF), sendo aceitável que vários FPGAs executassem simultaneamente subgrafos, conseguindo assim o paralelismo máximo de máquinas baseadas em fluxo de dados.

Em seguida, foram feitas evoluções sobre o WASMII. (TAKAYAMA et al., 2000), desenvolveu um compilador de linguagem de alto nível para a máquina. Além disso, ele também implementou um algoritmo de escalonamento e particionamento para a arquitetura, prevenindo possíveis deadlock, obtendo melhorias de quase 40% no desempenho.

A arquitetura SEED (Sistema de Escalonamento e Execução Dataflow), consegue

executar e escalonar código com instruções utilizando o modelo baseado em fluxo de dados, conseguindo aproveitar o máximo de paralelismo possível dos programas. Geralmente, as arquiteturas dataflow exploram paralelismo de granularidade fino, mas a arquitetura SEED

36 blocos de dados na arquitetura, atenuando a complexidade estabelecida pelo hardware e o excesso de ocupação da memória (MAGNA, 1997).

Em (SASSATELLI, TORRES et al., 2002), é proposta uma arquitetura que utiliza um

modelo de execução paralela, dinamicamente reconfigurável com granularidade grossa, que tem por objetivo principal acelerar o processamento de aplicações orientadas a dados. A visão geral do sistema é apresentada na Figura 13.

A arquitetura é constituída por 2 camadas e 1 núcleo, denominados como, camada operativa, camada de configuração e núcleo RISC adaptável com um conjunto de instruções dedicado como controlador de configurações. Na parte interna da camada operativa, tem o Dnode, que é componente de granularidade grossa, utilizado para fazer o processamento das instruções, pois é constituído por registradores e ULA. Na camada de configuração, possui uma memória RAM (Random Access Memory), onde armazena todas as configurações dos componentes da arquitetura. Como trabalho futuro, existe a proposta de desenvolver uma ferramenta de compilação eficiente, que será a chave para o processamento de arquiteturas reconfiguráveis.

Figura 13. Visão geral do sistema Fonte: (SASSATELLI, TORRES et al., 2002

Foi proposta por (MADOŠ e BALÁŽ, 2011), uma arquitetura orientada à dados com uma abordagem moderna, a tile computing. Onde, seus componentes de comunicação, são

utilizados para desenvolver arquiteturas com múltiplos chips. Além dos componentes de comunicação, sua estrutura contem diversos elementos de processamento, cada PE com uma unidade de controle e uma ULA, e duas redes: uma para o mapeamento do grafo dataflow, e a

37 A arquitetura (FERLIN, 2008), propõe uma arquitetura paralela reconfigurável orientada a fluxo de dados. Sendo, formada por uma unidade de controle, tendo como principal função controlar os Elementos Processadores (EPs) e diversos EPs que concretizam a execução da operação. Além disso, faz o gerenciamento de caminho de dados que ocorrer entre os EPs. Sua estrutura prevalecer-se dos benefícios alcançados quando é combinada a computação reconfigurável com o processamento paralelo. Já que sua utilização possibilita a aceleração da execução de programas, adequando uma opção de alto desempenho para soluções que antes eram somente em software.

Portanto, já foi apresentado as redes em chips (NoCs), dentre as redes exibidas houve um maior aprofundamento da rede IPNoSys que é o objetivo de estudo. Em seguida, foi estudado sobre o modelo de computação e a arquitetura dataflow. No próximo capítulo, será

proposto uma arquitetura que une tudo que foi estudado antes. Ou seja, vincular aplicações

dataflow e seu modelo de execução na rede IPNoSys Dataflow, assemelhando-se a uma das

38

4.

PROPOSTA DE MODELO DE EXECUÇÃO ORIENTADO A

DADOS PARA REDE IPNOSYS

Nesse capítulo será apresentado uma proposta de uma arquitetura para aumentar o desempenho da rede IPNoSys, através da execução de instruções em paralelo. Sendo possível, devido a rede possui dentro de cada roteador uma ULA, e pelo seu modelo de execução Spiral Complement, que proporcionam um paralelismo em nível de instrução. Para validar essa

proposta serão executas aplicações SDF, já que são compatíveis com esse paralelismo em nível de instrução.

No modelo de execução da rede IPNoSys como concebida originalmente, cada RPU recebe o pacote e verifica se está com o cabeçalho; em caso afirmativo, executa a instrução, caso contrário, apenas retransmite o pacote à próxima RPU.

Para permitir um paralelismo a nível de instrução são necessárias modificações nas RPUs da rede. Essas modificações dizem respeito à maneira como o modelo de execução orientado à dados será implementado, de modo que instruções possam executar em paralelo. O modelo de execução proposto funciona em duas etapas: programação e execução.

Para cada uma das etapas será criado um novo tipo de pacote. Além da mudança no formato do pacote, foram necessárias mudanças na arquitetura da rede, como visto nas próximas seções.

4.1.

FORMATO DOS PACOTES

Como visto, a seção 2.2.1.4 explica o formato geral do pacote original. Nesta seção, será apresentado o que foi modificado desse original, para existir dois pacotes diferentes: um pacote de programação e um pacote de execução.

O pacote original da rede IPNoSys, possui o código da instrução e operandos, e assim, executa as operações sobre os operandos, e os resultados será armazenados para consultado ou serem utilizados, caso seja necessário. O número instruções e de operandos varia, de acordo, com aplicação que o pacote estiver representando, mas o cabeçalho e o terminador é apenas um para todos os pacotes.

4.1.1

Formato do Pacote de Programação

39 Além disso, o identificador da aplicação e do pacote, o endereço da unidade de acesso a memória onde ocorreu a iniciação do programa, a quantidade de instruções que cada RPU executará, e o apontador permanecem no pacote de programação.

A primeira alteração necessária para a correta execução do pacote no modelo de execução proposta, é a troca do bit de controle “o” para “e”, que representa execução, quando estiver ativado. Também, foi preciso retirar a palavra que armazena os dados utilizados como operando das instruções, já que essa etapa será feita a programação da rede IPNoSys com os operadores sendo armazenados na memória de cada RPU.

No pacote de programação que contém as instruções da aplicação, é preciso que se tenha necessariamente um terminador, indicando o fim do pacote, e consequentemente, a pacote termina de programar as RPUs necessárias para executar o pacote com os dados da aplicação corrente.

40

4.1.2

Formato do Pacote de Execução

O pacote de execução não precisará armazenar o número de instruções contidas no pacote, que era um dado necessário para o pacote original. Da primeira palavra do pacote original, só será preciso armazenar o endereço da RPU de origem e de destino, um campo com o re-rotear e outro com tipo de pacote corrente.

Na segunda e na terceira palavra do pacote de execução, todos os campos permanecem iguais ao do pacote original. A principal diferença, é que o formato do pacote de execução possui uma sequencia de dados, sem a necessidade de armazenar as instruções.

Figura 15. Formato do pacote modificado para programação.

41 ativado. Também, foi preciso retirar a palavra onde o controle “i” de instrução está ativo, pois nele os seguintes campos são armazenados: identificador da instrução, número de operandos e resultados, já que essa etapa será feita a execução do pacote com os dados na aplicação.

No pacote de execução que contém os dados da aplicação, o terminador é opcional, pois os dados do pacote podem existir infinitamente. Por exemplo, quando a rede IPNoSys precisar executar aplicações de stream de áudio que esta sempre ligado, assim os dados do

pacote não terminam nunca. Simplesmente, vão existir dados passando pelas instruções contidas nas RPUS da IPNoSys incessantemente.

4.2.

PROGRAMAÇÃO

Na etapa de programação, um novo pacote foi desenvolvido, contendo apenas a sequencia de instruções que a aplicação dataflow vai executar, de modo que, o pacote trafega

pela rede IPNoSys, programando cada RPU. Quando o pacote de instruções chegar nas RPUs, estas não o executam, apenas armazenam com o tipo de instrução que estiver no cabeçalho do pacote. Com isso, as RPUs ficam programadas para executar os dados que chegarem ao pacote de dados.

42 Figura 16. Etapa de Programação da rede IPNoSys Dataflow - Parte1

44 Figura 18. Etapa de Programação da rede IPNoSys Dataflow - Parte3

Quando o pacote de programação chegar ao fim, Figura 18(12º), as 10 RPUs estarão programadas, aguardando o pacote com os dados. Essa etapa será explicada na seção de execução.

4.3.

EXECUÇÃO

45 Figura 19. Etapa de Execução da rede IPNoSys Dataflow – Parte1

46 Figura 20. Etapa de Execução da rede IPNoSys Dataflow – Parte2

47

5.

RESULTADOS

Uma solução para melhorar o desempenho dos processadores é a construção de software e hardware que permitam a exploração da execução de tarefas em paralelo, aumentando o desempenho geral do sistema. Segundo (DUNCAN, 1990), entre as diversas maneiras de se implementar o paralelismo em computadores, as arquiteturas baseadas em fluxo de dados parecem ser uma excelente alternativa para ajudar as arquiteturas usuais em aplicações especificas com processamento intenso de dados.

A IPNoSys proporciona um paralelismo em nível de instrução, pois ela possui vários roteadores com poder de processamento: dentro de cada processador há uma ULA. As aplicações ideais para aproveitar esse paralelismo em nível de instrução, são as aplicações SDF.

Para avaliar a rede IPNoSys foi preciso comparar como seria a execução de uma aplicação SDF com paralelismo em nível de pacotes e como seria sua execução em nível de instruções. Na execução em nível de instrução, as n instruções de uma aplicação executam n

vezes, como se estivessem dentro de um laço.

5.1.

AVALIAÇÃO

As simulações deste trabalho foram realizadas na rede, utilizando o simulador SystemC da rede IPNoSys. Todos os códigos das aplicações foram descritas na Linguagem de Descrição de Pacotes e submetidos ao assembler da IPNoSys. O assembler gerou o código

objeto da aplicação, que foi utilizado como entrada do simulador gerando os resultados. O primeiro experimento apresenta a quantidade de ciclos necessários para executar instruções, variando a quantidade de instruções presente em cada pacote e a quantidade de instruções executadas em cada RPU. Percebe-se nos gráficos das FIGURAS 22 e 23, com relação ao tempo de execução, que o desempenho da aplicação se mantém praticamente constante quando o número de instruções por pacote cresce até 8, independente do número de instruções executadas em cada RPU, e do número de pacotes presente na rede. A partir do número de instruções por pacote com valor 16, o tempo de execução vai crescendo cada vez que o tamanho do pacote é aumentado.

50 O impacto da potência dissipada pode ser verificado nos gráficos das Figuras 24 e 25, variando o número de pacotes que são injetados na rede IPNoSys, a quantidade de instruções executadas em cada RPU e a quantidade de instruções presente nos pacotes. Nas execuções para as versões até 16 instruções por pacotes, a potência é sempre menor que 1, independente do número de pacotes percorrendo a rede e da quantidade de instruções executadas em cada RPU. Logo, quando se tem a mesma configuração, a potência dissipada em todos os testes apresenta crescimento linear.