1 UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE CENTRO DE CINCIAS EXATAS E DA TERRA DEPARTAMENTO DE INFORMTICA E MATEMTICA APLICADA BACHARELADO EM CINCIA

DA COMPUTAO

Roteamento em Zigue-zague para a plataforma IPNoSys

Marcos Oliveira da Cruz

Natal-RN Junho 2013

2
Marcos Oliveira da Cruz

Roteamento em zigue-zague para a plataforma IPNoSys

Monografia de Graduao apresentada ao Departamento de Informtica e Matemtica Aplicada do Centro de Cincias Exatas e da Terra da Universidade Federal do Rio Grande do Norte como requisito parcial para a obteno do grau de bacharel em Cincia da Computao. Orientador

Prof. Dr. Mrcio Kreutz

UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE - UFRN DEPARTAMENTO DE INFORMTICA E MATEMTICA APLICADA - DIMAP

Natal-RN Junho 2013

3
Monografia de Graduao sob o ttulo Roteamento em Zigue-zague para a plataforma IPNoSys apresentada por Marcos Oliveira da Cruz e aceita pelo Departamento de Informtica e Matemtica Aplicada do Centro de Cincias Exatas e da Terra da Universidade Federal do Rio Grande do Norte, sendo aprovada por todos os membros da banca examinadora abaixo especificada:

__________________________ Prof. Dr. Mrcio Kreutz Orientador Departamento de Informtica e Matemtica Aplicada Universidade Federal do Rio Grande do Norte

__________________________ Prof. Dr. Monica Magalhes Pereira Departamento de Informtica e Matemtica Aplicada Universidade Federal do Rio Grande do Norte

__________________________ Prof. Dr. Edgard de Faria Correa Departamento de Informtica e Matemtica Aplicada Universidade Federal do Rio Grande do Norte

Natal-RN, 19 de Junho de 2013.

Aos meu pais, Francisco e Maria, e minha tia Josefa ( In Memoriam)

Agradecimentos

Agradeo sempre a Deus por me dar o dom da f. Acreditar nele e no seu auxlio em tudo o que empreendemos essencial. Dirijo tambm meu agradecimento aos que me foram presentes durante a execuo desse trabalho e participaram com seu auxlio e suporte: Professor Kreutz, Professor Slvio, Eliselma, Aparecida, Jefferson e Jonathan.

Onde existe uma vontade, existe um caminho Bernard Shawn

Roteamento em Zigue-zague para a plataforma IPNoSys

Autor: Marcos Oliveira da Cruz Orientador: Prof. Dr. Mrcio Kreutz

RESUMO
Com o advento dos processos submicrnicos, a capacidade de integrao de transistores tem atingido nveis que possibilitam a construo de um sistema completo em uma nica pastilha de silcio. Essa crescente complexidade dos circuitos possibilitou o desenvolvimento de arquiteturas de comunicao do tipo redes em chip como alternativa de arquitetura de interconexo para os Sistemas-em-Chip. As redes em chip possuem capacidade de reuso de componentes, paralelismo e escalabilidade. Na literatura, tm-se uma grande quantidade de propostas com diferentes configuraes, entre elas, a rede IPNoSys. A IPNoSys possui uma arquitetura diferenciada que une os conceitos de comunicao e processamento em uma nica estrutura presente na sua composio. O objetivo deste trabalho implementar um novo algoritmo de roteamento para a IPNoSys, efetuar testes e avaliar os resultados comparando-os com os resultados obtidos na IPNoSys original. Uma vez apresentada a plataforma e o background necessrio para sua compreenso, apresentamos um novo modelo de roteamento, o roteamento em ziguezague, que ser comparado nos testes com o modelo original. Os testes implementados nos traro informaes acerca de trs aspectos da arquitetura, a saber, preveno de deadlocks, explorao de paralelismo e o uso de canais virtuais. Palavras-chave: redes em chip, algoritmos de roteamento, canais virtuais.

Zigzag routing for the IPNoSys Platform

Author: Marcos Oliveira da Cruz Advisor: Mrcio Kreutz, PhD

ABSTRACT With the advent of submicronic processes, the ability to integrate transistors have reached levels that enable us to construct an entire system on a single chip. This growing complexity of circuits enabled the development of communication architectures such as networks-on-chip as an alternative interconnection architecture for systems-on-Chip. Networks-on-chip have parallelism, scalability and reusable components. In the literature, there have been a lot of proposals with different settings, including the network IPNoSys. The IPNoSys has a distinctive architecture that gathers the concepts of communication and processing in a single structure present in its composition. This work aims is to implement a new routing algorithm for IPNoSys, perform tests and evaluate the tests results by comparing them with the results obtained in the original IPNoSys. Once presented the platform and the necessary background for your understanding, we present a new model of routing, the zigzag routing, which will be compared on tests to the original model. The tests performed will bring us information on three aspects of the architecture: deadlock prevention, exploitation of parallelism and the use of virtual channels.

Keywords: Networks-on-chip, routing algorithms, virtual channels.

Lista de figuras
2.1. Exemplo de mensagem e topologia bsica de uma NoC ............................................... p. 18 2.2. redes em chip com topologia direta ............................................................................... p. 19 2.3. redes em chip com topologia indireta ............................................................................. p. 20 3.1. Arquitetura IPNoSys ....................................................................................................... p. 25 3.2. Formato dos pacotes ..................................................................................................... p. 25 3.3. Grafo de dependncia de dados e seu pacote correspondente ..................................... p. 30 3.4. Execuo de uma instruo: momento da execuo e aps a execuo com as palavras inseridas no pacote ............................................................................................................... p. 31 3.5. Gramtica da PDL .......................................................................................................... p. 32 3.6. Tokens da PDL ............................................................................................................... p. 32 4.1. Algoritmo para Calcular Novo Endereo no Spiral Complement ................................... p. 34 4.2. Roteamento Spiral complement: (a) 1 espiral; (b) 2 espiral; (c) 3 espiral; (d) 4 Espiral ................................................................................................................................... p. 35 4.3. Situaes de deadlock ................................................................................................... p. 36 4.4. Mquina Dataflow em sua etapa de programao das unidades de processamento .... p. 37 4.5. Mquina Dataflow em sua etapa de execuo das intrues ........................................ p. 38 4.6. Quatro rotas da IPNoSys em Zigue-zague: (a) 1 rota; (b) 2 rota; (c) 3 rota; (d) 4 rota ........................................................................................................................................ p. 39 4.7. Sequncia de rotas na IPNoSys usando o roteamento em Zigue-zague ....................... p. 39 4.8. Algoritmo para clculo do novo endereo no roteamento em Zigue-zague ................... p. 40 5.1. Quantidade de instrues por nodo usando o contador sequencial na IPNoSys com roteamento Spiral complement ............................................................................................. p. 44 5.2. Quantidade de instrues por nodo usando o contador sequencial na IPNoSys com roteamento em zigue-zague ................................................................................................. p. 44 5.3. Relao entre os pacotes do Contador Paralelo ............................................................ p. 45 5.4. Quantidade de instrues por nodo usando o contador paralelo na IPNoSys com roteamento Spiral Complement ............................................................................................. p. 46 5.5. Quantidade de instrues por nodo usando o contador paralelo na IPNoSys com roteamento em Zigue-zague ................................................................................................. p. 46 5.6. Frmula para clculo do desvio padro ......................................................................... p. 47 5.7. Comparao do Tempo de Execuo: Contador Sequencial versus Contador Paralelo na IPNoSys (a) Spiral Complement e (b) zigue-zague .......................................................... p. 48 5.8. Tempo mdio de transmisso em ciclos para os roteamentos (a) Spiral complement e (b) em Zigue-zague para contador sequencial ...................................................................... p. 49 5.9. Tempo mdio de transmisso em ciclos para os roteamentos (a) Spiral complement e (b) em Zigue-zague para contador paralelo .......................................................................... p. 49

10
5.10. Utilizao mdia dos canais para os roteamentos (a) Spiral complement e (b) em Zigue-zague para contador sequencial ................................................................................. p. 51 5.11. Utilizao mdia dos canais para os roteamentos (a) Spiral complement e (b) em Zigue-zague para contador paralelo ..................................................................................... p. 51 5.12. Taxa efetiva de transmisso para os roteamentos (a) Spiral complement e (b) em Zigue-zague para contador sequencial ................................................................................. p. 52 5.13. Taxa efetiva de transmisso para os roteamentos (a) Spiral complement e (b) em Zigue-zague para contador paralelo ..................................................................................... p. 52 5.14. Nmero mximo de instrues executadas em um Nodo para o contador sequencial na IPNoSys Spiral complement .................................................................................................. p. 54 5.15. Nmero mximo de instrues executadas em um Nodo para o contador sequencial na IPNoSys Zigue-zague ........................................................................................................... p. 54 5.16. Nmero mximo de instrues executadas em um Nodo para o contador paralelo na IPNoSys Spiral complement .................................................................................................. p. 55 5.17. Nmero mximo de instrues executadas em um Nodo para o contador paralelo na IPNoSys Zigue-zague ........................................................................................................... p. 56 5.18. Tempo Mdio para transmisso de Palavras para o Contador Sequencial (a) Spiral complement e (b) Zigue-zague ............................................................................................. p. 57 5.19. Tempo Mdio para transmisso de Palavras para o Contador Paralelo (a) Spiral complement e (b) Zigue-zague ............................................................................................. p. 57 5.20. Utilizao Mdia dos Canais para o Contador Sequencial (a) Spiral complement e (b) Zigue-zague ..................................................................................................................... p. 58 5.21. Utilizao Mdia dos Canais para o Contador Paralelo (a) Spiral complement e (b) Zigue-zague ..................................................................................................................... p. 58 5.22. Taxa efetiva de transmisso usando Contador Sequencial (a) Spiral complement e (b) Zigue-zague ..................................................................................................................... p. 58 5.23. Taxa efetiva de transmisso usando Contador Paralelo (a) Spiral complement e (b) Zigue-zague ..................................................................................................................... p. 59 5.24. Tempo de execuo para o Contador Sequencial (a) Spiral complement e (b) Zigue-zague .............................................................................................................................................. p. 59 5.25. Tempo de execuo para o Contador Paralelo (a) Spiral complement e (b) Zigue-zague ............................................................................................................................................... p. 59 5.26. Potncia nos Buffers de entrada usando Contador Sequencial (a) Spiral complement e (b) Zigue-zague ..................................................................................................................... p. 60 5.27. Potncia nos Buffers de entrada usando Contador Paralelo (a) Spiral complement e (b) Zigue-zague ..................................................................................................................... p. 60 5.28. Potncia do rbitros, Contador Sequencial (a) Spiral complement e (b) Zigue-zague . p. 61 5.29. Potncia do rbitros, Contador Paralelo (a) Spiral complement e (b) Zigue-zague ..... p. 61 5.30. Potncia Total, Contador Sequencial (a) Spiral complement e (b) Zigue-zague .......... p. 62

11
5.31. Potncia Total, Contador Paralelo (a) Spiral complement e (b) Zigue-zague ............... p. 62 5.32. 3 canais virtuais, 64 instrues em sequencial ........................................................... p. 63 5.33. 3 canais virtuais, 64 instrues em paralelo ................................................................ p. 64

12

Lista de tabelas
Tabela 2.1 Caractersticas das redes em chip .................................................................... p. 18 Tabela 3.1 Caractersticas da Rede IPNoSys .................................................................... p. 25 Tabela 3.2 Conjunto de instrues IPNoSys ...................................................................... p. 28 Tabela 5.1 Parmetros das simulaes para o Caso de teste N 1 ................................... p. 43 Tabela 5.2 Desvio padro para distribuio de carga na IPNoSys, contador paralelo ....... p. 47 Tabela 5.3 Comparao do Tempo de Execuo: Spiral complement versus Zigue-zague, contador sequencial .............................................................................................................. p. 48 Tabela 5.4 Comparao do Tempo de Execuo: Spiral complement versus Zigue-zague, contador paralelo .................................................................................................................. p. 48 Tabela 5.5 Quantidade mxima de instrues executadas em um Nodo contador sequencial .............................................................................................................. p. 55 Tabela 5.6 Quantidade mxima de instrues executadas em um Nodo contador paralelo .............................................................................................................................................. p. 56 Tabela 5.7 3 canais virtuais, 64 instrues em sequencial mtricas ............................... p. 63 Tabela 5.8 3 canais virtuais, 64 instrues em paralelo mtricas .................................... p. 64

13

Lista de abreviaturas e siglas

abw - average bandwidth (utilizao mdia dos canais) avcpf average cycles per flit (ciclos por flit mdio ) Flit flow control unit IPNoSys Integrated Processing NoC System MAU Memory Access Unit NoC Network on Chip PDL - Package Description Language RPU Routing and processing unit SoC System on Chip thr taxa efetiva de transmisso de dados VCT - Virtual cut-through

14

Sumrio
1. Introduo .......................................................................................................... p. 15 1.1 . Organizao do trabalho ...................................................................... p. 15 2. redes em chip .................................................................................................... p. 16 2.1 . Conceitos bsicos sobre redes em chip ............................................... p. 18 3. A Plataforma IPNoSys ....................................................................................... p. 24 3.1 . A arquitetura IPNoSys .......................................................................... p. 24 3.2 . Modelo de programao ...................................................................... p. 28 4. O Roteamento na IPNoSys ............................................................................... p. 33 4.1 . O roteamento original .......................................................................... p. 33 4.2 . O roteamento em zigue-zague ............................................................. p. 37 5. Experimentos ..................................................................................................... p. 42 5.1 . Caso de teste 1 - Preveno a deadlock ............................................. p. 42 5.2 . Caso de teste 2 Canais virtuais ........................................................ p. 52 6. Consideraes finais ........................................................................................ p. 63 Referncias ............................................................................................................ p. 65 Anexo 1 Tabelas de resultados dos testes........................................................ p. 66

15

Introduo

Os SoC (Systems on Chip) com arquitetura baseada em barramento, apesar de simples, sob o ponto de vista de implementao, apresentam diversas desvantagens [BENINI, 2002]. Para controlar a complexidade de criar chips contendo bilhes de transistores, necessrio separar a comunicao da computao. Assim, as redes em chip (ou Network-on-Chip - NoC) emergem como uma alternativa para interconexes existentes nos chips, onde a abstrao das camadas de protocolos utilizada para modularizar o projeto de comunicao. A possibilidade de explorar paralelismo a nvel de instrues e a possibilidade de trabalhar com modelo de processamento orientado ao fluxo de dados situa as redes em chip como uma soluo para problemas pertinentes classe do processamento paralelo. O objetivo do presente trabalho implementar um novo algoritmo de roteamento para a plataforma simulada em SystemC IPNoSys ( Integrated Processing NoC System) em um modelo de roteamento em zigue-zague, avaliar os resultados e estabelecer um benchmark dos resultados dos experimentos comparativos entre a plataforma original e a plataforma modificada. Pretende-se assim, melhorar alguns aspectos da rede IPNoSys e tambm analisar o impacto desse novo roteamento na arquitetura.

1.1

Organizao do trabalho
Inicia-se o trabalho situando-se dentro do universo das redes em chip, ressaltando

suas caractersticas arquiteturais e elementos constituintes que nos ajudaro a entender a plataforma utilizada. Segue-se apresentando a plataforma IPNoSys, seus componentes arquiteturais e seus modelos de execuo e programao, alm de caracteriz-la com uma rede em chip. O captulo 4 mostra o roteamento original da IPNoSys e tambm o novo roteamento proposto, em Zigue-zague. O captulo 5 apresenta e analisa os resultados de experimentos comparando as duas verses de roteamento para a IPNoSys. Por fim, o trabalho traz suas concluso e consideraes finais.

16

redes em chip

Segundo [ZEFERINO, 2003], a crescente tecnologia aplicada nos processos de desenvolvimento de microchips tem permitido um aumento do nvel de integrao de transistores em uma mesma pastilha de silcio. Essas melhorias na tecnologia tm possibilitado a integrao de mltiplos componentes, como processadores, memrias e microcontroladores, em um nico chip, resultando na integrao de um sistema completo. Esses sistemas so denominados sistemas em chip ou SoCs (Systems-On-Chip). Para que a comunicao ocorra entre os ncleos do sistema, necessria a existncia de uma estrutura eficiente e que permita a interconexo dos ncleos entre si e tambm dos ncleos com os outros dispositivos do chip. Utiliza-se uma estrutura de canais para constituir essa rede de comunicao. Tipicamente, duas abordagens so bem conhecidas: canais ponto a ponto dedicados e canais multiponto compartilhados. Apesar de oferecer o melhor desempenho por oferecer comunicao independente por meio de canais exclusivos, a primeira alternativa esbarra na presso do mercado pela reusabilidade dos componentes. medida em que elementos so acrescentados arquitetura, preciso montar a conexo desses elementos com todos os outros elementos j existentes. A alternativa que utiliza a arquitetura multi-ponto, mais conhecida como barramento, pode ser reutilizada em diferentes sistemas, reduzindo o tempo de projeto, porm, quando o nmero de ncleos elevado, esta no oferece suporte demanda crescente de comunicao. Para minimizar o problema da baixa escalabilidade, as hierarquias de barramentos foram utilizadas com algum xito, entretanto, na era dos SoCs, onde os sistemas podem conter de dezenas a centenas de ncleos independentes, esta soluo ainda no apresenta a escalabilidade desejada. A hierarquia de barramentos no resolve o problema da impossibilidade de reuso, uma hierarquia de barramento sempre uma soluo ad hoc para um sistema especfico. De acordo com [ZEFERINO,2003], as tecnologias de desenvolvimento de semicondutores existentes permitir a integrao de at quatro bilhes de transistores e dezenas a centenas de ncleos em uma mesma pastilha de silcio, o que permitir o desenvolvimento de novas aplicaes nas reas de multimdia, telecomunicaes e eletrnica de consumo. Contudo, enquanto isso abre novas oportunidades de projeto, surgem tambm novas dificuldades com relao especificao, mapeamento e avaliao das opes de projeto, assim como questes associadas s arquiteturas de comunicao.

17
[ZEFERINO, 2003] ainda explica que, no que se refere comunicao, o problema reside no fato de que esses sistemas sero to complexos que inviabilizaro o uso de interconexes dedicadas face s dificuldades envolvidas e falta de reusabilidade dessa abordagem. Por outro lado, os requisitos de desempenho em comunicao, como largura de banda escalvel e paralelismo em comunicao, dificilmente sero atendidos pelas arquiteturas baseadas no barramento. Isso decorre da natureza arquitetural do barramento que impe uma srie de problemas j identificados. Os problemas residem em diversos aspectos da arquitetura. Por utilizar conexes do tipo multiponto, quanto maior for o nmero de ncleos conectados ao barramento, maior ser a sua capacitncia parasita. Assim, o atraso na movimentao de dados ao longo dos fios ir se tornar incrivelmente significativo e limitar o desempenho do sistema. Quanto potncia, o problema que o barramento opera por difuso e cada sinal deve chegar a todos os pontos do barramento, exigindo uma grande quantidade de energia. Alm desses, existem outros problemas, como largura de banda no escalvel e arbitragem centralizada, que dificultaro em muito o uso de barramentos em SoCs complexos [ZEFERINO,2003]. Torna-se clara a necessidade de desenvolvimento de novos sistemas de comunicao que resolvam os problemas acima enumerados. Nesse contexto, a soluo proposta pela comunidade cientfica est no uso de redes de interconexo chaveada, como aquelas encontradas em computadores paralelos. Essas redes tm como vantagens: a largura de banda escalvel, o uso de conexes ponto a ponto curtas e o paralelismo na comunicao, entre outras. Embora tenham como desvantagens maiores custos e latncia na comunicao, esses problemas sero atenuados pela grande disponibilidade de transistores e por solues arquiteturais que permitem reduzir a latncia da rede e seus efeitos no desempenho da aplicao. Essas redes chaveadas, quando aplicadas comunicao intrachip, recebem mltiplas denominaes na literatura: Micronetworks, On-Chip Networks (OCNs) e Networks-on-Chip (NoCs). Contudo, todas elas se referem mesma base arquitetural (redes de interconexo chaveada para computadores paralelos), sendo que o termo Network-on-Chip (rede em chip, em portugus) tem tido a maior aceitao [ZEFERINO, 2003].

18

2.1

Conceitos bsicos sobre redes em chip

Uma rede em chip pode ser definida como um conjunto de roteadores e canais

ponto a ponto que interconectam os ncleos de um sistema integrado de modo a suportar a comunicao entre esses ncleos. Tipicamente, o modelo de comunicao utilizado o da troca de mensagens, sendo que a comunicao entre ncleos feita atravs do envio e recebimento de mensagens de requisio e de resposta. Cada mensagem (Figura. 2.1(a)) constituda por: (i) cabealho, o qual sinaliza o incio da mensagem e inclui informaes necessrias sua transferncia pela rede; (ii) carga til, a qual inclui o contedo da mensagem; e (iii) terminador, o qual sinaliza o final da mensagem e pode ser at a ltima palavra da carga til, desde que haja um bit especial ativado apenas no final das mensagens. [ZEFERINO, 2003].
Figura 2.1 (a) Exemplo de mensagem e (b) topologia bsica de uma NoC

Fonte: [ZEFERINO, 2003]

As redes em chip podem ser caracterizadas segundo alguns aspectos de sua arquitetura. Estes aspectos esto descritos na tabela 2.1:
Tabela 2.1 Caractersticas das redes em chip
Aspecto Topologia Roteamento Descrio Forma como os ncleos esto interligados; nodos e enlaces tipicamente arranjados em forma de grafo Modo como os possveis caminhos so utilizados para que a mensagem chegue ao seu destino. Definido atravs de algoritmo esttica ou dinamicamente. Define o modo de conexo e o momento de conexo entre os nodos. Sincronizao bilateral emissor-receptor. Alocao de canais e buffers para um pacote que trafega dentro da rede. Viabiliza a comunicao. Determina qual canal de entrada pode utilizar um determinado canal de sada do nodo de chaveamento. Determina o esquema de filas utilizado para armazenar uma mensagem bloqueada na rede quando um canal de sada por ela requisitado j est alocado para uma outra mensagem.

Chaveamento Controle de fluxo Arbitragem Memorizao

19
A topologia consiste na estrutura formada pela ligao entre os roteadores. Essa organizao pode ser expressa na forma de um grafo, onde os roteadores correspondem aos vrtices e os canais de comunicao so os arcos [NI, 1993]. Essas topologias podem ser agrupadas em dois grandes grupos: redes diretas e redes indiretas. As redes diretas so caracterizadas pela associao de cada roteador a um ncleo, formando um elemento nico dentro da rede chamado de nodo. Cada nodo ligado ponto a ponto a outros nodos. Se uma mensagem enviada, ela passar por vrios nodos antes de chegar ao seu destino, utilizando para isso o roteador do nodo. Uma rede direta pode ter vrios nveis de conectividade [CARDOZO, 2005]. Dentre as topologias diretas esto: (a) Grelha 2D, (b) Torus 2D, (c) Cubo 3D, (d) Cubo 4D ou Hipercubo e (e) Totalmente Conectada, que so representadas na figura 2.2
Figura 2.2 redes em chip com topologia direta

Fonte: [ARAJO, 2008]

Na topologia direta cada roteador est ligado a um dos ncleos do sistema. Nas topologias indiretas isso no acontece com todos os roteadores, alguns so usados como pontes entre roteadores ligados a ncleos [ARAJO, 2008]. Exemplos de topologias indiretas so (a) crossbar e (b) rede multiestgio mega, apresentadas na Figura 2.3. O algoritmo de roteamento define o modo como as mensagens iro trafegar na rede at alcanar o seu destino. Alm de ter um significativo impacto no desempenho da rede, o modelo de roteamento deve ser bem idealizado para evitar problemas como deadlock e livelock . Existem diversas propostas de algoritmos de roteamento, alguns com um comportamento esttico e outros com um comportamento adaptativo. Estes ltimos

20
constroem seus caminhos baseados em tomadas de decises durante o percurso da mensagem. Segundo [ZEFERINO, 2003], os algoritmos de roteamento mais simples so determinsticos e, portanto, definem um nico caminho entre origem e destino, como por exemplo, o algoritmo XY. Nesse algoritmo um pacote deve percorrer totalmente uma linha na direo X at chegar coluna na qual se situa o destinatrio, em seguida ele deve percorrer essa coluna at atingir o roteador ao qual o ncleo destinatrio est conectado, quando ento ele entregue a esse ncleo. Uma vez que um pacote toma a direo Y, ele no pode mais tomar a direo X.
Figura 2.3 redes em chip com topologia indireta

Fonte: [ARAJO, 2008]

O determinismo do algoritmo de roteamento nos fornece uma margem de segurana quanto resoluo dos problemas anteriormente citados, porque nos permite prever o comportamento da mensagem durante o percurso, porm possui limitaes quanto utilizao da rede e de todos os seus recursos disponveis. O modo como a mensagem ser transferida desde a entrada de um roteador at um de seus canais de sada que chamamos de Chaveamento. Os dois mtodos utilizados so: (i) chaveamento por circuito e (ii) chaveamento por pacote. No chaveamento por circuito (circuit switching) estabelecido um caminho desde o ncleo de origem da mensagem at o seu ncleo de destino, pelo qual a mensagem passa. Neste tipo de chaveamento os canais fsicos necessrios para a transmisso da mensagem ficam todos alocados, no podendo ser usados por outras comunicaes at o final da transmisso. Apesar de utilizar um nmero mnimo de buffers (apenas para conter o cabealho responsvel por reservar recursos da rede) possui a desvantagem de no permitir que os canais sejam utilizados por outra mensagem, gerando sub-utilizao na rede. No chaveamento por pacote a mensagem dividida em pacotes, cada um com um

21
cabealho com informaes necessrias sua transmisso pela rede. Os pacotes informam a cada roteador qual caminho seguiro na rede, no existindo um caminho prdefinido e sem estabelecer um circuito fixo do ncleo fonte at o destino. Como no h um caminho pr-definido, possvel uma maior utilizao da rede, pois no h reserva de recursos [CARDOZO, 2005]. Um dos mtodos de chaveamento por pacotes utilizado o VCT (virtual cutthrough). Este mtodo permite que pedaos da mensagem sejam chaveadas e retransmitidas mesmo que a mensagem inteira ainda no tenha sido recebida. Essas tcnicas permitem a reduo da latncia na comunicao e melhoram o desempenho da rede. No chaveamento VCT, quando o cabealho do pacote contendo as informaes de roteamento chega a um nodo de chaveamento e o canal de sada desejado encontra-se disponvel, o restante do pacote (corpo de dados e terminador) desvia o buffer, reduzindo a latncia da comunicao. Um pacote s armazenado no buffer se o canal desejado estiver indisponvel [LZARO, 2011]. Outra tcnica o chaveamento wormhole. Este uma variao do chaveamento VCT que tem como objetivo principal reduzir a quantidade de buffers necessria para manter pacotes bloqueados na rede. Na terminologia do chaveamento wormhole, cada conjunto formado por uma ou mais palavras e sobre o qual realizado o controle de fluxo denominado flit (flow control unit). Um pacote de mensagem ento dividido em flits que avanam pela rede em um modo pipeline. Os buffers dos nodos de chaveamento tem capacidade para armazenar poucos flits, de modo que se um pacote for bloqueado, seus flits sero mantidos em diferentes nodos na rede. Como a informao de roteamento includa nos flits de cabealho, os flits de dado devem seguir os primeiros pela rede. Como resultado disso, no possvel se realizar a multiplexao de flits de diferentes pacotes em um mesmo canal lgico. Um pacote deve atravessar completamente um canal antes de liber-lo para outro pacote. Essa uma das principais desvantagens dessa tcnica de chaveamento, pois a probabilidade de ocorrer o deadlock maior. Entretanto, essa restrio pode ser contornada atravs do uso de canais virtuais [LZARO, 2011]. [ZEFERINO, 2003b] nos afirma que a grande vantagem do chaveamento wormhole que os requisitos de buffer so menores que os das abordagens SAF e VCT, possibilitando a construo de roteadores pequenos e rpidos. Explica ainda que, em geral, o chaveamento wormhole o mais vantajoso com relao utilizao da rede e ao custo dos roteadores, sendo o mais usado atualmente. A arbitragem o mecanismo da rede em chip responsvel por resolver os conflitos

22
entre duas ou mais mensagens que competem pela utilizao de um mesmo recurso. Esse mecanismo deve resolver estes conflitos e ao mesmo tempo tornar a rede imune ao problema de starvation, em que uma mensagem fica esperando indefinidamente para avanar na rede, mas impedida sempre por outra mensagem de maior prioridade. A arbitragem pode ser implementada em estrutura centralizada ou distribuda. Existem vrios mecanismos de arbitragem clssicos, baseados em diferentes critrios tais como: prioridades estticas, dinmicas, escalonamento por idade, FCFS ( First Come First Served), LRS (Least Recently Served) e RR (Round-Robin). A memorizao o esquema de filas usado para guardar mensagens destinadas a canais de sadas que j foram requisitados por uma outra mensagem e que, por isso, esto bloqueadas na rede. Nas redes em chip a memorizao pode ser centralizada ou distribuda nas entradas dos ncleos da rede. Uma rede em chip precisa ainda ter implementado um bom controle de fluxo para que ocorra a perfeita sincronizao entre os ncleos. O controle de fluxo lida com a alocao de recursos da rede (buffers e canais) necessrios para uma mensagem avanar, realizando a regulao de trfego nos canais. Esta poltica de regulao implementada nas redes de interconexo em nvel de enlace, utilizando buffers para armazenamento do dado em transferncia. [CARDOZO, 2005]. A rede possui dimenses limitadas e muitas vezes a quantidade de pacotes que trafegam nela maior do que a sua capacidade de vazo. Assim, o controle de fluxo da rede deve tomar decises sobre o destino a ser dado aos pacotes excedentes podendo armazenar temporariamente em buffers, bloquear, descartar ou mesmo desviar para caminhos alternativos. A tcnica de controle de fluxo baseada em crditos a de mais simples implementao. Nela, o mdulo receptor envia um sinal para o mdulo transmissor informando o espao disponvel no buffer de entrada. Esta informao vista como crdito. A transmisso de dados ocorre quando existem crditos disponveis. Esta uma tcnica de controle de fluxo onde no h descarte de dados [REGO, 2006]. Um outro elemento presente em muitas redes em chip so os canais virtuais. Canais virtuais so elementos de trasmisso multiplexados que viabilizam a transmisso em srie de pacotes como se fossem paralelos. Assim, havendo apenas um canal fsico, pode-se implementar a utilizao de diversos canais virtuais para as diversas funes ou tipos de mensagens a serem transmitidos. Esse mecanismo ter um importante papel no desenvolvimento do trabalho. Uma caracterstica importante nos modelos tradicionais de redes em chip a

23
separao dos conceitos de comunicao e processamento. A nfase na ortogonalidade desses conceitos importante para que se possa realizar uma anlise individual do impacto de eventuais mudanas efetuadas em projetos de redes em chip.

24

A Plataforma IPNoSys
Este captulo se dedica a expor as principais caractersticas da IPNoSys, suas

principais diferenas arquiteturais e pontos relevantes de sua constituio que auxiliam na compreenso do desenvolvimento dos testes implementados. Este trabalho no objetiva esgotar todas as explicaes a respeito da arquitetura. Informaes mais completas a respeito da plataforma podero ser encontradas em [ARAJO, 2012], [ARAJO, 2008] e [FERNANDES, 2010].

3.1

A arquitetura IPNoSys
O sistema proposto na IPNoSys baseado na comunicao de uma rede com

topologia em Grelha 2D de dimenso quadrada, ou seja, o nmero de linhas igual ao de colunas; utiliza, no mnimo, dois canais virtuais; roteamento XY com modificaes; chaveamento que combina VCT e wormhole; controle de fluxo baseado em crdito; arbitragem distribuda; e armazenamento na entrada. Nessa proposta os tradicionais processadores das redes diretas so substitudos por quatro Unidades de Acesso Memria (MAU Memory Access Unit) e os roteadores tornam-se Unidades de Processamento e Roteamento (RPU Routing and Processing Unit). O sistema de entrada e sada (IONode e MemArbiter) tambm ligado a uma das MAUs. Os pacotes deixam de ser apenas mensagens de requisies e respostas para se tornarem uma estrutura contendo instrues e operandos a serem processadas durante o percurso do pacote. Os pacotes so armazenados nas memrias nos cantos da rede que so gerenciadas pelas MAUs [ARAJO, 2012]. A Figura 3.1 ilustra o sistema IPNoSys formado por uma rede 4x4. A Tabela 3.1 mostra as caractersticas da rede em chip IPNoSys. Os pacotes IPNoSys so conjuntos variveis de palavras de 32 bits de tamanho. Existem quatro tipos de palavras nos pacotes: cabealho, instruo, operando e fim de pacote. Os tipos de palavras so identificados atravs de seus quatro primeiros bits, chamados bits de controle como mostrado na Figura 3.2. Cada pacote possui somente um cabealho e um fim de pacote, mas o nmero de instrues e operandos varivel em cada pacote.

25
Figura 3.1 Arquitetura IPNoSys

Fonte: [ARAJO, 2012]

Tabela 3.1 Caractersticas da Rede IPNoSys Aspecto Topologia Roteamento Chaveamento Controle de fluxo Arbitragem Memorizao Canais Virtuais IPNoSys utiliza Grelha 2D de dimenso quadrada Roteamento XY com modificaes (Spiral complement) Combinado VCT e wormhole Baseado em crditos Distribuda Armazenamento na entrada No mnimo dois

Figura 3.2 Formato dos pacotes

Fonte: [ARAUJO, 2012]

26
O cabealho possui trs palavras. A primeira palavra indica a origem e o destino do pacote, o nmero corrente de instrues presentes no pacote, trs bits que determinam o modo como ser calculado o novo destino do pacote quando este alcanar o seu destino atual e um flag de 5 bits que determina o tipo do pacote. Atualmente existem quatro tipos de pacotes que so identificados a partir do campo tipo na primeira palavra do cabealho: controle, regular, interrompido e caller. Os pacotes de controle carregam instrues que so executadas na MAU, enquanto os pacotes regulares so compostos por instrues executveis em qualquer RPU da rede. Os pacotes interrompidos so pacote regulares que foram impossibilitados de serem executados por estarem esperando um evento de E/S. E por fim, um pacote caller tambm um pacote regular que fez uma chamada de uma funo, executada atravs de outro pacote, para onde o resultado da execuo dessa funo dever ser retornado [ARAJO, 2012]. A segunda palavra do cabealho possui um identificador para pacote, indicando em dois campos o nmero do programa ou processo do qual o pacote faz parte e o nmero do pacote em si. A terceira palavra do cabealho possui trs campos sendo o primeiro o endereo da MAU onde o programa foi iniciado, o segundo, chamado de IPR (abreviao de instrues por RPU), que informa a quantidade de instrues que ser executada em cada RPU pela qual o pacote passa e o apontador (16 bits) que possui o nmero de palavras processadas ao longo do percurso do pacote, indicando a prxima instruo a ser executada, funcionando de maneira semelhante a um PC (Program Counter). As RPUs so roteadores com capacidade para executar instrues lgicas e aritmticas e tambm instrues de salto. Como a topologia da rede IPNoSys uma rede Mesh 2-D, as RPUs situadas no centro da rede possuem quatro portas de comunicao enquanto as RPUs das bordas da rede e dos quatro cantos, possuem apenas trs. Quando um pacote chega ao buffer de entrada de uma RPU, o seu tipo verificado. Se este for um pacote de controle, ento ele ser roteado utilizando o roteamento XY tradicional e transmitido atravs de um canal virtual exclusivo. Caso seja um pacote regular primeiro verifica-se se a atual RPU a RPU destino para o pacote. Sendo assim, um novo destino para o pacote ser calculado, utilizando o algoritmo de roteamento vigente na rede. Em seguida o pacote roteado para um novo destino seguindo o roteamento XY. Quando a RPU atual no o destino do pacote, este simplesmente roteado utilizando o roteamento XY. Em cada porta de sada existe um rbitro que soluciona os conflitos entre pacotes que eventualmente solicitem o uso da via ao mesmo tempo. Antes, porm, de transmitir o

27
pacote regular o rbitro solicita a execuo da primeira instruo contida no pacote. Caso esta instruo seja uma operao lgico-aritmtica ou de salto, o rbitro solicita ULA que a execute. Caso a instruo seja uma instruo direcionada MAU (acesso memria ou sincronizao de aplicaes), o rbitro envia uma solicitao Unidade de Sincronizao (SU) que ir criar um pacote de controle para a MAU em questo. Em ambos os casos, o rbitro espera a resposta para depois remover a instruo e seus respectivos operandos do pacote e prosseguir com sua transmisso para a prxima RPU. A quantidade de palavras removidas do pacote adicionada ao apontador no cabealho do pacote. Caso esta instruo retorne algum resultado, o rbitro mantm esse valor em um buffer de resultados enquanto espera o ponto exato de insero no pacote indicado pela instruo. Buffers de resultado devem incluir dado de resultado (32 bits) e at dois endereos de resultado (11 bits cada). Quando a RPU no pode trasmitir o cabealho do pacote devido a falta de espao em buffer da RPU seguinte ou devido a situaes de deadlock, o rbitro executa localmente as instrues. Assim, continua a solicitar ULA e SU a execuo de instrues do pacote at que a transmisso do pacote se torne possvel. Na IPNoSys, uma aplicao consiste em um ou mais pacotes armazenados na memria. As Unidade de Acesso Memria (MAUs), localizadas nos cantos da rede, so responsveis por ler os pacotes armazenados na memria e injet-los na rede, alm das tarefas de leitura escrita de dados na memria. Esta tarefa realizada atravs de instrues da MAU ou instrues de controle. Estas instrues so responsveis por estabelecer a comunicao ou sincronizao entre os mdulos processantes (MAUs e RPUs) ou compartilhar resultados de computao entre os pacotes. Atravs dessas instrues um resultado obtido em um nodo da rede pode ser enviado para a memria onde ser inserido como operando em outro pacote. Quando uma RPU identifica uma dessas instrues, ela cria um pacote de controle e o envia para a MAU especfica que o executar. Pacotes de controle so enviados por um canal virtual exclusivo, imune a deadlocks, uma vez que o pacote de controle bastante pequeno e no trafega por uma rota circular. Alm disso, este canal virtual dedicado a transmitir apenas pacotes de controle. Uma vantagem atribuda s redes em chip a separao entre computao e comunicao. A rede em chip responsvel nica e exclusivamente por realizar a comunicao entre os elementos de processamento responsveis pela computao [ARAJO 2012]. A IPNoSys representa uma soluo de sistema multiprocessado que rompe com o paradigma da separabilidade entre computao e comunicao,

28
aproveitando os elementos da estrutura das redes em chip para a realizao da computao durante a comunicao. A RPU o elemento central nesse ponto, por caracterizar o elemento que une os dois conceitos em questo.

3.2

Modelo de programao
O conjunto de instrues IPNoSys formado por 32 instrues, onde 4 so

aritmticas, 4 lgicas, 2 de deslocamentos, 3 de acesso a memria, 4 de sincronizao, 6 de desvios condicionais, 1 de incondicional, 2 auxiliares, 2 de entrada/sada, 2 de sistema e 2 de chamada de procedimento, como mostrado na Tabela 3.2. [ARAJO, 2012].
Tabela 3.2 Conjunto de instrues IPNoSys
# 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 Instruo ADD SUB MUL DIV NOT AND OR XOR RSHIFT LSHIFT LOAD STORE EXEC SYNEXEC SYNC RELOAD BE BNE BL BG BLE BGE JUMP COPY NOP SEND IN OUT Tipo Aritmtica Aritmtica Aritmtica Aritmtica Lgica Lgica Lgica Lgica Deslocamento Deslocamento Acesso Memria Acesso Memria Sincronizao Sincronizao Sincronizao Acesso Memria Condicional Condicional Condicional Condicional Condicional Condicional Incondicional Auxiliar Auxiliar Sincronizao Entrada e sada Entrada e sada Descrio Soma 2 inteiros Subtrai 2 inteiros Multiplica 2 inteiros Divide 2 inteiros Negao de 1 valor Conjuno de 2 valores Disjuno de 2 valores Ou-exclusivo de 2 valores Desloca n bits de um valor direita Desloca n bits de um valor esquerda Solicita um valor da memria Armazena um valor na memria Ordena a injeo imediata de um pacote Ordena a injeo de um pacote aps sincronizao Sinal de sincronizao para um pacote Retorna um valor carregado da memria Desvia se igual Desvia se diferente Desvia se menor Desvia se maior Desvia se menor ou igual Desvia se maior ou igual Desvia incondicionalmente Copia 1 valor para outra instruo no mesmo pacote Sem operao Envia um valor para ser inserido em um pacote Recebe bytes do controlador de Entrada e Sada Envia bytes ao controlador de Entrada e Sada

29
28 29 30 31 WAKEUP NOTIFY CALL RETURN Sistema Sistema Procedimento Procedimento Ordena a reinjetar um pacote antes interrompido Notifica estado de um pacote Faz a chamada de uma funo/pacote Retorna o resultado de uma funo para o chamador Fonte: [ARAJO, 2012]

Todas as instrues so executadas pelas RPUs, exceto as instrues de acesso memria e de sincronizao que so enviadas por meio de pacotes de controle s MAUs, onde so executadas. Esta a razo pela qual tais instrues so chamadas instrues de controle e as outras ditas instrues regulares. Este conjunto de instrues apresentado uma ferramenta para construo de programas executveis IPNoSys. Contudo, algumas consideraes devem ser feitas [ARAJO, 2012]: 1. Uma aplicao ou programa pode ser formado por 1 ou mais pacotes regulares. 2. Todo programa deve ter um pacote com identificador 0 (zero), o qual ser usado para indicar o fim do programa.

3. Um pacote injetado (pacote em execuo) uma cpia do pacote que permanece

na memria, identificado pelo par ID programa e ID pacote.

4. O par ID programa/ID pacote traduzido para o endereo de memria, pela MAU

que gerencia a memria onde o pacote est armazenado. 5. possvel modificar o valor de um operando de um pacote no momento que est sendo injetado, atravs de instrues SEND, tendo assim uma nova instncia do pacote, sem alterar o valor original do pacote mantido na memria. 6. IPNoSys no utiliza registradores, ento variveis de programas so sempre posies de memria que podem ser lidas ou escritas (atravs de LOAD e STORE). Entretanto, durante a execuo das instrues nos pacotes, o valor das variveis e os resultados intermedirios podem ser inseridos no pacote como operando de uma instruo no mesmo ou em outro pacote. 7. As instrues so executadas na ordem que aparecem nos pacotes. 8. Podem existir instrues de desvio de fluxo que podem provocar o descarte de vrias palavras de um pacote at a palavra do desvio, mas nunca pode acontecer um desvio do fluxo da execuo para instrues anteriores, uma vez que instrues anteriores a do desvio j foram executadas e no fazem mais parte do pacote. 9. Um pacote pode ser injetado tantas vezes quanto for necessrio, de acordo com a quantidade de instrues EXEC ou SYNEXEC foram enviadas para injet-lo.

30
10. Um pacote pode se autoexecutar, desde que haja pelo menos uma instruo EXEC ou SYNEXEC, dentro do pacote, para injet-lo da memria para as RPUs novamente. 11. Um lao de repetio pode ser implementado atravs das propriedades 5, 8, 9 e 10. 12. At quatro pacotes podem ser injetados simultaneamente, um em cada MAU, sejam eles da mesma aplicao ou de aplicaes diferentes. Isso pode ser usado para criar threads (fluxos de execues paralelas) de uma mesma aplicao. O modelo de programao do sistema IPNoSys consiste em descrever as aplicaes/programas atravs de um ou mais pacotes, os quais so injetados e executados no sistema, na ordem da dependncia dos dados entre as computaes que cada pacote representa. Do mesmo modo, um pacote um conjunto de instrues com seus respectivos dados, empilhados de acordo com a dependncia de dados. Assim uma instruo executada apenas quando estiver no topo dessa pilha, ou seja, no incio do pacote j com todos os seus operandos. Com isso, o resultado de uma instruo executada pode fornecer dados que serviro de operandos para outras instrues a serem executadas posteriormente [ARAJO, 2012]. A Figura 3.3 mostra um exemplo simples de operaes matemticas onde a terceira operao (multiplicao) tem dependncia de dados de duas instrues prvias (adio e subtrao). Seguindo o modelo de programao IPNoSys as instrues so colocadas em ordem em um pacote de acordo com suas dependncias de dados. Para este exemplo o pacote mostrado na Figura 3.3 (b) foi criado. Note-se que cada palavra do pacote possui um nmero, porm alguns nmeros foram intencionalmente omitidos. Tais nmeros representam as palavras correspondentes a operandos que dependem de resultados em instrues prvias.
Figura 3.3 (a) grafo de dependncia de dados e (b) seu pacote correspondente

Fonte: [FERNANDES, 2010]

31
No momento em que o pacote injetado, cada RPU no caminho do pacote remove a primeira instruo presente no pacote, executa-a, atualiza o apontador para a prxima instruo, transmite o pacote para a prxima RPU e insere os resultados nas posies correspondentes indicadas na instruo, conforme nos mostra a Figura 3.4. A Figura 3.4 (a) mostra o pacote no momento da execuo de uma instruo. A Figura 3.4 (b) mostra o pacote aps a execuo da instruo, atualizando o apontador e inserindo os resultados nas palavras 7 e 10. A prxima instruo ser executada do mesmo modo pela RPU seguinte.
Figura 3.4 Execuo de uma instruo: (a) momento da execuo e (b) aps a execuo com as palavras inseridas no pacote

Fonte: [FERNANDES, 2010]

Uma vez que a arquitetura IPNoSys possui um novo paradigma de programao, h algumas peculiaridades em seu cdigo Assembly que precisam ser implementados. Para descrever as aplicaes no formato de pacotes, foi desenvolvida a Linguagem de Descrio de Pacotes (PDL Package Description Language) para ajudar ao programador a desenvolver suas aplicaes em um nvel intermedirio entre linguagens de alto nvel e o formato dos pacotes. A PDL equivalente a uma linguagem Assembly, a qual deve ser processada por um montador (do ingls: assembler) afim de ser traduzida para o cdigo objeto da arquitetura, neste caso os pacotes em formato binrio [ARAJO, 2012]. A Figura 3.5 apresenta a gramtica que define a PDL para a arquitetura IPNoSys. Conforme podemos ver em [ARAJO, 2012], a PDL diferencia palavras maisculas de minsculas e possui algumas palavras reservadas como podem ser vistas na definio dos tokens da linguagem na Figura 3.6.

32

Figura 3.5 Gramtica da PDL

Fonte: [ARAJO, 2012]

Figura 3.6 Tokens da PDL

Fonte: [ARAJO, 2012]

33

O Roteamento na IPNoSys
A rede em chip IPNoSys uma arquitetura peculiar, e como qualquer arquitetura

tambm possui vantagens e desvantagens. Existem campos de aplicao que podem ser beneficiados com o modelo de execuo da IPNoSys, como por exemplo as aplicaes com fluxo contnuo de dados. No entanto sempre possvel agregar funcionalidades novas ou mesmo melhorar as j existentes. Cada elemento componente da arquitetura passvel de mudanas e melhorias e implementar essas melhorias no hardware da rede IPNoSys pode significar elevao do custo de implementao. Podemos, porm, trabalhar conceitos relacionados interao dos componentes da arquitetura e efetuar mudanas no modo como eles trabalham, sem que essas mudanas representem uma elevao sensvel no custo de implementao. Arbitragem, roteamento, multiplexao de pacotes, gerenciamento dos buffers, entre outros podem ser alterados sem grandes variaes no custo de implementao. Como opo de melhorias na arquitetura, o modelo de roteamento pode ser uma alternativa para aumentar o desempenho da rede em chip como um todo. Os testes realizados serviro como base para a avaliao de um novo algoritmo de roteamento.

4.1

O roteamento original
As aplicaes que rodam na plataforma IPNoSys so descritas no formato de

pacotes onde esto explcitas informaes necessrias para a execuo como o particionamento da aplicao, o sincronismo e a comunicao entre as partes do programa. No caminho dos pacotes dentro da rede, cada RPU executa pelo menos uma instruo contida no incio do pacote. Essa quantidade de instrues tambm definida pelo programador. Segundo [ARAJO, 2012] o destino de cada pacote criado para prover recursos suficientes para execuo das instrues contidas no pacote. Entretanto, o nmero de instrues, e operandos, so variveis em cada pacote, dependendo da aplicao. Assim, para que seja possvel executar o maior nmero de instrues, o destino do pacote deve ser suficientemente distante da origem, considerandose a distncia entre destino e origem como o nmero de RPUs intermedirias nesse caminho A impossibilidade de determinar o nmero e a natureza das instrues presentes em cada programa inviabiliza a construo de uma rede em chip com dimenses fixas que

34
seja ideal para todos os tipos de aplicaes. A rede IPNoSys redestina o pacote quando este atinge o final do caminho. Isto feito atravs de um algoritmo baseado no roteamento XY e no padro de trfego complemento, chamado de Spiral Complement. Esse algoritmo capaz de rotear novamente um pacote, tantas vezes quanto for necessrio, at que seja garantida a execuo de todas as instrues, independentemente do nmero de instrues e das dimenses da rede (nmero de RPUs) [ARAJO, 2012]. O algoritmo para calcular os endereos de destino para os pacotes em execuo mostrado na figura Figura 4.1. Esse o algoritmo implementado na plataforma IPNoSys original.
Figura 4.1 Algoritmo para Calcular Novo Endereo no Spiral Complement

Fonte: [ARAJO, 2012]

No algoritmo spiral complement, o destino inicial de um pacote o complemento da origem. Ento, quando um pacote atinge seu destino e o nmero de instrues contidas no pacote maior que zero, um novo destino deve ser calculado, ou seja, feito um novo roteamento. Neste novo roteamento, a origem passa a ser o antigo destino, ou seja, o nodo corrente que calcula o novo destino, e o novo destino calculado levando-se em considerao a necessidade de se obter a melhor distribuio de carga possvel entre os canais da NoC. Na IPNoSys os pacotes so inicialmente injetados em um dos quatro cantos da rede, uma vez que os pacotes so armazenados nas memrias que esto localizadas nos cantos. A cada novo destino calculado, a rede virtualmente reduzida em uma linha ou em uma coluna alternadamente, e o pacote enviado para o canto oposto dessa rede reduzida [ARAJO, 2012]. A Figura 4.2 mostra as quatro espirais que so geradas pelo roteamento spiral complement para uma matriz de 4x4 RPUs, para pacotes originados em cada um dos quatro cantos da rede.

35

Figura 4. 2 Roteamento spiral complement: (a) 1 espiral; (b) 2 espiral; (c) 3 espiral; (d) 4 Espiral

Fonte: [ARAJO, 2012]

Analisando o algoritmo original de roteamento da IPNoSys percebemos que este permite que o pacote percorra a rede e, em um dado momento, sendo este grande o bastante, encontrar com a sua parte anterior ainda no executada. Esse tamanho mnimo de pacote depende das dimenses da rede e da espiral em que se encontra este pacote. Considere-se aqui o tamanho do pacote determinado pelo nmero de instrues nele contidas. Em uma rede IPNoSys de tamanho 4x4, para as espirais de nmeros 1 e 3, pacotes com pelo menos 24 (15 + 9) instrues iro encontrar-se com sua parte no transmitida. Para as espirais 2 e 4, o tamanho mnimo para que essa situao ocorra 22 (11 + 11). O clculo desse nmero feito contabilizando-se o nmero de RPU pelas quais o pacote j passou (que representa o nmero de instrues j executadas at aquele momento), acrescido do nmero de instrues que um pacote deve ter, ainda a serem executadas, para encontrar-se com sua ltima instruo. Essa situao geraria um deadlock, se o sistema no permitisse a execuo

36
localizada das instrues. A execuo localizada das instrues nas RPUs a soluo da IPNoSys para evitar o problema com deadlock. A Figura 4.3 ilustra essa situao para redes de tamanho 4 usando as espirais (a) 1 e (b) 2.
Figura 4.3 Situaes de deadlock

Fonte: Prprio autor

Solucionado o deadlock pela execuo localizada, teremos um resultado explcito nos relatrios de simulao como visto em [ARAJO, 2012] que mostra que, nesse caso, uma RPU pode se encarregar de executar um grande nmero de instrues. Ainda na mesma situao, as simulaes relataram que algumas RPUs no executavam instruo alguma, reflexo da desigual distribuio da responsabilidade de execuo das instrues. Um fato importante a ser observado que a execuo localizada no somente resolve as situaes de deadlock mas tambm impede que a rede execute o reroteamento previsto para pacotes com tamanho que ultrapasse o caminho feito atravs da espiral. Aps as sucessivas execues localizadas o pacote reduzido de tal forma que ao terminar o seu caminho na espiral onde foi inicialmente injetado, no ter um nmero mnimo de instrues tal que possa percorrer sequer um trecho da espiral seguinte. No podemos imputar a responsabilidade desse impedimento somente execuo localizada, mas ao conjunto execuo localizada + Spiral Complement. Assim, como no podemos descartar a execuo localizada por causa do tamanho limitado da rede e da imprevisibilidade dos tamanhos e percursos das aplicaes, nos resta buscar uma alternativa de roteamento diferente do Spiral Complement, atualmente aplicado.

37

4.2

O roteamento em zigue-zague
Propomos aqui um novo modelo de roteamento para a rede IPNoSys,

determinstico e como rotas de mesmo tamanho nas quatro possibilidades. Alm disso, a viabilidade de re-rotear os pacotes, como previsto na implementao da IPNoSys, e a possibilidade de permitir outros modelos de execuo so duas caractersticas do roteamento em zigue-zague. Conforme podemos ver em [NOBRE, 2012], a prpria arquitetura da IPNoSys possui modelo de execuo compatvel com modelos de computao orientados a dados (como por exemplo o modelo Dataflow), uma vez que os dados trafegam junto com as instrues em pacotes dedicados execuo de operaes. O modelo de computao baseado em passagem de pacotes entre os roteadores, caracteriza um pipeline e explora o paralelismo das transmisses. Para implementarmos uma mquina Dataflow na IPNoSys, teramos que dividir a tarefa de computao em duas etapas: na primeira os pacotes trafegam pela rede programando as suas unidade de processamento; em uma etapa posterior os dados trafegam e as unidades de processamento executam a instruo previamente memorizada sobre cada dado nos pacotes. Mas esse tipo de processamento no pode ser implementado se o caminho dos pacotes passar duas vezes pelo mesmo ponto. Assim, o roteamento em Zigue-zague aparece como proposta para viabilizar esse tipo de implementao. As Figuras 4.4 e 4.5 mostram as duas etapas na execuo do modelo dataflow em uma IPNoSys dataflow.
Figura 4.4 Mquina Dataflow em sua etapa de programao das unidades de processamento

Fonte: Prprio autor

38
Figura 4.5 Mquina Dataflow em sua etapa de execuo das intrues

Fonte: Prprio autor

Pretende-se tambm com esse novo modelo de roteamento retardar a situao de execuo localizada e buscar uma melhor distribuio da execuo das instrues nas RPUs, evitando a ociosidade das unidades de processamento. Busca-se tambm uma distribuio mais equilibrada no uso dos buffers e dos canais de comunicao, por se tratarem tambm de recursos alocveis do sistema. Considerando as espirais no roteamento Spiral complement podemos perceber que em cada uma delas h uma probabilidade maior de encontrarmos o cabealho do pacote em um canto da rede. Esse fato no ocorre no roteamento em Zigue-zague, onde a probabilidade a mesma, independente da rota que o pacote percorre. A Figura 4.6 apresenta as quatro rotas do novo modelo de roteamento, correspondentes respectivamente aos pacotes injetados pelas MAUs (0,0), (3,0), (3,3) e (0,3). Ainda que implcito na Figura 4.6, necessrio um olhar mais atento para perceber que as rotas no formam uma sequncia, como na ideia original da IPNoSys. As espirais do modelo original se sequenciam na mesma ordem numrica (1, 2, 3 e 4 espirais). O novo roteamento segue a sequncia apresentada na Figura 4.7. Observe que um pacote injetado inicialmente pela rota 1 se roteado novamente prosseguir pela rota 2, em seguida pela rota 3 e depois pela rota 2 novamente. Lembrando que os pacotes podem ser injetados a partir de qualquer rota.

39
Figura 4.6 Quatro rotas da IPNoSys em zigue-zague: (a) 1 rota; (b) 2 rota; (c) 3 rota; (d) 4 rota

Fonte: Prprio autor

Figura 4.7 Sequncia de rotas na IPNoSys usando o roteamento em zigue-zague

Fonte: Prprio autor

Podemos pensar que esse modelo vai levar a uma maior concentrao de palavras nas rotas 2 e 3, mas isso no representa uma maior concentrao em um dado ponto da rede, j que cada uma das unidades de processamento aparece somente uma vez em

40
cada rota, o que no ocorre no Spiral Complement. Observando-se a Figura 4.2 nota-se que pacotes trafegando pela 2 espiral podem passar pelo n (3,3) at 4 vezes. Considerando ainda a possibilidade de re-roteamento e o grafo de sequncia das rotas, o novo modelo permite que, sendo injetado a partir da MAU localizada no canto superior esquerdo (MAU 0,0) e aumentando-se o nmero de canais virtuais disponveis para pacotes regulares para 2, um pacote pode executar at 51 instrues antes que a execuo localizada ocorra. Esse limite passvel de acrscimo se aumentarmos tambm o nmero de canais virtuais. A vantagem dessa abordagem est na facilidade de implementao de melhorias no sistema sem que o hardware em si seja alterado, o que pode acarretar custos elevados de projeto. A Figura 4.8 mostra o algoritmo para o clculo do novo endereo de destino implementado no roteamento em Zigue-zague.
Figura 4.8 Algoritmo para clculo do novo endereo no roteamento em Zigue-zague

SeINICIO Se(ROTA=1)OU(ROTA=4) DESTINO=(X+1,COMPLEMENTOdeY) Seno DESTINO=(COMPLEMENTODEX,Y) Fim_se Seno Se(ROTA=1)OU(ROTA=4) Se(DESTINO.X=TAMANHODAREDE) DESTINO=(X,COMPLEMENTOdeY) Seno DESTINO=(X+1,COMPLEMENTODEY) Fim_se Seno Se(ROTA=2) Se(DESTINO.Y=TAMANHODAREDE) DESTINO=(COMPLEMENTODEX,Y) Seno DESTINO=(COMPLEMENTODEX,Y+1) Fim_se Seno//(ROTA=3) Se(DESTINO.Y=0) DESTINO=(COMPLEMENTODEX,Y) Seno DESTINO=(COMPLEMENTODEX,Y1) Fim_se Fim_se Fim_se Fim_se

Fonte: Prprio autor

As rotas 1 e 4 correspondem, respectivamente, aos pacotes injetados a partir das MAUs (0,0) e (0,3), localizadas na parte superior da rede. Essas duas rotas possuem sentidos contrrios e so implementadas de forma semelhante. O primeiro destino do

41
pacote nestas rotas o nodo localizado na coluna oposta, na linha imediatamente abaixo. Percorre toda a rede realizando o clculo do novo destino sempre da mesma forma, at que esteja na ltima linha. Neste caso o novo destino no est na linha inferior, mas na mesma linha. As rotas 2 e 3 correspondem, respectivamente, aos pacotes injetados a partir das MAUs (3,0) e (3,3), localizadas na parte inferior da rede. O primeiro destino calculado nestas rotas corresponde ao nodo localizado na linha oposta. Durante todo o percurso o endereo de destino ser o nodo localizado na linha oposta, na prxima coluna, para a rota 2, e o nodo localizado na linha oposta, na coluna anterior, para a rota 3. Ao final de todas as rotas, o pacote re-roteado, caso ainda possua instrues a serem executadas, para a rota indicada na Figura 4.7.

42

Experimentos
Este captulo apresenta os resultados dos testes de simulao realizados com a

IPNoSys utilizando o roteamento em zigue-zague. O conjunto de testes realizados corresponde a um subconjunto dos testes implementados em [ARAUJO, 2012], assim escolhido para que pudesse ser realizada uma anlise com base na comparao dos resultados obtidos com o algoritmo original de roteamento. Os testes escolhidos so referentes anlise da soluo adotada para preveno a deadlocks, explorao de paralelismo e utilizao de canais virtuais. Assim como em [ARAUJO, 2012], todos os resultados foram obtidos a partir do simulador da IPNoSys em SystemC com preciso de ciclos. Vrios parmetros do simulador foram configurados de diferentes formas afim de obtermos diferentes instncias da arquitetura, de acordo com a necessidade de cada caso de teste. Todos os testes foram realizados em uma rede de tamanho 4x4. Em [ARAUJO, 2012], os testes foram efetuados em uma verso anterior da plataforma IPNoSys que posteriormente passou por uma reviso de cdigo. Por este motivo e para evitar eventuais inconsistncias nos testes, repetimos os mesmos testes realizados em [ARAUJO, 2012] na mais nova verso da IPNoSys, datada de Fevereiro de 2013.

5.1

Caso de teste 1 Preveno a deadlock

O algoritmo de roteamento originalmente adotado foi proposto para disponibilizar

recursos de processamento suficientes para execuo de todas as instrues, independente da quantidade de instrues presente nos pacotes e da quantidade de RPUs disponveis. Entretanto, esse algoritmo cria rotas em espirais, o que fatalmente provocaria um deadlock [ARAUJO, 2012]. Como visto na seo anterior, a execuo localizada evita o deadlock. Os testes aqui realizados nos possibilitam fazer uma avaliao da eficincia desse mecanismo da resoluo do problema de deadlock e seu impacto no desempenho da IPNoSys. Assim como nos testes realizados na IPNoSys original, avaliamos a taxa de ocupao dos buffers de resultado nos rbitros e a quantidade de instrues executadas em cada RPU, por meio da execuo de um contador simples, no qual variamos nmero de instrues e o modo de execuo (sequencial ou em paralelo).

43
O contador foi implementado atravs de adies unitrias e acumulaes sucessivas, ou seja, h dependncias sucessivas de dados das instrues imediatamente anteriores. Em geral cada RPU executa apenas uma instruo at que uma situao de deadlock seja iminente, quando ento a execuo localizada iniciada [ARAUJO, 2012]. A Tabela 5.1 traz os parmetros definidos para cada simulao.
Tabela 5.1 Parmetros das simulaes para o caso de teste N 1

Estratgia Sequencial Em paralelo

Quantidade de instrues 8, 16, 32, 64, 128 e 256 8, 16, 32, 64, 128 e 256

Na execuo sequencial, apenas dois pacotes compem a aplicao: um pacote contendo as instrues de adio e o outro para finalizar a aplicao. Ambos so injetados a partir da MAU localizada no canto superior esquerdo (MAU 0,0). As simulaes para este caso de teste foram realizadas utilizando dois canais virtuais, um para pacotes de controle e outro para os pacotes regulares. A Figura 5.1 mostra a quantidade de instrues que foram processadas em cada RPU, nas seis simulaes utilizando a estratgia sequencial. A Figura 5.2 apresenta os resultados das simulaes utilizando a mesma estratgia, dessa vez utilizando o roteamento em zigue-zague. Em ambos os grficos, as RPUs esto representadas no eixo X, enquanto o eixo Z mostra as diferentes quantidades de instrues e o eixo vertical Y a quantidade de instrues efetivamente executadas em cada RPU. Analisando o grfico da Figura 5.1 pode-se notar que h uma maior concentrao da execuo das instrues no nodo (3,2), quando o pacote possui 32 ou mais instrues. Isso ocorre devido injeo do pacote ser feita pelo nodo (0,0 ) e, em consequncia, o tratamento do deadlock, atravs da execuo localizada, acontecer no nodo (3,2). Alm disso, a concentrao no nodo (3,2) tende a aumentar medida que o nmero de instrues no pacote tambm aumenta, enquanto nos outros nodos o nmero de instrues executadas se mantm equilibrado. No nodo (0,0), so executadas mais instrues que a maioria, pois nesse nodo que tanto o pacote principal da aplicao quanto o pacote finalizador so injetados. Um comportamento semelhante pode ser observado no grfico da Figura 5.2 onde h concentrao maior no nodo (0,0) ao invs do (3,2). Numericamente as quantidades diferem em um valor no considervel (vide Anexo I), assim pode-se dizer que o algoritmo em zigue-zague apenas transferiu a posio do nodo onde essas instrues vo se concentrar. Uma diferena importante a melhor distribuio da execues nas outras

44
RPUs, no ocorrendo, por exemplo, a no utilizao da RPU (2,1), como visto na Figura 5.1. Dados mais detalhados a respeito dos grficos abaixo podem ser encontrados no Anexo I do presente trabalho.
Figura 5.1 Quantidade de instrues por nodo usando o contador sequencial na IPNoSys com roteamento Spiral complement

Fonte: Prprio autor

Figura 5.2 Quantidade de instrues por nodo usando o contador sequencial na IPNoSys com roteamento em zigue-zague

Fonte: Prprio autor

No modo de execuo em paralelo a aplicao tem uma estrutura diferente onde o

45
paralelismo explcito pela distribuio dos pacotes. Um pacote inicial responsvel por ordenar a injeo de quatro pacotes paralelos, cada um por uma MAU diferente, e esperar os sinais de sincronizao dos quatro pacotes para injetar o pacote finalizador. A Figura 5.3 ilustra a relao entre os pacotes componentes da aplicao.
Figura 5.3 Relao entre os pacotes do Contador Paralelo

Fonte: [ARAJO, 2012]

A Figura 5.4 apresenta as quantidades de instrues executadas em cada nodo para o contador paralelo na IPNoSys com roteamento original, tambm variando a quantidade de instrues de 8 at 256. A Figura 5.5 apresenta os resultados da mesma aplicao utilizando a IPNoSys com roteamento em zigue-zague. Em ambos os grficos as RPUs esto representadas no eixo X, enquanto o eixo Z mostra as diferentes quantidades de instrues e o eixo vertical Y a quantidade de instrues efetivamente executadas em cada RPU. Segundo a anlise feita em [ARAJO, 2012], para os resultados do algoritmo spiral complement, na abordagem paralela a quantidade de instrues executadas nos nodos melhor distribuda, comparada a execuo sequencial. Nota-se na Figura 5.4 que mesmo existindo uma maior concentrao nos nodos dos cantos da rede (0,0), (0,3), (3,0) e (3,3), existe uma melhor distribuio da carga pela rede. Alm disso, os valores dos picos desse grfico so quatro vezes menores em comparao a execuo sequencial para os mesmos casos, o que significa que necessrio menos recursos de armazenamento local e melhor desempenho em tempo de execuo. Esse grfico tambm demonstra como o algoritmo spiral complement distribui a carga nos cantos da rede, evitando congestionamento nos canais da regio central da rede, como em geral acontece no padro de trfego complemento nas NoCs tradicionais. O mesmo comportamento pode ser observado na Figura 5.5 exceto a maior concentrao de execues que neste caso migrou para os nodos (0,0), (0,3), (1,3) e (3,1).

46
Outro fato notrio a melhor distribuio nos outros nodos. O algoritmo em zigue-zague neste caso tambm evitou a ociosidade das RPUs da rede.
Figura 5.4 Quantidade de instrues por nodo usando o contador paralelo na IPNoSys com roteamento Spiral Complement

Fonte: Prprio autor

Figura 5.5 Quantidade de instrues por nodo usando o contador paralelo na IPNoSys com roteamento em Zigue-zague

Fonte: Prprio autor

Para analisarmos a distribuio da tarefa de execuo nas RPUs, excetuando-se

47
as de maior concentrao, obtivemos o clculo do desvio padro do nmero de instrues nas demais RPUs da rede. Segundo [TEDESCO, 2005], O desvio padro, cuja frmula est indicada na Figura 5.6, indica a disperso dos valores medidos em relao mdia. Um pequeno desvio padro indica, desta forma, valores da distribuio prximos ao valor de sua mdia. Os valores obtidos so apresentados na Tabela 5.2.
Figura 5.6 Frmula para clculo do desvio padro

Tabela 5.2 Desvio padro para distribuio de carga na IPNoSys, contador paralelo # de Instrues 8 16 32 64 128 256 Spiral complement 0.4923659639 0.9847319278 1.1677484162 1.1281521496 1.0836246695 0.9847319278 Zigue-zague 0.7784989442 0.9003366374 0.9534625892 0.6513389473 0.4264014327 0.4264014327

Os valores apresentados na Tabela 5.2 indicam uma distribuio mais homognea nos testes realizados com o roteamento em zigue-zague para este tipo de aplicao. Com relao ao impacto que o paralelismo representa para a execuo de uma aplicao, foi realizada tambm uma anlise comparativa entre as estratgias sequencial e paralela do contador para as duas verses do roteamento. A comparao leva em considerao (i) o tempo de execuo, (ii) o tempo mdio de transmisso de flits, (iii) a utilizao mdia de canais e (iv) a taxa efetiva de transmisso. A comparao do tempo de execuo (em ciclos) apresentada nos grficos da Figura 5.7. A curva do tempo de execuo na estratgia sequencial cresce mais rapidamente a partir de aplicaes que possuem acima de 32 instrues, enquanto que na implementao paralela, o tempo de execuo cresce de forma mais lenta. A anlise feita por [ARAJO, 2012] afirma que o crescimento do tempo de execuo na estratgia sequencial se d a partir desse nmero de instrues devido s dimenses da rede (4x4), quando a situao de deadlock ocorre e acontece a execuo localizada no nodo (3,2). Indica ainda que, esse fenmeno deve acontecer sempre, mas a relao com o nmero de instrues dependente da dimenso da rede. Assim, para redes com dimenses menores que 4x4 esse fenmeno deve acontecer com uma quantidade de instrues

48
menor que 32, e para dimenses maiores com uma quantidade ainda maior. No incio da curva da execuo paralela, quando a quantidade de instrues pequena, h pouca ou nenhuma vantagem da estratgia paralela em relao a sequencial, devido ao overhead provocado pela comunicao e sincronismo entre os pacotes, entretanto a medida que a quantidade de instrues cresce a vantagem torna-se mais visvel. Os dois modelos de roteamento apresentaram comportamentos semelhantes, segundo os dados mostrados na Figura 5.7. As diferenas na quantidade de ciclos podem ser observadas nas Tabela 5.3 e Tabela 5.4 que nos trazem esses valores fornecendo uma comparao entre as duas abordagens. Como possvel observar, os valores para a estratgia sequencial diferem indicando um leve ganho para o roteamento em Ziguezague, enquanto que a estratgia paralela obteve os mesmos resultados em ambos.
Figura 5. 7 Comparao do tempo de execuo: Contador Sequencial versus Contador Paralelo na IPNoSys (a) Spiral Complement e (b) Zigue-zague

(a) Spiral Complement

(b) zigue-zague Fonte: Prprio autor

Tabela 5.3 Comparao do tempo de execuo: Spiral complement versus Zigue-zague, contador sequencial Spiral complement Zigue-zague 8 289 283 16 476 467 32 811 799 64 1483 1471 128 2827 2815 256 5515 5503

Tabela 5.4 Comparao do tempo de execuo: Spiral complement versus Zigue-zague, contador paralelo Spiral complement Zigue-zague 8 249 249 16 291 291 32 375 375 64 543 543 128 879 879 256 1551 1551

Nesse ponto faz-se necessrio utilizar mtricas para avaliao do impacto da execuo localizada na carga nos canais entre os nodos. As mtricas utilizadas

49
correspondem a tempo mdio para transmisso de flits ( avcpf average cycles per flit ciclos por flit mdio), utilizao mdia de canais ( abw - average bandwidth) e taxa efetiva de transmisso de dados (thr) definidas em [TEDESCO, 2005]. A obteno do tempo mdio para transmisso de flits (avcpf) consiste em inicialmente no clculo do cpf (ciclos por flit) para cada pacote, que o tempo gasto para sua transmisso dividido pelo seu tamanho. Utilizaremos aqui a frmula encontrada em [TEDESCO, 2005] para esse clculo. Para comparao usando a mtrica citada acima, repetimos o teste realizado em [ARAJO, 2012] utilizando apenas as simulaes com 256 instrues nas duas estratgias de execuo (sequencial e paralela), para os dois tipos de roteamento. As Figuras 5.8 e 5.9 apresentam os grficos do tempo mdio de transmisso, em ciclos, nas estratgias de execuo sequencial e paralela, respectivamente.
Figura 5.8 Tempo mdio de transmisso em ciclos para os roteamentos (a) Spiral complement e (b) em Zigue-zague para contador sequencial

Fonte: Prprio autor

Figura 5.9 Tempo mdio de transmisso em ciclos para os roteamentos (a) Spiral complement e (b) em Zigue-zague para contador paralelo

Fonte: Prprio autor

Essa medida corresponde ao tempo mdio de transmisso das palavras de todos

50
os pacotes que passaram pelo canal em ambos os sentidos. Portanto, os valores esto relacionados ao enlace entre dois nodos, sejam eles no eixo horizontal ou vertical. Para cada grfico mostrada uma viso bidimensional da rede, exibindo todos os valores calculados nos enlaces entre os nodos correspondentes. Podemos perceber pelos grficos das Figuras 5.8 e 5.9 que nos dois modelos de roteamento, a verso paralela da aplicao obteve um tempo mdio, em geral, menor, indicando que pacotes menores na composio da aplicao podem ser eficazes na diminuio do tempo mdio de transmisso. Porm, o roteamento em Zigue-zague ofereceu uma melhor distribuio nos enlaces da rede em ambas as verses da aplicao. Outra mtrica muito comum para avaliao do desempenho nas NoCs a utilizao mdia dos canais (abw) , que corresponde ao percentual de largura da banda utilizado pelos pacotes para transmisso de dados. A frmula para o clculo dessa mtrica est definida em [TEDESCO, 2005]. O grfico da utilizao mdia dos canais da implementao sequencial apresentado na Figura 5.10 e da implementao paralela na Figura 5.11, em ambos os casos o valor mximo que pode ser alcanado 1, que representa 100%. Na implementao sequencial os nicos canais que apresentam valores so aqueles que fazem parte da rota (ou espiral) iniciada na MAU (0,0) de acordo com o algoritmo de roteamento vigente. Nesses canais, a utilizao feita em um nico sentido durante quase todo o tempo de execuo da aplicao, por isso os valores so em torno de 0,5 (50%). Na verso paralela usando o roteamento Spiral complement (Figura 5.11 - (a)) percebe-se que h utilizao dos canais da periferia da rede em ambos os sentidos na maior parte do tempo, quando os valores ficam aproximados a 1 (100%), enquanto os canais centrais, quando so usados, so em apenas um dos sentidos. Com o roteamento em Zigue-zague (Figura 5.11 (b)) h aproveitamento de todos os canais centrais da rede. No entanto, segundo [TEDESCO, 2005], o clculo da utilizao mdia dos canais pode ser superestimado em redes que utilizam o mecanismo wormhole (IPNoSys usa uma combinao wormhole com VCT). Isso pode acontecer, uma vez que, no mecanismo wormhole, quando um canal alocado para transmisso de um pacote, ele permanece indisponvel para transmisso de outros pacotes at o final da transmisso do primeiro, como acontece no sistema IPNoSys. Assim, para representar com maior preciso o volume de trfego dos canais, podemos usar a mtrica de taxa efetiva de transmisso de dados (thr). A taxa efetiva corresponde ao nmero de bits de todas as palavras transmitidas durante o tempo de transmisso no canal [ARAJO, 2012]. O clculo dessa

51
mtrica utiliza a frmula indicada em [TEDESCO, 2005].
Figura 5.10 Utilizao mdia dos canais para os roteamentos (a) Spiral complement e (b) em Zigue-zague para contador sequencial

Fonte: Prprio autor

Figura 5.11 Utilizao mdia dos canais para os roteamentos (a) Spiral complement e (b) em Zigue-zague para contador paralelo

Fonte: Prprio autor

A comparao entre a taxa efetiva na execuo sequencial e na execuo paralela pode ser feita por meio dos grficos das Figuras 5.12 e 5.13. Na abordagem sequencial, representada pela Figura 5.12 (a), vemos que a taxa efetiva praticamente uniforme para os canais usados na primeira espiral do algoritmo Spiral complement. O mesmo ocorre para o roteamento em Zigue-zague exceto para um dos enlaces cuja taxa o dobro das outras, como visto na Figura 5.12 (b). J a aplicao paralela obteve maiores valores para os enlaces mais externos da IPNoSys Spiral complement, como visto na Figura 5.13 (a), enquanto o roteamento em Zigue-zague distribuiu a carga nos enlaces.

52
Figura 5. 12 Taxa efetiva de transmisso para os roteamentos (a) Spiral complement e (b) em Zigue-zague para contador sequencial

Fonte: Prprio autor

Figura 5. 13 Taxa efetiva de transmisso para os roteamentos (a) Spiral complement e (b) em Zigue-zague para contador paralelo

Fonte: Prprio autor

5.2

Caso de teste 2 Canais virtuais

A idia de canal virtual em uma NoC permitir multiplexar no tempo pacotes de origens diferentes por um mesmo canal de sada, usado principalmente para evitar deadlocks. Na arquitetura IPNoSys so usados no mnimo 2 canais virtuais com o intuito de transmitir concorrentemente pacotes de tipos diferentes, os quais so roteados diferentemente. Na verdade, cada canal virtual de fato um buffer na entrada da RPU. Os pacotes de controle e pacotes interrompidos (aqueles que esto esperando E/S ou a execuo de uma funo) utilizam um canal virtual onde os pacotes so roteados atravs do roteamento XY tradicional sem execuo das instrues contidas neles e sempre so destinados para uma MAU [ARAUJO, 2012]. Os pacotes dos tipos controle, caller e interrompido so identificados atravs dos seus cabealhos pelas RPUs por onde trafegam. Enquanto os pacotes do tipo regular

53
trafegam pelo outro canal virtual, podendo ter suas instrues executadas em qualquer RPU do caminho e ter seus destinos alterados de acordo com o algoritmo de roteamento. As rotas criadas pelos algoritmos de roteamento e a possibilidade de concorrncia dos canais fsicos por pacote da mesma ou de outras rotas podem levar a situaes de iminente deadlock, os quais so tratados por execues localizadas. As execues localizadas podem exigir grandes buffers de resultados. O segundo tipo de experimento realizado foi implementado alterando-se a quantidade de canais virtuais disponveis para os pacotes regulares. Segundo [ARAUJO, 2012], quando existe mais que um canal virtual para pacotes regulares, durante a transmisso desses pacotes, cada rbitro do canal fsico verifica a disponibilidade, na sequncia, do primeiro ao ltimo canal, transmitindo o pacote no primeiro canal que esteja disponvel ou ativando a execuo localizada em ltimo caso. Para estes experimentos foram verificados: (i) a quantidade de instrues executadas em cada nodo, (ii) tempo mdio para transmisso, (iii) utilizao mdia dos canais, (iv) taxa efetiva de transmisso, (v) tempo de execuo e (vi) a estimao de potncia dissipada pelos buffers de entrada das RPUs. Na estimao de potncia usada nos experimentos, foi considerada apenas a potncia dos buffers, os quais provavelmente so os maiores responsveis pelo consumo global. Os valores de estimativa utilizados so explicados em [ARAJO, 2012]. Para avaliar o efeito da utilizao de vrios canais virtuais para os pacotes regulares, diversas simulaes foram realizadas com a mesma aplicao do contador apresentada na seo 5.1, variando-se a quantidade de canais virtuais. Assim como em [ARAUJO, 2012], tambm utilizamos a aplicao do contador em suas verses sequencial e paralela, variando a quantidade de instrues (8, 16, 32, 64, 128 e 256) executadas em instncias de IPNoSys com 1, 2, 3, e 4 canais virtuais para pacotes regulares, mantendo as dimenses da rede em 4x4 RPUs, todas configuradas para executar apenas 1 instruo por vez. Primeiramente foi observada a quantidade de instrues executadas em cada nodo (RPU ou MAU) nas verses sequenciais, destacando os valores mximos em cada instncia. A Figura 5.14 traz os valores de resultados do experimento para a IPNoSys com o roteamento Spiral complement e a Figura 5.15 traz os resultados para a IPNoSys com o roteamento em Zigue-zague. A anlise dos grficos nos indica que o objetivo de retardar a execuo localizada alcanado. Enquanto no roteamento Spiral complement, 32 instrues executadas com 1 ou 2 canais disponveis so o bastante para ocorrer execuo localizada, no roteamento

54
em Zigue-zague o evento ocorre apenas quando se tem apenas 1 canal virtual. O mesmo ocorre com 64 instrues e 2 canais virtuais.
Figura 5. 14 Nmero mximo de instrues executadas em um Nodo para o contador sequencial na IPNoSys Spiral complement

Fonte: Prprio autor

Figura 5. 15 Nmero mximo de instrues executadas em um Nodo para o contador sequencial na IPNoSys Zigue-zague

Fonte: Prprio autor

Para efeitos de comparao entre as duas verses da IPNoSys, a Tabela 5.5 traz os valores dos resultados dos testes. Cada valor foi representado no formato (<ValorSpiralcomplement> / <ValorZigue-zague>).

55

Tabela 5.5 Quantidade mxima de instrues executadas em um Nodo contador sequencial

# instrues 8 16 32 64 128 256 1 canal 3/3 3/3 18 / 17 50 / 49 114 / 113 241 / 241 2 canais 3/3 3/3 14 / 4 46 / 21 110 / 85 238 / 213 3 canais 3/3 3/3 4/4 25 / 6 89 / 57 217 / 185 4 canais 3/3 3/3 4/4 6/6 49 / 29 177 / 157

A Figura 5.16 traz os valores de resultados do experimento utilizando a aplicao do contador paralelo para a IPNoSys com o roteamento Spiral complement e a Figura 5.17 traz os resultados para a IPNoSys com o roteamento em Zigue-zague.
Figura 5. 16 Nmero mximo de instrues executadas em um Nodo para o contador paralelo na IPNoSys Spiral complement

Fonte: Prprio autor

Na verso paralela do contador, com 4 fluxos de execuo, o comportamento das instncias da arquitetura comea a se diferenciar apenas na implementao com 64 instrues, nas duas verses de roteamento. Tambm para que pudssemos comparar as duas verses da IPNoSys, a Tabela 5.6 traz os valores dos resultados dos testes. Cada valor foi representado no formato (<ValorSpiralcomplement> / <ValorZigue-zague>).

56
Figura 5. 17 Nmero mximo de instrues executadas em um Nodo para o contador paralelo na IPNoSys Zigue-zague

Fonte: Prprio autor

Tabela 5.6 Quantidade mxima de instrues executadas em um Nodo contador paralelo

# instrues 8 16 32 64 128 256 1 canal 8/5 6/7 6/7 16 / 22 40 / 38 64 / 70 2 canais 5/5 6/7 7/7 8/8 38 / 23 102 / 69 3 canais 5/5 6/7 7/7 8/8 20 / 12 56 / 56 4 canais 5/5 6/7 7/7 8/8 12 / 12 58 / 46

Com o aumento dos canais virtuais a execuo localizada acontece mais tarde, e com isso os buffers de resultados acabam sendo menos utilizados, entretanto isso no garante que o tempo de transmisso dos pacotes seja reduzido. Pelo contrrio, como aumenta a disputa pelos canais fsicos, existe mais espera para cada canal virtual transmitir [ARAJO, 2012], como pode ser visto no grfico das Figura 5.18 e 5.19.

57
Figura 5. 18 Tempo Mdio para transmisso de Palavras para o Contador Sequencial (a) Spiral complement e (b) Zigue-zague
Fonte: Prprio autor

Figura 5. 19 Tempo Mdio para transmisso de Palavras para o Contador Paralelo (a) Spiral complement e (b) Zigue-zague

Fonte: Prprio autor

Nessas figuras possvel notar a tendncia crescente no tempo mdio de transmisso das palavras, seguindo o aumento do nmero de instrues. importante perceber que com o roteamento em Zigue-zague inicialmente temos um decrscimo, mas com o aumento do nmero de canais virtuais o aumento do tempo ocorre do mesmo jeito. Considerando a mdia de utilizao dos canais, com o aumento dos canais virtuais, h mais opes de pacotes para transmitir, assim o canal utilizado por mais tempo, e consequentemente o percentual de utilizao dos canais aumentado. As Figuras 5. 20 e 5.21 correspondem a utilizao mdia dos canais para o contador sequencial e para o contador paralelo, respectivamente.

58
Figura 5.20 Utilizao Mdia dos Canais para o Contador Sequencial (a) Spiral complement e (b) Zigue-zague

Fonte: Prprio autor

Figura 5.21 Utilizao Mdia dos Canais para o Contador Paralelo (a) Spiral complement e (b) Zigue-zague

Fonte: Prprio autor

O aumento de canais virtuais tambm multiplica a taxa efetiva de transmisso de maneira progressiva como podemos observar nas Figuras 5.22 e 5.23.
Figura 5.22 Taxa efetiva de transmisso usando Contador Sequencial (a) Spiral complement e (b) Zigue-zague

Fonte: Prprio autor

59

Figura 5.23 Taxa efetiva de transmisso usando Contador Paralelo (a) Spiral complement e (b) Zigue-zague

Fonte: Prprio autor

As Figuras 5.24 e 5.25 trazem grficos contendo os valores obtidos do tempo de execuo, em ciclos, para as aplicaes sequencial e paralela. Pode-se observar que o aumento de canais virtuais causam um pequeno acrscimo no tempo de execuo da aplicao sequencial, mas a abordagem paralela no apresenta qualquer diferena. Figura 5.24 Tempo de execuo para o Contador Sequencial (a) Spiral complement e (b) Zigue-zague

Fonte: Prprio autor

Figura 5.25 Tempo de execuo para o Contador Paralelo (a) Spiral complement e (b) Zigue-zague

60
O aumento do nmero de canais virtuais tambm produz um impacto direto na potncia nos buffers de entrada. At um determinado nmero de instrues, o valor mantm-se igual para a IPNoSys com diferentes quantidades de canais virtuais. A um certo ponto, esse valor comea a aumentar, tanto para a implementao sequencial quanto a paralela. Os grficos das Figuras 5.26 e 5.27 mostram os valores mdios em mW da potncia nos buffers de entrada. Os valores apresentados na execuo em paralelo chegam a sofrer uma reduo de at 95%, em relao aos valores da execuo em sequencial.
Figura 5.26 Potncia nos buffers de entrada usando Contador Sequencial (a) Spiral complement e (b) Zigue-zague

Fonte: Prprio autor

Figura 5.27 Potncia nos buffers de entrada usando Contador Paralelo (a) Spiral complement e (b) Zigue-zague

Fonte: Prprio autor

Obtivemos tambm os valores mdios em mW da potncia dos buffers de resultado dos rbitros. Estes valores esto apresentados nos grficos das Figuras 5.28 e 5.29.

61
Figura 5.28 Potncia nos buffers dos rbitros, Contador Sequencial (a) Spiral complement e (b) Zigue-zague

Fonte: Prprio autor

Figura 5.29 Potncia nos buffers dos rbitros, Contador Paralelo (a) Spiral complement e (b) Zigue-zague

Fonte: Prprio autor

Como se observa nesses grficos, os valores relativos potncia dos buffers de entrada da RPUs so proporcionalmente maiores que os valores de potncia dissipada pelos buffers de resultados nos rbitros. Nota-se ainda pouca variao nos valores entre as implementaes sequenciais e paralelas. [ARAJO, 2012] explica que isso se deve ao fato de que, independente de acontecer execuo localizada, o resultado de uma instruo executada em uma RPU ser armazenado no buffer de resultados at que seja o momento da sua transmisso no pacote. Desse modo, a quantidade total de potncia determinada pela quantidade de buffers de entrada nas RPUs e pela potncia dissipada por eles. Assim, tanto nas implementaes sequenciais quanto nas paralelas as diferenas entre as instncias da IPNoSys, variando-se a quantidade de canais virtuais, mantida proporcional ao grfico dos buffers de entrada, como mostram as Figuras 5.30 e 5.31.

62
Figura 5.30 Potncia Total, Contador Sequencial (a) Spiral complement e (b) Zigue-zague

Fonte: Prprio autor

Figura 5.31 Potncia Total, Contador Paralelo (a) Spiral complement e (b) Zigue-zague

Fonte: Prprio autor

Tomando-se uma situao particular, pode-se perceber a diferena entre os dois algoritmos de roteamento. Foram tomados os valores de simulaes com aplicaes contendo 64 instrues, nas abordagems sequencial e paralela, fixando o nmero de canais virtuais disponveis para os pacotes regulares em 3, e foi verificado o desempenho do sistema utilizando os dois tipos de roteamentos. O resultado obtido para o contador sequencial apresentado na Figura 5.32. Note-se que o pico no grfico corresponde execuo na IPNoSys com roteamento Spiral complement e corresponde a um valor discrepante em relao aos outros, no obstante a disponibilidade de mais canais virtuais. Diferente do que acontece com o roteamento original, o roteamento em Zigue-zague oferece uma melhor distribuio. Como visto nos testes anteriores, a distribuio da tarefa de computao e de comunicao implica em um aumento da potncia. A Tabela 5.7 mostra os valores de potncia, ciclos de execuo e utilizao mdia dos recursos do sistema.

63
Figura 5.32 3 canais virtuais, 64 instrues em sequencial

A Tabela 5.7 indica que o algoritmo em Zigue-zague apresentou uma leve perda de desempenho e tambm um aumento do consumo.
Tabela 5.7 3 canais virtuais, 64 instrues em sequencial - mtricas

Mtrica Consumo nos rbitros Consumo nos Buffers Consumo Total Utilizao Mdia Nmero de Ciclos

Spiral complement 0.00768 3.04769 3.05537 18.3613 % 1547

Zigue-zague 0.00768 3.38873 3.39641 20.2632 % 1577

A Figura 5.33 traz os valores para a execuo da mesma aplicao em sua abordagem sequencial. Mais uma vez o algoritmo em Zigue-zague permitiu uma melhor distribuio das tarefas execuo e comunicao dentro da rede. Analisando os dados presentes na Tabela 5.8, notamos que, diferentemente da abordagem sequencial, a execuo em paralelo no apresentou perda de desempenho e tambm ofereceu uma pequena reduo no consumo, quando comparado execuo com o algoritmo Spiral complement.

64
Figura 5.33 3 canais virtuais, 64 instrues em paralelo

Tabela 5.8 3 canais virtuais, 64 instrues em paralelo mtricas

Mtrica Consumo nos rbitros Consumo nos Buffers Consumo Total Utilizao Mdia Nmero de Ciclos

Spiral complement 0.00768 1.07305 1.08073 19.1989 % 543

Zigue-zague 0.00768 1.06368 1.07136 18.8029 % 543

65

Consideraes finais
Os avanos da tecnologia na produo de circuitos integrados vem permitindo a

produo de sistemas completos em uma nica pastilha de silcio. A integrao de diversos componentes heterogneos e a quantidade de comunicao necessria para gerenciar o processamento nesses sistemas abrem espao a pesquisa de anlise da viabilidade de diferentes abordagens de comunicao. As redes em chip aparecem como uma soluo promissora e suas implicaes de projeto direcionam as pesquisas a resoluo de problemas com carter distribudo. Decises de projeto envolvem diversos aspectos a serem considerados e analisados exaustivamente. Os testes realizados neste trabalho identificam caractersticas importantes no estudo de viabilidade de desenvolvimento da IPNoSys. O primeiro ponto que a se ressaltar a natureza paralela da arquitetura. Na realizao dos testes dispondo de quatro pontos de injeo de pacotes na rede IPNoSys, obteve-se melhores resultados. A possibilidade de explorao do paralelismo em nvel de pacotes pode trabalhar junto com um algoritmo de roteamento que possibilite uma melhor distribuio da execuo entre os ncleos, permitindo alcanar uma significativa melhora no desempenho. No se pode excluir desse conjunto os enlaces da rede que tambm so uma varivel importante na construo de uma arquitetura eficiente. possvel notar que o roteamento possui uma influncia direta sobre a distribuio de comunicao dentro da rede. Apesar de representar um aumento do consumo, em alguns casos, pode-se buscar um justo equilbrio entre custo e eficincia. Algoritmos de roteamento diferenciados podem se adequar a projetos especficos que exijam maior eficincia em detrimento do consumo. A partir dos resultados obtidos, uma melhor distribuio no uso dos recursos da IPNoSys pode ser alcanada utilizando-se o algoritmo de roteamento em Zigue-zague. Essa melhoria relativa comparao com o algoritmo de roteamento Spiral complement usado na IPNoSys original. Analisando os experimentos sob a tica da execuo localizada pode-se considerar o fato de que ela pode, em determinadas situaes, diminuir o tempo de execuo dos programas. Porm, isso no deve ser motivo para acomodao e importante encontrar diferentes caminhos que explorem o paralelismo da IPNoSys, sem que isso acarrete em custos elevados de potncia e comunicao. Algoritmos de roteamento nodeterminsticos podem ser o caminho para isso. Vale tambm ressaltar que a situao de deadlock no permite que a utilizao da IPNoSys como mquina dataflow. Uma IPNoSys

66
dataflow tem sua eficincia ligada diretamente ao bom aproveitamento de todos os recursos disponveis na rede. Os testes realizados com variao do nmero de canais virtuais indicam que a utilizao desse mecanismo deve ser uma deciso de projeto baseada em bastante cautela, dado que o aumento excessivo da potncia dissipada pode inviabilizar o projeto. Os buffers so tambm recursos limitados e devem ser considerados como tal, para que o aumento da carga no venha gerar situaes inesperadas. Salvo esses cuidados, pode-se explorar o uso de canais virtuais para implementar diferentes instncias de arquitetura IPNoSys. O roteamento em Zigue-zague pode ser um aliado dos canais virtuais na tarefa de adiar a execuo localizada, visto que o seu comportamento determinstico nos permite prever o momento em que um pacote vai colidir com outro pacote ou consigo mesmo. Aumento em valores dos testes para mtricas, como tempo mdio de transmisso, taxa efetiva de transmisso e utilizao mdia dos canais, indicam uso maior dos recursos de comunicao da rede quando se utiliza o rotemanto em Zigue-zague. Isso reflexo direto do adiamento da execuo localizada, permitindo que o pacote percorra um caminho maior. A imprevisibilidade dos tipos de programas que podem rodar em um dado momento em um processador no nos permite fazer escolhas determinsticas para uma arquitetura como a IPNoSys. Assim, dentro de uma perspectiva de desenvolvimento da IPNoSys, muitas ideias podem ser trabalhadas. Entre elas, tem-se a possibilidade de um algoritmo de roteamento adaptativo que possibilite uma maior explorao dos recursos da rede, independente do tamanho e do tipo de programa que esteja em execuo. Um outro possvel trabalho seria um algoritmo de roteamento com rotas que se sequenciam, permitindo que o programa percorra o maior nmero de RPUs possvel. Rotas inversas podem ainda permitir que uma mquina IPNoSys Dataflow (como a mostrada no Captulo 4, onde a execuo ocorre em duas etapas: programao e execuo em si) seja desenvolvida com paralelismo em nvel de instruo e tambm de pacotes, bastando para isso haver canais bilaterais e com memorizao independente da instruo. Dois programas com dados diferentes poderiam trafegar em caminhos opostos sem que um interfira na execuo do outro. Dado que nem todos os recursos da IPNoSys foram explorados nos testes aqui apresentados, trabalhos futuros podem ainda analisar o impacto do roteamento em Ziguezague ou mesmo de um novo roteamento em diversos aspectos dessa arquitetura, como por exemplo o acesso memria, o nmero de instrues executadas por RPU e a

67
utilizao dos recursos de I/O.

68

Referncias
ARAJO, S. R. F. Estudo da viabilidade do desenvolvimento de sistemas integrados baseados em redes em chip sem processadores: sistemas IPNoSys. Natal, RN: 2008. 88 f. Dissertao (Mestrado) - Universidade Federal do Rio Grande do Norte. Centro de Cincias Exatas e da Terra. Programa de Ps-Graduao em Sistemas e Computao. ARAJO, S. R. F. Projeto de sistemas integrados de propsito geral baseados em redes em chip - expandindo as funcionalidades dos roteadores para execuo de operaes: a plataforma Ipnosys. Natal, RN: 2012. 164 f. Tese (Doutorado) - Universidade Federal do Rio Grande do Norte. Centro de Cincias Exatas e da Terra. Programa de Ps-Graduao em Sistemas e Computao. BENINI, L.; DE MICHELI, G. Networks on Chips: A New SOC Paradigm. Computer, v. 35, 2002. p.70-78. CARDOZO, R.S. redes em chip de Baixo Custo, Mestrado, Instituto de Informtica Universidade Federal do Rio Grande do Sul, Porto Alegre, RS, Brasil. 2005. FERNANDES, S. R.; SILVA S. I.; KREUTZ, M. Packet-driven General Purpose Instruction Execution on Communication-based Architectures. JICS - Journal of Integrated Circuits and Systems, vol. 5, p. 14, 2010. LZARO, P. A. Concepo de um MPSoC de processadores Java utilizando NoC como mecanismo de comunicao. Fortaleza, CE: 2011. 50f. Monografia (Graduao) Universidade Federal do Cear. Departamento de Engenharia e Teleinformtica. NI, L. M.; McKINLEY, P. K. A Survey of Wormhole Routing Techniques in Direct Networks . IEEE Computer Magazine, [S.l.], v.26, n.2, p.62-76, Feb. 1993. NOBRE, C. de A. Proposta de um Modelo de Execuo Orientado a Dados para a Arquitetura de Rede em Chip IPNoSys. Natal, RN: 2012. 56 f. Tese (Mestrado) Universidade Federal do Rio Grande do Norte. Centro de Cincias Exatas e da Terra. Programa de Ps-Graduao em Sistemas e Computao. REGO, Rodrigo Soares de Lima S. Projeto e implementao de uma plataforma MP-SoC usando SystemC. Natal, RN: 2006. 141 f. Dissertao (Mestrado) - Universidade Federal do Rio Grande do Norte. Centro de Cincias Exatas e da Terra. Programa de PsGraduao em Sistemas e Computao. TEDESCO, L. P. Uma proposta para gerao de trfego e avaliao de desempenho para NoCs. 2005. 126 Mestrado (Mestrado). Pontifcia Universidade Catlica do Rio Grande do Sul, Porto Alegre. ZEFERINO, C. A. Introduo s redes em chip . In: GNTZEL, Jos; FRANCO, Denis; REIS, Ricardo.. (Org.). V Escola de Microeletrnica Sul (livro texto). Porto Alegre: SBC, 2003, v. , p. 93-104. ZEFERINO, C. A. redes em chip: arquiteturas e modelos para avaliao de rea e desempenho. Tese (Doutorado) Universidade Federal Rio Grande do Sul, Porto Alegre, Brasil, 2003.

69

Anexo I Resultados numricos de testes

Caso de teste 1 Preveno a deadlock
C1a Algoritmo Spiral complement, contador sequencial, nmero de instrues por RPU
RPU # instrues 0,0 8 3 16 3 32 3 64 3 128 3 256 3 0,1 1 1 1 1 1 1 0,2 1 1 1 1 1 1 0,3 1 1 1 1 1 1 1,0 0 1 1 1 1 1 1,1 0 1 1 1 1 1 1,2 0 1 1 1 1 1 1,3 1 1 1 1 1 1 2,0 0 1 1 1 1 1 2,1 0 0 0 0 0 0 2,2 0 1 1 1 1 1 2,3 1 1 1 1 1 1 3,0 0 1 1 1 1 1 3,1 0 1 1 1 1 1 3,2 1 2 8 50 114 241 3,3 1 1 1 1 1 1

C1a - Representao grfica

C1b Algoritmo em zigue-zague, contador sequencial, nmero de instrues por RPU

RPU # instrues 8 16 32 64 128 256

0,0 3 3 17 49 113 241

0,1 1 1 1 1 1 1

0,2 1 1 1 1 1 1

0,3 1 1 1 1 1 1

1,0 1 1 2 2 2 2

1,1 1 1 1 1 1 1

1,2 1 1 1 1 1 1

1,3 1 1 1 1 1 1

2,0 0 1 2 2 2 2

2,1 0 1 1 1 1 1

2,2 0 1 1 1 1 1

2,3 0 1 1 1 1 1

3,0 0 1 1 1 1 1

3,1 0 1 1 1 1 1

3,2 0 1 1 1 1 1

3,3 0 1 1 1 1 1

70
C1b - Representao grfica

C1c Algoritmo Spiral complement, contador paralelo, nmero de instrues por RPU
RPU # instrues 0,0 8 5 16 6 32 7 64 7 128 32 256 64

0,1 1 2 3 4 2 2

0,2 1 2 3 3 3 2

0,3 2 3 4 14 29 61

1,0 0 0 2 2 2 2

1,1 0 0 0 1 0 0

1,2 0 0 0 0 0 0

1,3 0 0 2 3 2 2

2,0 0 0 2 2 2 2

2,1 0 0 0 1 0 0

2,2 0 0 0 1 0 0

2,3 0 0 2 3 2 2

3,0 2 3 5 13 29 61

3,1 1 2 2 2 2 2

3,2 1 2 2 2 2 2

3,3 2 3 5 13 29 61

C1c - Representao grfica

71
C1d Algoritmo em zigue-zague, contador paralelo, nmero de instrues por RPU
RPU # instrues 8 16 32 64 128 256

0,0 5 7 7 22 38 70

0,1 1 2 3 2 2 2

0,2 1 2 3 2 2 2

0,3 2 4 4 16 32 64

1,0 0 1 3 2 2 2

1,1 0 0 3 2 2 2

1,2 0 0 3 2 2 2

1,3 0 1 3 3 21 53

2,0 1 1 1 2 2 2

2,1 0 0 1 2 2 2

2,2 0 0 1 2 2 2

2,3 1 1 1 3 2 2

3,0 2 2 2 3 3 3

3,1 0 0 1 2 20 52

3,2 0 0 1 2 1 1

3,3 2 2 2 4 2 2

C1d - Representao grfica