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

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
Natal/RN
Agosto, 2012
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ósGraduaçã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
Natal/RN
Agosto, 2012
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
RN/UF/BSE-CCET
RN/UF/BSE-CCET
CDU: 004.72
CDU 004:577.2
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.
Aos amigos do LASIC, pela amizade, compreensão e ajuda ao longo do mestrado.
À CAPES, pelo apoio financeiro, que possibilitou meus estudos e pesquisas.
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
paralelo, paralelismo em nível de instruções, aplicações orientadas a dados.
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.
Keywords: Network-on-chip, embedded systems architecture, parallel processing, instruction
level parallelism, data oriented applications.
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 23 – Tempo de Execução da Aplicação SDF: (a) 3 Pacotes; (b) 4 Pacotes.................49
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
Figura 29 – Desempenho estimado para variações da rede com dimensões 6x6....................58
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
VCT
Virtual Cut-Through
Sumário
1. INTRODUÇÃO ..................................................................................................... 13
1.1. OBJETIVOS ......................................................................................................................... 15
1.2. ESTRUTURA DO TRABALHO ......................................................................................... 15
2. REFERENCIAL TEÓRICO .................................................................................. 16
2.1. REDES EM CHIP .................................................................................................................. 16
2.1.1. Características das Redes em Chip ........................................................................... 16
2.1.1.1.
Topologia ........................................................................................................ 16
2.1.1.2.
Roteamento..................................................................................................... 18
2.1.1.3.
Controle de Fluxo .......................................................................................... 19
2.1.1.4.
Chaveamento .................................................................................................. 19
2.1.1.5.
Arbitragem ..................................................................................................... 20
2.1.1.6.
Memorização .................................................................................................. 21
2.1.2. Vantagens e Desvantagens das NoCs ........................................................................ 22
2.2. REDE IPNOSYS .................................................................................................................... 22
2.2.1. Elementos Arquiteturais ............................................................................................ 23
2.2.1.1.
MAU - Unidade de Acesso a Memória ......................................................... 23
2.2.1.2.
RPU - Unidade de Processamento e Roteamento ....................................... 24
2.2.1.3.
Algoritmo Spiral Complement ....................................................................... 25
2.2.1.4.
Formato do Pacote ......................................................................................... 26
3. ESTADO DA ARTE ............................................................................................. 30
3.1. MODELO DE COMPUTAÇÃO BASEADO EM FLUXO DE DADOS .......................... 30
3.1.1. Fluxo de Dados Síncrono ........................................................................................... 32
3.1.2. Fluxo de Dados Assíncrono........................................................................................ 33
3.1.3. Fluxo de Dados Dinâmico .......................................................................................... 33
3.2. APLICAÇÕES DATAFLOW ................................................................................................ 33
3.3. ARQUITETURAS DATAFLOW .......................................................................................... 35
4. PROPOSTA DE MODELO DE EXECUÇÃO ORIENTADA A DADOS PARA
REDE IPNOSYS .................................................................................................. 38
4.1. FORMATO DOS PACOTES................................................................................................ 38
4.1.1. Formato do pacote de programação ......................................................................... 38
4.1.2. Formato do pacote de execução................................................................................. 40
4.2. PROGRAMAÇÃO................................................................................................................. 41
4.3. EXECUÇÃO........................................................................................................................... 44
5. RESULTADOS .................................................................................................... 47
5.1. AVALIAÇÃO ........................................................................................................................ 47
5.2. RESULTADOS ANALÍTICOS ........................................................................................... 52
6. CONSIDERAÇÕES FINAIS ................................................................................. 59
6.1. CONCLUSÕES ...................................................................................................................... 59
6.2. TRABALHOS FUTUROS .................................................................................................... 60
7. REFERÊNCIAS ................................................................................................... 61
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.
AGARWAL (2009) sintetiza abordagens e estudos descritos em sessenta artigos de
investigação e contribuições na área do NoC, verificando que é preciso um estudo mais
eficiente nas soluções de baixo custo, área e energia para NoCs, permitindo sua aplicação na
13
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.
Disso percebe-se a importância e a necessidade de adequação de uma NoC com
propriedades particulares, como é o caso da rede IPNoSys (ARAUJO, 2008) que se diferencia
14
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
das aplicações e arquiteturas DF. A explicação das modificações que foram feitas na
IPNoSys visando executar aplicações orientada a dados são apresentadas no CAPITULO
4. O CAPITULO 5, apresenta a analise dos resultados obtidos após a proposta de uma
arquitetura IPNoSys baseada em fluxo de dados. O CAPITULO 6 traz a conclusão e os
trabalhos futuros.
15
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.
Nas topologias da classe de redes diretas cada nodo de chaveamento (roteador) possui
um nodo de processamento, núcleo associado, e esse par pode ser visto como um elemento
único dentro do sistema, tipicamente referenciado pela palavra nodo (DUATO, 97). As
topologias de redes diretas mais utilizadas são a grelha 2D, o toróide 2D, o cubo 3D,
hipercubo (cubo 4D), e a totalmente conectada, exemplificados na Figura 1. Conforme é
ilustrado nessa figura, um nodo é composto pelo processador e pelo roteador.
16
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.
Figura 2. Topologias Indiretas: crossbar e rede multiestágio Ômega.
Fonte: REGO, 2006.
17
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
ocorre quando pacotes que estão sendo transmitidos pela infraestrutura de comunicação
jamais atingem o seu destino, ou seja, eles ficam circulando na rede. Starvation pode ser
18
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.
Nas redes em chip, os dois métodos de transferências de pacotes mais utilizados são:
chaveamento por circuito e chaveamento por pacotes. No chaveamento por circuito é preciso
estabelecer um caminho do roteador que emite o pacote até o roteador que recebe o pacote,
para só depois o pacote ser enviado pela rede. Nesta metodologia, os buffers só são utilizados
para controlar o cabeçalho que destina os recursos da rede.
19
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.
Na abordagem centralizada, todas as portas de saída são controladas por um único
módulo roteador, que recebe os cabeçalhos dos pacotes, executa o roteamento e define o canal
de saída a ser usado por cada pacote. Na segunda abordagem, a distribuída, para cada porta do
roteador, o roteamento e a arbitragem são realizados de maneira independente. Ou seja, cada
porta de entrada e de saída, tem um módulo de roteamento e arbitragem, respectivamente. Um
algoritmo, como por exemplo, round robin, é utilizado para definir a prioridade de envio dos
20
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.
Fonte: ZEFERINO, 2003.
21
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
estão em formato de pacote.
22
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. MAU – Unidade de Acesso a Memória
Na rede IPNoSys, os pacotes são injetados pelas MAUs que estão diretamente ligadas
aos módulos de memória, localizadas nos quatro cantos da rede. Sua estrutura interna é
composta por uma unidade de controle, um gerenciador de memória e um gerenciador de
pacotes, como ilustrado na Figura 8. Independentemente das memórias estarem separadas, as
mesmas constituem um ambiente exclusivo de endereçamento (ARAUJO, 2012).
23
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. RPU – Unidade de Processamento e Roteamento
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.
Com isso, o pacote consegue percorrer a rede IPNoSys funcionando como instruções
em séries. As instruções e as operações só são executadas pela rede, no instante, em que
estiverem no cabeçalho do pacote. Em seguida, o resultado obtido da operação corrente é
capaz de ser armazenado no mesmo pacote, servindo de operando para instruções que forem
executadas no futuro. Por fim, a instrução que foi executada é descartada do pacote, e o
restante do pacote é roteado para a RPU seguinte, assim que o canal de transmissão estiver
disponível. (FERNANDES, OLIVEIRA et al., 2008).
24
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. Algoritmo Spiral Complement
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
pacote passe inúmeras vezes pelos mesmos canais, dependendo da dimensão da rede e do
comprimento do pacote.
25
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. Formato do Pacote
A rede IPNoSys utiliza um formato de pacote baseado no pacote desenvolvido para a
rede em chip da plataforma STORM (REGO, 2006). Algumas alterações foram
26
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.
A quantidade de instrução e de operandos contido nos pacotes, estar sujeito a
aplicação que pacote for representar. Apenas o cabeçalho e o terminador são obrigatórios em
todos os pacotes. Na rede IPNoSys, os tipos de pacotes são identificados pelos 2 últimos bits
da primeira palavra do seu cabeçalho, como: controle, regular, interrompido e caller,
representados respectivamente pelos bits 00b, 01b, 10b, 11b (ARAUJO, 2008)..
27
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.
Portanto, é possível observar que a rede IPNoSys apresenta relevantes contribuições,
como: alto desempenho e vazão de pacotes proporcionados pela adaptação da topologia e
redução da influencia da rede de comunicação, conseguindo diminuir os problemas
28
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).
Com base no que foi mencionado anteriormente, entende-se a necessidade de
utilização e verificação da rede IPNoSys, visto que a rede possui características particulares,
como a integração de elementos de processamento nos roteadores da rede, bem como a sua
alta capacidade de paralelismo. Com isso, as tarefas desse trabalho visam a busca por
resultados significativos na execução de aplicações orientadas a dados.
29
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
(MTTDA) do MIT (ARVIND, 90). No final da década de 80, o interesse pelo modelo foi
reduzido, pois a viabilidade do modelo foi provada durante o desenvolvimento do projeto,
mas foram identificados vários problemas, comprometendo o desempenho das arquiteturas em
questão.
30
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
qual o arco entra no nó é conhecido como porta de entrada. A execução de uma instrução é
chamada de disparo do nó, podendo ocorrer, apenas se o nó estiver habilitado, utilizando uma
regra de habilitação. O termino de execução de uma operação libera valores ou decisões para
os nós do grafo, cuja execução depende deles. A FIGURA 12 apresenta um exemplo de um
programa na linguagem a fluxo de dados.
31
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 é
imperativo.
32
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
Descrever aplicações de acordo com um modelo de computação beneficia a aquisição
de resultados que atendam os objetivos desejados, já que suas informações podem ser
exatamente as suficientes e necessárias para uma dada aplicação. Como consequência da
especificidade dos modelos de computação, as seguintes vantagens são decorrentes: menor
área necessária para armazenar as informações que representam a aplicação; maior velocidade
e menor complexidade dos algoritmos que tratam os modelos.
33
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
Este caso, permite avaliar o desempenho da rede IPNoSys, ao variar o número de
instruções executadas por pacote. O número de instruções usados em cada pacote para a
simulação foi de 2, 4, 8,16, 32, 64, 128 e 254.
34
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
explora o paralelismo de granularidade mais grossa com o intuito de diminuir o tráfego dos
35
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
outra, para a comunicação local.
36
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
arquiteturas apresentadas anteriormente.
37
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
O formato do pacote de programação possui uma sequencia de identificadores de
instruções. O pacote continuará armazenando o endereço da RPU de origem e de destino, e o
número de instruções contidas no pacote. Caso seja necessário, um novo endereço de destino
será calculado utilizando os bits do re-rotear. E também o tipo de pacote que está trafegando
pela rede.
38
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.
Figura 14. Formato do pacote modificado para programação.
39
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.
Então, a primeira alteração que precisa se feita é a mesma do pacote de programação,
onde ocorre a troca do bit de controle “o” para “e”, que representa execução, quando estiver
40
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.
Supondo que uma aplicação tenha 10 instruções, e para executar essa aplicação será
necessário injetar o pacote com as operações dessas instruções. Na Figura 16(2º) o pacote é
injetado inicialmente no canto superior esquerdo, sua primeira instrução vai programar a 1ª
RPU, identificou que é uma operação de subtração, Figura16(3º). Então, programa na
memória da RPU, que ela deve executar operações de subtração. Depois, descarta a instrução
do pacote, e encaminha o pacote para a próxima instrução.
41
Figura 16. Etapa de Programação da rede IPNoSys Dataflow - Parte1
A Figura16(4º), mostra que a 2ª RPU vai executar operações de soma, pois a instrução
do pacote de programação tinha o operando para realizar adição. Em seguida, retira a
instrução corrente, e encaminha o pacote para configurar a próxima RPU. Todo o processo de
programação da rede IPNoSys para conseguir executar a aplicação com 10 instruções é
apresentado nas Figuras 16, 17 e 18.
42
Figura 17. Etapa de Programação da rede IPNoSys Dataflow - Parte2
43
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
Na etapa de execução, um novo pacote foi desenvolvido, contendo apenas os dados
das instruções que a rede IPNoSys dataflow vai executar, já que as RPUs necessárias para
execução da aplicação já estão programadas, aguardando pelos dados. A Figura 19(1º)
apresenta o pacote de execução sendo injetado, em seguida, Figura 19(2º), os dados são
executados na 1ªRPU, ou seja, os dados são os operandos necessários para ocorre a operação
de subtração que aquela RPU esta programada para executar.
44
Figura 19. Etapa de Execução da rede IPNoSys Dataflow – Parte1
Todo o processo de execução de uma aplicação dataflow com 10 instruções na rede
IPNoSys DataFlow é apresentado nas Figuras 19, 20 e 21. Percebe-se pelas figuras, que cada
dado contido no pacote de execução passa pela RPU sendo executado, utilizando as instruções
contidas na memória de cada RPU, e cada dado é executado 10 vezes, como se fosse um laço
que executa 10 instruções 10 vezes.
45
Figura 20. Etapa de Execução da rede IPNoSys Dataflow – Parte2
Figura 21. Etapa de Execução da rede IPNoSys Dataflow – Parte3
46
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.
Com relação aos resultados apresentados a seguir, o desempenho da rede não aumenta
quando o paralelismo é incrementado. Com o aumento dos pacotes, a quantidade de ciclos
gastos continua constante para a mesma configuração. A performance da rede é estável,
apresentando crescimento de ciclos linear em função da variação de instruções.
47
Figura 22. Tempo de Execução da Aplicação SDF: (a) 1 Pacote; (b) 2 Pacotes
48
Figura 23. Tempo de Execução da Aplicação SDF: (a) 3 Pacotes; (b) 4 Pacotes
49
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.
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
Observa-se que a estimação de potência encontrada nos experimentos acima de 32
instruções tem um aumento proporcionalmente muito mais significativo que aquelas
dissipadas, pelos experimentos com menos de 32 instruções por pacotes.
Percebe-se, também que a potência é praticamente a mesma entre as implementações
sequenciais e entre as paralelas, pois a quantidade de total de potência é determinada pela
potência dissipada nas RPUs, e não apenas pela transmissão do pacote pela rede. E com o
aumento de pacotes, a quantidade de energia gasta não cresce linearmente em função do
número de instruções, em razão do crescimento linear apresentado pelos resultados.
Os resultados serviram para comprovar que a execução localizada aumenta o
desempenho, pois ocorre uma menor comunicação, pois tal procedimento permite que as
próximas instruções continuem sendo executadas na mesmo RPU, enquanto não é permitido
transmitir o pacote. Quando ocorre a execução localizada, a IPNoSys tem a execução dos
pacotes em nível de instrução. Tanto que foi analisado, que ao aumentar o número de
instruções por RPU, ocorre ganho de desempenho, pois existe uma menor quantidade de
comunicação entre os componentes da rede IPNoSys.
Como foi observado que a execução da IPNoSys é sequencial queremos aproveitar o
potencial de paralelismo na rede, para fazer o paralelismo à nível de instrução. Não só a nível
de pacotes como é na original. E para aproveitar o paralelismo da rede IPNoSys e o
paralelismo a nível de execução é interessante que a aplicação seja a SDF. Para comprovar o
ganho de desempenho das aplicações SDF, executadas como paralelismo à nível de instrução,
será feita uma analise, de maneira analítica como equações baseadas na tese de Zeferino
(ZEFERINO, 2003).
5.2 RESULTADOS ANALÍTICOS
Nesta sessão são apresentados modelos analíticos baseados em (ZEFERINO, 2003),
para a estimativa de desempenho de arquiteturas de comunicação para a rede IPNoSys. As
equações foram desenvolvidas para calcular de maneira analítica, latência em redes em chip,
que são quantos ciclos leva para executar instruções dos pacotes.
Tomando como base as equações de (ZEFERINO, 2003), foi possível modificá-la para
medir latência na rede IPNoSys. Ou seja, as equações foram adaptadas para IPNoSys original
com paralelismo à nível de pacotes e a IPNoSys SDF com paralelismo à nível de instruções,
onde elas serão demonstradas e comparadas.
Para obter as equações que propiciam o modelo de latência é preciso avaliar o tempo
de transferência do pacote e o de arbitragem (Ta). A equação da latência, ao transmitir com
um pacote com f flits no barramento é expressa da seguinte maneira:
Tpct,bus = Ta + (Tbus X f)
(7.1)
Considerando que o barramento ajusta um clock para transmitir cada flit de um pacote
52
da IPNoSys, onde sua largura é igual a largura do seu canal de comunicação (Wdata). DUA, 97
apresenta um modelo para a estimativa da latência em NoCs baseadas no chaveamento
wormhole, que foi utilizado para obter um modelo de latência com carga zero para as redes de
interconexão. Onde, a latência alcançada ao transmitir um pacote com f flits entre a fonte e o
destino separados por d enlaces do tipo RPU-RPU com canal de dados igual a Wdata em (7.2).
tpct,wormhole = (tr + ts + tw) x d + max(ts,tw) x [M/Wdata]
(7.2)
Considerando que a primeira expressão é composta pela soma dos clocks de três
tempos (tr, ts e tw) vezes d, com ela é possível calcular a latência para transferir o cabeçalho
do pacote. Onde o primeiro tempo, tr, representa o tempo que o roteador demora para realizar
o escalonamento do pacote. O atraso para transmissão dos pacotes, ocasionado pelos canais
existentes nos roteadores, é dado pelo tempo, ts. O último tempo, tw, associa os atrasos para
transmissão dos pacotes pelos canais de enlaces.
Observa-se em (7.2), uma expressão max(ts,tw) que indica o máximo entre os atrasos
de propagação dos pacotes. O último termo, [M/Wdata], onde M é o tamanho do pacote, que
indica o número de flits do pacote e, W é a largura do canal de comunicação, que é a mesma
quantidade bits que cada flit apresenta.
De acordo, com o algoritmo spiral complement é aceitável alcançar o número de
enlaces, d, desde a fonte até o destino. Então, é necessário adaptar a equação (7.2) para
estimar em alto nível o desempenho em comunicação da rede IPNoSys.
A equação (7.2), será adaptada para a IPNoSys original. De posse da equação adaptada
para IPNoSys original, ela será adaptada para possibilitar a captura do paralelismo à nível de
instrução da IPNoSys SDF, onde será possível obter além do tempo gasto para transmitir o
pacote, o tempo gasto para executar cada instrução contida nos pacotes.
A equação encontrada foi derivada de uma equação que calcula o tempo para
transmitir a mensagem entre fonte e destino, na rede. Como a rede IPNoSys já é também
processamento, no instante em que for adaptada uma equação, o resultado da equação, vai
indicar o tempo necessário para transmissão do pacote e, além disso, indica o tempo da
execução da aplicação, pois ao transmitir a mensagem a aplicação também está sendo
executada.
Na IPNoSys original, o número de enlaces d, é a distancia da origem até o destino que
pode ser encontrado em função do tamanho da rede, do tamanho do pacote e do roteamento
spiral complement, quando ocorre o auto bloqueio e inicio da execução localizada. Com esses
dados, será possível saber em quantas RPUs o pacote vai passar e qual RPU o pacote vai
terminar. Enquanto que o destino na IPNoSys com paralelismo à nível de instrução, é onde
inicia a execução localizada que vai variar de acordo com o tamanho da rede. Nessa forma,
também será encontrado o paralelismo máximo em função do tamanho da rede, pois quando
ocorre o bloqueio a execução fica localizada e não vai existir mais roteadores no caminho, ou
53
seja, não vai existir mais transmissão do pacote entras RPUs. O limite de paralelismo máximo
é alcançado quando não houver mais transmissão dos pacotes pelas RPUs e sua execução
começar a ser localizada.
No flit da IPNoSys tem código de operação e dado, assumindo que o tamanho do flit é
a quantidade de bits do código das operação e dado, que é o tamanho total que é a largura do
canal. Cada flit, que corresponde uma instrução e seus operandos, leva um ciclo para executar.
As duas IPNoSys executam instruções da mesma maneira e o tempo que cada uma leva para
executar cada instrução é o mesmo, a diferença é como o pacote flui pela rede e, apresenta ou
não paralelismo à nível de instrução, pois em vez de ter uma instrução executando em
sequencia, são executados as instruções em paralelo.
Considerando, a mesma configuração da rede IPNoSys que utiliza dimensões 4x4,
devido ao algoritmo de roteamento spiral complement. Para encontrar o número de enlaces,
d, foi determinado que r é o tamanho da rede (ou seja, r = 4), o refinamento na rede inteira
será verificada na equação (7.3). Observa-se que o maior número possível de RPUs que uma
rede 4x4 permite pode ser encontrado pela equação abaixo.
despiral = (1 x r + (2 x (r -1)) + (4 x (r - 2)) + (4 x (r - 3)))
(7.3)
A Figura 26 ilustra como foi feita a equação que verifica a quantidade máxima de
RPUs que o pacote percorre para completar todo o espiral da rede com topologia 4x4.
A equação (7.3) foi adaptada para obter a equação (7.4), onde é calculado o número
mínimo de RPUs que um pacote pode percorrer para que já inicie a execução localizada, onde
ocorre o bloqueio da rede por ele mesmo. Observa-se na FIGURA 27 que o d, em situações
em que ocorre bloqueio, é igual a quantidade de RPUs percorridos até ele se bloquear.
dbloqueio = (1 x r + (2 x (r -1)) + (3 x (r -2)))
(7.4)
Em situações onde a quantidade de flits do pacote for menor que dbloqueio, o valor de d
vai ser a quantidade de flits do pacote, ou seja, podendo ser encontrado por [M/Wdata], onde
M é o tamanho do pacote e, W é a largura do canal de comunicação, que a mesma quantidade
bits que cada flit apresenta.
Como se quer comparar o paralelismo original da IPNoSys, que é a nível de pacotes
com o paralelismo à nível de instrução, a utilização de apenas um pacote já é o suficiente para
analisar o seu auto bloqueio.
A equação utilizada para encontrar o tempo de execução do pacote na IPNoSys original
(7.5) e na IPNoSys Data Flow (7.6) são as seguintes:
t = [((tr + ts + tw) * D + (max(ts,tw)))] * ((M/W) -1)
t = D + (D -1)
(7.5)
(7.6)
54
Figura 26. Quantidade de RPUs percorrido no Spiral Complement
Os resultados que serão apresentados a seguir demonstram o ganho de desempenho da
IPNoSys Data Flow devido ao paralelismo à nível de instrução obtido, permitindo que uma
instrução possa ser executada várias vezes, apenas seguindo o caminho de execução. Ao
contrário, da IPNoSys original, onde uma instrução só consegue ser executada várias vezes, se
ela for várias vezes reinjetada.
55
Figura 27. Roteamento com bloqueio da rede
A FIGURA 28 mostra o gráfico dos resultados analíticos de uma aplicação SDF,
executando na IPNoSys original e a mesma aplicação, executando na IPNoSys com
paralelismo à nível de instrução. No eixo vertical à esquerda, é mostrado o número de ciclos
para a entrega dos pacotes e, o eixo horizontal apresenta o número de instruções contida em
cada pacote.
56
Figura 28. Desempenho estimado para variações da Rede IPNoSys 4x4
Nota-se, que na IPNoSys Data Flow é consumido menos ciclos para a execução de
todas as instruções, independente da quantidade de instruções contidas no pacote. Para
obtenção desse gráfico, os parâmetros utilizados foram: tr, ts e tw = 1, Wdata=32 bits e M = 2,
4, 8, 16, 32, 64, 128 e 254 instruções por pacotes.
No gráfico da figura 28, é possível verificar que foram gastos mais ciclos na IPNoSys
original, do que na IPNoSys dataflow para executar a mesma quantidade de instruções, isso
ocorre porque o modelo de execução da IPNoSys dataflow utiliza o paralelismo a nível de
instruções, onde as instruções são executadas em paralelo, como se fosse um pipeline.
Enquanto, as instruções na IPNoSys original apresenta um modelo de execução, onde as
instruções são executadas de maneira sequencial, provocando um gasto enorme de tempo para
executar a mesma quantidade de instruções.
Considerando, a configuração da rede IPNoSys que utiliza dimensões 6x6. Para
encontrar o número de enlaces, d, foi determinado que r é o tamanho da rede (ou seja, r = 6), o
refinamento na rede inteira será verificada na equação (7.7). Observa-se que o maior número
possível de RPUs que uma rede 6x6 permite pode ser encontrado pela equação abaixo.
despiral = (1 x r + (2 x (r - 1)) + (4 x (r - 2)) + (4 x (r - 3)) + (4 x (r - 4 )) + (4 x (r - 5))) (7.7)
Para a rede em chip com topologia 6x6, o d para situações em que ocorre bloqueio é
igual a quantidade de RPUs percorridos até ele se bloquear. A mesma equação apresentada
em (7.4) é utilizada, a diferença que o valor de r, não é mais 4, e sim, 6. Os resultados
57
analíticos da comparação das estimativas de latência para as redes IPNoSys Original e Data
Flow são mostrados na FIGURA 29.
Figura 29. Desempenho estimado para variações da Rede IPNoSys 6x6
Segundo as equações 7.5 e 7.6 que foram mostradas anteriormente, foi possível
descobrir o tempo gasto para um pacote ser executado na IPNoSys original (7.5) e na
IPNoSys Data Flow (7.6). Com isso, pode-se perceber na figura 27 uma comparação entre a
IPNoSys desse modelo de execução que foi proposto, e a IPNoSys original.
Como pode ser observado, ocorreu um ganho de desempenho para IPNoSys dataflow,
independente da quantidade de instruções presente no pacote inserido na rede para execução,
devido a paralelismo baseado em instruções presente na IPNoSys dataflow. Ou seja, se existir
64 instruções no pacote, elas serão executadas em sequencial na IPNoSys original, enquanto
que na IPNoSys dataflow elas será executadas em paralelo, proporcionando uma redução, de
aproximadamente, 10 mil ciclos, como verificado na gráfico da figura 29.
58
6. CONSIDERAÇÕES FINAIS
6.1. CONCLUSÕES
Devido ao surgimento dos processadores com múltiplos núcleos, esforços para tornar
viável o aumento das taxas de desempenho focam em arquiteturas que conseguem explorar o
paralelismo. Como consequência, diversas pesquisas foram feitas para solucionar problemas
derivados da inserção de vários núcleos no único chip. Segundo a literatura, foi preciso
estudar novas abordagens de arquitetura em oposição às soluções tradicionais de
interconexão.
As Networks on Chip tem se apresentado como a principal alternativa de comunicação
dos núcleos de processamento e outros periféricos nos processadores many core, pois
exploram desempenho em um contexto paralelo, com vários núcleos disponíveis. E um dos
principais motivos de queda de desempenho são as próprias redes de interconexão. À medida
que são intensamente usadas, elas causam contenções e atrasos de pacotes, tal latência
acarreta no aumento do tempo necessário para executar uma determinada aplicação. No
mesmo sentido, é preciso que a NoC apresente uma arquitetura e uma largura de banda que
privilegie a vazão de pacotes.
Durante o estudo das arquiteturas de comunicação, observou-se que a rede IPNoSys
apresenta um aumento de desempenho significativo em relações as outras NoCs, devido a
junção das funções de comunicação e processamento em um único sistema. Também foi
realizado um estudo a respeito do contexto do trabalho, com definições e classificações das
principais variações do MoC Data Flow.
Devido as suas propriedades particulares, a rede IPNoSys foi utilizada para executar
aplicações orientadas a dados. Essas aplicações foram escolhidas após um estudo dos
diferentes comportamentos dos modelos de computação a fluxo de dados. Disso, buscou-se
analisar a desempenho mediante a execução de aplicações puramente orientadas a dados.
Os experimentos possuem tamanhos diversificados em relação a quantidade de
instruções e de pacotes, para poder avaliar os fins da computação na rede IPNoSys. Além
dessas alterações, também foram realizados testes variando o número de instruções
executadas em cada RPU.
A modificação da arquitetura da rede IPNoSys foi proposta, através da utilização do
paralelismo à nível de instrução. A modificação foi possível devido à rede possuir vários
roteadores interligados e dentro de cada um deles tem uma ULA para execução das operações
entre os dados das instruções do pacote.
Os testes de simulação de desempenho e potência desenvolvidos neste trabalho
permitiram obtenção de resultados conclusivos a respeito da execução de aplicações orientada
à dados na rede IPNoSys. Foi possível observar com o aumento de pacotes, que a quantidade
de ciclos gastos continua constante para a mesma configuração. O desempenho na rede é
estável, apresentando crescimento de ciclos lineares em função da variação de instruções. A
potência total dissipada em todos os testes apresentou crescimento linear para a mesma
configuração. Logo, com o aumento de pacotes, a quantidade de energia gasta não cresce
59
linearmente em função do número de instruções, pois a execução localizada aumenta o
desempenho devido a uma menor comunicação. Ou seja, foi observado um ganho elevado de
desempenho, pois várias instruções executam em paralelo e quando maior a rede, mais
instruções executam em paralelo, até o limite que o pacote se auto bloqueia devido ao
algoritmo spiral complement.
Deve-se destacar que a comparação do paralelismo original da IPNoSys, que é a nível
de pacotes com o paralelismo à nível de instrução, foi feito por meio da execução de
aplicações com mesma configuração. Verificou-se que o desempenho da execução, nas redes
com dimensões, 4x4 e 6x6 é sempre maior na IPNoSys Data Flow, devido ao seu paralelismo,
que permite que uma instrução seja processada diversas vezes, apenas adotando o caminho de
execução.
6.2. TRABALHOS FUTUROS
Dentre os diversos trabalhos futuros estão: modificação do algoritmo de roteamento, já
que o algoritmo espiral complement, utilizado pela IPNoSys original, apresenta um limite de
paralelismo que é alcançado quando o pacote se alto bloqueia; Uso de canais virtuais na
transmissão de pacotes na IPNoSys SDF; Desenvolvimento de um simulador para testar as
aplicações com fluxo de dados síncrono; Mapear aplicações reais para a rede IPNoSys
original e para a SDF, analisando a viabilidade da rede ao executar as aplicações.
60
7. Referências
AGARWAL A., ISKANDER C. D., R. SHANKAR. Survey of Network on Chip (NoC)
Architectures & Contributions. Journal of Engineering Computing and Architecture,
Volume 3, Issue 1. 2009.
ARAÚJO, S. R. F. Estudo da Viabilidade do Desenvolvimento de Sistemas Integrados
Baseados em Redes em Chip sem Processadores: Sistema IPNoSys. Departamento de
Informática e Matemática Aplicada. vol. Mestre Natal: UFRN, 2008, p. 87.
ARVIND, K. P.; NIKHIL, R. S. Executing a Programo n the MIT Tagged-Token Data
flow Architecture. IEEE Transactions on Computers, 39(3): 300-318, 1990.
BENINI, L.; DE MICHELI, G. Networks on Chips: A New SOC Paradigm. Computer,
v.35, 2002. p.70-78.
BOLOTIN, E. et al. QNoC: QoS Architecture and Design Process for Network on Chip.
Journal of Systems Architecture, v.50, n.2, p. 1-24, 2004.
CARARA, E. A. Uma Exploração Arquitetural de Redes Intra-Chip com Topologia
Malha e Modo de Chaveamento Wormhole. 2004. 65 Trabalho de Conclusão II, Pontifícia
Universidade Católica do Rio Grande do Sul, Porto Alegre.
CALAZANS, N.; MORAES, F.; CARVALHO, E. Heuristics for Dynamic Task Mapping
in NoC-based Heterogeneous MPSoC, IEEE International Workshop on Rapid System
Prototyping, p. 43-50,2007.
COMPTON, K.; HAUCK, S. Reconfigurable Computing: a servey of systems and
sofware. ACM Comput. Surv., ACM, New York, NY, USA, v. 34, n. 2, p.171-210, 2002.
CULLER, D. E. et al. The Explicit Token Store, Journal of Parallel and Distributed
Computing, 1991.
DALLY, W.; TOWLES, B. Principles and Practices of Interconnection Networks. Morgan
Kaufmann Publishers Inc., 2004. ISBN 0122007514.
DENNIS, J. B. Retrospective: a preliminary architecture for a basic data flow processor. In:
25 years of internacional symposia on Computer architecture (selected papers), 1998.
Barcelona, Sapin. ACM. p.2-4.
DUATO, J. et al. Interconnection Networks: An Engineering Approach. IEEE Computer
Society Press, 1997. 515p.
DUNCAN, R. A survey of parallel computer architectures. ACM Computer, v. 23, n. 2, p.
365-396, 1990.
Ferlin, E. P. Arquitetura paralela reconfigurável baseada em fluxo de dados
implementada em FPGA, Tese de Doutorado, Curitiba, UTFPR, 2008
61
FERNANDES, S., et al., IPNoSys: uma nova arquitetura paralela baseada em redes em
chip, Simpósio em Sistemas Computacionais de Alto Desempenho (WSCAD), pp.53-60,
2008.
GERRIER, P.; GREINER A. A Generic Architecture for On-Chip Packet Switched
Interconnections. In DATE’2000. Internacional conference on Application of Concurrency
to System Design. p. 188-189.
HAMMOND, L.; NAYFEH, B. A.; OLUKOTUN, K. A Single-Chip Multiprocessor. IEEE
Computer, v.30, 1997. p.79-85.
HIRAKI, K. et. al. The Sigma-1 Data flow Supercomputer: A Challenge for New
Generation. Journal of Information Processing, Vol.10, No. 4, 1987.
LEE, B.; HURSON, A. R. Issues in Data flow computing. Advances in Computers, v. 37,
p. 285-333, 1993.
LING, X. P. & AMANO, H. Wasmii: a data drivem computer on a virtual hardware. IN
FPGAs for Custom Computinh Machines, 1993. Proceedings. IEEE Workshop on (PP. 3342).
MADOŠ, B.; BALÁŽ, A. Data flow graph mapping techniques of computer architecture
with data driven computation model. In: Applied Machine Intelligence and Informatics
(SAMI), 2011 IEEE 9th International Symposium on, 2011. 27-29 Jan. 2011. p.355-359.
MAGNA, P. Proposta e simulação de uma arquitetura a fluxo de dados d segunda
geração, Tese de Doutorado, USP, 1997.
MATOS, D. S. M. Interfaces Parametrizáveis para Aplicações Interconectadas por uma
Rede-em-Chip, Dissertação de Mestrado, PPGC, UFRGS, 2010.
NAJJAR, W. A.; LEE, E. A.; GAO, G. R. Advances in the Dataflow computational model.
Parallel Comput., Elsevier Science Publishers B. V., Amsterdam, The Netherlands, v. 25, n.
13-14, p. 1907-1929, 1999.
NICOPOULOS, C., PARK, D., KIM, J., VIJAYKRISHNAN, N., YOUSIF, S., DS R.
ViChaR: A Dynamic Virtual Channel Regulator for Network-on-Chip Routers. Int.
Symp. Microarchitecture – MICRO, p.333 – 346, 2006.
OSCI. SystemC, 2005. Disponível em: http://www.systemc.org. Acesso em: 07 abr. 2012
PATT, Y. N. et al. One Billion Transistors, One Uniprocessors, One Chips. IEEE
Computer, v.30, 1997. p.51-57.
REGO, R. S. D. L. S. Projeto e implementação de uma Plataforma MP-SoC usando
SystemC. 2006. 144 Dissertação de Mestrado (Mestrado). Departamento de Informática e
Matemática Aplicada, Universidade Federal do Rio Grande do Norte.
RIJPKEMA, E.; GOOSSENS, K.; WIELAGE, P. Router Architecture for Networks on
Silicon. In: Proceedings of Progress 2001, 2nd Workshop on Embedded Systems, 2001.
Veldhoven, the Netherlands.
62
SASSATELLI, G. et al. Highly scalable dynamically reconfigurable systolic ring-architecture
for DSP applications. In: Design, Automation and Test in Europe Conference and
Exhibition, 2002. Proceedings, 2002. 2002. p.553-558.
SHIMADA. T.; HIRAKI. K; NISHIDA. K.; SEKIGUSHI, S. Evaluation of a Prototype
Dataflo Processor of the Sigma-1 for Scientific Computations. Proceedings of the 13th
International Symposium on Computer Architecture, 226-234, 1986.
STENSGAARD, B.; SPARSO, J. ReNoC: A Network-on-Chip Architecture with
Reconfigurable Topology, Network-on-Chip – NoCs, p. 55 – 64, 2008.
TAKAYMA, A., SHIBATA, Y., IWAI, K., & AMANO, H. Dataflow partitioning and
scheduling algoritms for WASMII, a virtual hardware. In Field-Programmable Logic and
Applications: The Roadmap to Reconfigurable Computing, volume 1896 of Lecture Notes in
Computer Science, pp. 685- 694, 2000.
TAMIR, Y.; FRAZIER, G. L. Dynamically-Allocated Multi-Queue Buffers for VLSI
Communication Switches. IEEE Trans. On Computers, v. 41, n. 6, Jun. 1992. P. 725-737.
TRELEAVEN, P. C.; BROWNBRIDGE, D. R.; HOPKINS, R. P. Data Driven and Demand
Driven Computer Architecture. Computing Surveys, 93-143, 1982.
VEEN, A. H. Dataflow machine architecture. In:ACM Computing urveys, 1986, p. 365396.
YAMAGUCHI, Y. Synchronization Mechanisms of a Highly Parallel Data flow Machine
EM-4. IEICE Transaction, 1991.
ZEFERINO, C. Redes em chip: Arquiteturas e Modelos para Avaliação e Área e
Desempenho. Tese (Doutorado em Ciência da Computação) - Instituto de Informática,
UFRGS, Porto Alegre, 2003.
ZEFERINO, C. A.; SUSIN, A. A. SoCIN: A Parametric and Scalable Network-on-Chip.
In: Symposium on Integrated Circuits and Systems, São Paulo, 2003.
63