UNIVERSIDADE DO VALE DO ITAJAÍ PRÓ-REITORIA DE PÓS-GRADUAÇÃO, PESQUISA, EXTENSÃO E CULTURA PROGRAMA DE MESTRADO ACADÊMICO EM COMPUTAÇÃO APLICADA

Transcrição

1 UNIVERSIDADE DO VALE DO ITAJAÍ PRÓ-REITORIA DE PÓS-GRADUAÇÃO, PESQUISA, EXTENSÃO E CULTURA PROGRAMA DE MESTRADO ACADÊMICO EM COMPUTAÇÃO APLICADA PLATAFORMA PARA AVALIAÇÃO DE DESEMPENHO DE REDE-EM-CHIP EM FPGA Dissertação de Mestrado por Magnos Roberto Pizzoni Cesar Albenes Zeferino, Dr. Orientador São José (SC), Dezembro de 2010

2 UNIVERSIDADE DO VALE DO ITAJAÍ PRÓ-REITORIA DE PÓS-GRADUAÇÃO, PESQUISA, EXTENSÃO E CULTURA PROGRAMA DE MESTRADO ACADÊMICO EM COMPUTAÇÃO APLICADA PLATAFORMA PARA AVALIAÇÃO DE DESEMPENHO DE REDE-EM-CHIP EM FPGA por Magnos Roberto Pizzoni Relatório de Dissertação a ser apresentada como requisito parcial à obtenção do grau de Mestre em Computação Aplicada. Orientador: Cesar Albenes Zeferino, Dr. São José (SC), Dezembro de 2010

3 FOLHA DE APROVAÇÃO ii

4 AMirtes, minha amada, que me acompanhou desde os primeiros passos nessa desconhecida e longa jornada. Com todo meu amor eu agradeço a ela. iii

5 Bendito quem inventou o belo truque do calendário, pois o bom da segunda-feira, do dia 1º do mês e de cada ano novo é que nos dão a impressão de que a vida não continua, mas apenas recomeça. Mário Quintana iv

6 AGRADECIMENTOS Muitas pessoas colaboraram de alguma maneira para a conclusão dessa dissertação de mestrado. Começo agradecendo a minha família, que acreditou em mim e serviu de base e exemplo de determinação, meu pai (Seu Valmir), minha mãe (Dona Santina), meu irmão (Maurício), a Mirtes, que é meu grande amor, a minha Sogra, Sogro, cunhados e cunhados, enfim, agradeço a todos os meus familiares. Agradeço ao meu orientador, Professor Doutor Cesar Albenes Zeferino, pela paciência de um verdadeiro mestre, pelas inúmeras explicações e discussões até provar que o erro era mesmo meu e não dos sistemas. Também agradeço, em ordem alfabética, aos meus colegas de aula e laboratório, ao Douglas, João Camargo, Kazuo, Marcos, Rodrigo e Thiago, pelas vezes que me socorreram sempre que precisei ou pelas conversas dos mais variados assuntos. Agradeço a Dona Lurdes, responsável pela secretaria do curso, que sempre esteve disposta em nos auxiliar e agradeço também ao CNPq (Conselho Nacional de Desenvolvimento Científico e Tecnológico) pelo auxílio financeiro para a realização deste trabalho. Muito Obrigado! v

7 SUMÁRIO LISTA DE FIGURAS...viii LISTA DE TABELAS...ix LISTA DE QUADROS... x RESUMO...xii ABSTRACT...xiii 1 INTRODUÇÃO PROBLEMA DE PESQUISA Solução Proposta OBJETIVOS Objetivo Geral Objetivos Específicos ESTRUTURA DA DISSERTAÇÃO FUNDAMENTAÇÃO TEÓRICA REDES-EM-CHIP Interconexão em sistemas integrados em um único chip Características de NoCs Topologia Estratégias de Roteamento Chaveamento Controle de Fluxo Memorização Arbitragem Estudo de caso: SoCIN (System-on-Chip Interconnection Network) MODELO DE GERAÇÃO DE TRÁFEGO Padrões para distribuição espacial de tráfego Categoria de serviços Modelos de serviços AVALIAÇÃO DE DESEMPENHO DE NOCS Avaliação do desempenho da rede SPIN Avaliação do desempenho da rede QNoC Avaliação do desempenho da rede HERMES ESTADO DA ARTE DA AVALIAÇÃO DE DESEMPENHO ON-CHIP Genko et al. (2005) Wolkotte, Hölzenspies e Smit (2007) Wang, Jerger e Steffan (2010) DISCUSSÃO vi

8 3 PROJETO DA PLATAFORMA PARA AVALIAÇÃO DE DESEMPENHO ON-CHIP DA REDE SOCIN VISÃO GERAL COMPONENTES DE HARDWARE PARA EXECUÇÃO DOS EXPERIMENTOS Bloco de controle da emulação - ECB Núcleos de geração e de medição de tráfego TG e TM COMPONENTES DE HARDWARE E DE SOFTWARE PARA CONFIGURAÇÃO DA PLATAFORMA O Software Supervisor Módulo de Comunicação e de Controle IMPLEMENTAÇÃO E VALIDAÇÃO Supervisor e Driver CCM Integração de hardware e de software CONCLUSÃO...84 REFERÊNCIAS BIBLIOGRÁFICAS...86 vii

9 LISTA DE FIGURAS Figura 1. Arquitetura genérica de um SoC...20 Figura 2. Interconexão de modelo ponto-a-ponto...21 Figura 3. Interconexão multiponto (ou barramento)...21 Figura 4. Exemplos de topologia: (a) em malha; (b) toróide ou torus; (c) hipercubo...24 Figura 5. Topologia em malha 2-D da rede SoCIN...33 Figura 6. Topologia em malha 2-D, representando os endereços dos nodos em forma binária segundo um sistema de coordenadas XY (X = coluna, Y = linha)...35 Figura 7. Modelo de sistema para comparação do desempenho SPIN x PI-Bus: (a) requisição dos geradores de tráfegos; (b) respostas dos destinos aos iniciadores...41 Figura 8. Avaliação da escalabilidade das arquiteturas de comunicação através da análise da latência...41 Figura 9. Fluxo de projeto da QNoC...44 Figura 10. Carga Relativa dos enlaces da malha...46 Figura 11. Carga aplicada vs. latência média obtida...48 Figura 12. Topologia em malha bidirecional 3x3 da NoC HERMES...49 Figura 13. Arquitetura de emulação de NoC...51 Figura 14.Comparação de tráfego uniforme com tráfego em rajadas...52 Figura 15. Avaliação do tamanho da rajada...53 Figura 16. Visão esquemática do hardware...54 Figura 17. Modelo da arquitetura DART...56 Figura 18. Ilustração da organização dos componentes da plataforma...60 Figura 19. Direção do fluxo de projeto da plataforma desenvolvida...62 Figura 20. Ordem seqüencial de execução da plataforma...63 Figura 21. Organização simplificada do ECB...64 Figura 22. Descritor de Fluxo...65 Figura 23. Organização Simplificada do TG...66 Figura 24. Organização Simplificada do TM...66 Figura 25. Fluxo de projeto do Supervisor...68 Figura 26. Pacote do traffic.bst Figura 27. Organização interna do módulo CCM...75 Figura 28. Estrutura interna do caminho de dados do periférico (core)...76 Figura 29. Arquivo recebido pela RS-232 no formato Hexadecimal...77 Figura 30. Visão geral da simulação...79 Figura 31. Valores resultantes da emulação...81 Figura 32. Tempo previsto para a emulação...82 viii

10 LISTA DE TABELAS Tabela 1. Comparação entre as estruturas de interconexão mais utilizadas em SoCs e as NoCs...22 Tabela 2. Classificação dos Mecanismos de Roteamento Tabela 3. Relação de ligações entre nodos destino e origem...36 Tabela 4. Exemplo de ligação no Padrão de Tráfego utilizando coordenadas binárias...37 Tabela 5. Modelagem de tráfego - QNoC com freqüência de 1GHz Tabela 6. Latência média dos pacotes em função da largura de banda alocada. QoS desejado é marcado em itálico...47 Tabela 7. Caracterização de trabalhos sobre avaliação de desempenho de NoCs Tabela 8. Valores resultantes nas emulações comparados com os valores das simulações Tabela 9. Especificações dos arquivos traffic.mif e traffic.tcf...71 Tabela 10. Especificações dos comandos para execução dos experimentos...72 Tabela 11. Descrição dos campos de configuração do ECB...73 Tabela 12. Descrição dos campos dos descritores do TG...73 Tabela 13. Descrição dos campos coletados do TM...75 Tabela 14. Descrição dos valores coletados do TM...80 Tabela 15. Resultados da síntese de um sistema ix

11 LISTA DE QUADROS Quadro 1. Exemplo de arquivo traffic.tcf para uma rede 2x2 gerado pelo BrownPepper...69 Quadro 2. Exemplo de arquivo traffic.mif para uma rede 2x2 - apenas para o TG (0,0)...71 Quadro 3. Exemplo de arquivo de configuração traffic.bst...74 Quadro 4. Arquivo de configuração da Plataforma (valores em Hexadecimal)...78 Quadro 5. Resultados da simulação recolhidos pelos TMs (valores ilustrados em Hexadecimal)...80 x

12 LISTA DE ABREVIATURAS ABR CBR DMA FCFS Flit FPGA Gbps HDL HLP IP LRS LUT NoC OCP ParIS PHIT QoS RTL SoC SPIN TG TL TM TR UART UBR UNIVALI USB VBR VHDL VHSIC Available Bit Rate Constant Bit Rate Direct Memory Access First-Come-First-Served Flow Control Digit Field Programmable Gate Array Gigabits por segundo Hardware Description Language Higher Level Protocol Intellectual Property Least Recently Served Look-Up Table Network-on-Chip Open Core Protocol Parameterized Interconnection Switch Physical Unit Quality of Service Register Transfer Level System-on-Chip Scalable, Programmable Interconnect Network Traffic generator Transaction Level Traffic Meter Traffic receptor Universal Asynchronous Receiver/Transmitter Unspecified Bite Rate Universidade do Vale do Itajaí Universal Serial Bus Variable Bit Rate VHSIC Hardware Description Language Very High Speed Integrated Circuit xi

13 RESUMO PIZZONI, Magnos Roberto. Plataforma para Avaliação de Desempenho de Rede-em-Chip em FPGA. São José, f. Dissertação (Mestrado em Computação Aplicada) Programa de Mestrado Acadêmico em Computação Aplicada, Universidade do Vale do Itajaí, São José, Com a evolução dos processos de fabricação de circuitos, tem sido possível a integração de sistemas completos em um único chip, os quais são construídos utilizando-se blocos de silício reutilizáveis (núcleos). Com as novas tecnologias de integração, será possível construir sistema com várias dezenas a centenas de núcleos em um mesmo chip. Tais sistemas terão alto poder de processamento, mas irá requerer estruturas de comunicação reutilizáveis com desempenho escalável, o que não é possível de ser obtido com as arquiteturas usadas atualmente, baseadas no barramento. É consenso na comunidade acadêmica e na indústria que a melhor solução para esse problema é baseada em estruturas de interconexão com canais chaveados por roteadores as chamadas Redes-em-Chip ou NoCs (Networks-on-Chip). Atualmente, diversos grupos de pesquisa trabalham investigando diferentes aspectos sobre NoCs e a grande maioria desses trabalhos utiliza ambientes de simulação para exploração arquitetural e avaliação de desempenho. No entanto, em modelos detalhados e com precisão de ciclo, o tempo de simulação é bastante alto, o que limita a quantidade de ciclos a serem simulados. Após a validação e a avaliação baseada em simulação, usualmente, realiza-se a síntese da NoC em FPGA (Field Programmable Gate Array) para realizar a sua validação física. Para tal, é necessário construir um sistema com núcleos conectados à rede e que produzam o tráfego que permitam validar a arquitetura implementada. Este projeto insere-se nesse contexto e busca desenvolver uma infra-estrutura de apoio à pesquisa sobre NoCs por meio da disponibilização de geradores de tráfego sintetizáveis para validação física e para a avaliação de desempenho de NoCs em dispositivos do tipo FPGA. A idéia é que essa infra-instrutora facilite a validação da rede e a realização de experimentos de análise de desempenho mais rapidamente e com maior precisão do que aqueles realizados em ambientes de simulação. Neste trabalho, foram desenvolvidos componentes de hardware e de software para a construção da plataforma proposta. Palavras-chave: System-on-Chip. Network-on-Chip. Avaliação de desempenho. xii

14 ABSTRACT With the evolution of the circuit manufacturer processes is becoming possible to integrate complete systems in a single chip, which are built of reusable silicon-based blocks (cores). With the advent of new integration technologies, it will be possible to build a system with several tens to hundreds of cores in the same chip. Such systems will have a higher processing power, but will require reusable communication structures with scalable performance, which is not possible to be obtained with the current bus-based architectures. The consensus in the academic community and industry is that the best solution for this problem is based on interconnection architectures with switching channels by routers the so called chip-networks or NoCs (Networks-on-Chip). Nowadays, several groups of research investigate different aspects of NoCs and the majority of the work being done uses simulation environments for architectural exploration and performance evaluation. However, in detailed models with cycle precision, the simulation time is very high, limiting the amount of cicles to be simulated. After the validation and evaluation based on simulation, usually a test of syntheses of the NoC in FPGA (Field Programmable Gate Array) is performed for physical validation. Thus, its necessary to build a system with cores connected to the network and that produces traffic that allows validating the implemented architecture. This project is inserted in this context and aims to develop an infra-structure of support to the research on NoCs through the availability of synthesizable traffic generators for physical validation and for Performance evaluation of NoCs in FPGA type devices. The idea is that this infra-structure facilitates the network validation and the realization of more agile and accurate performance analysis experiments than of those made in simulation environments. Hardware and software components were implemented to be included in the platform, which is being integrated with other components developed in a previous work. Keywords: System-on-Chip. Network-on-Chip. Performance. xiii

15 1 INTRODUÇÃO A evolução dos processos de fabricação de circuitos tem criado possibilidades de integração de sistemas completos em um único chip, os quais são construídos utilizando-se blocos de silício reutilizáveis (núcleos ou IPs Intelectual Property blocks). Com as novas tecnologias de integração, será possível construir sistema com várias dezenas a centenas de núcleos em um mesmo chip. Tais sistemas terão alto poder de processamento, mas irá requerer estruturas de comunicação reutilizáveis com desempenho escalável, o que não é possível de ser obtido com as arquiteturas usadas atualmente, baseadas no barramento. É consenso na comunidade acadêmica e na indústria que a melhor solução para esse problema é baseada em estruturas de interconexão com canais chaveados por roteadores, as quais são chamadas de Redes-em-Chip ou NoCs (Networks-on-Chip) (HEMANI et al. 2000; BENINI; DE MICHELI, 2002). Atualmente, alguns grupos de pesquisa investigam diferentes aspectos sobre NoCs e a grande maioria desses trabalhos utiliza ambientes de simulação para exploração e validação arquitetural e para a avaliação de desempenho, como feito por Adriahantenaina et al. (2003), Bolotin et al. (2004), Ost (2004) entre outros. Nesse contexto, as redes podem ser modeladas e avaliadas no nível de transação (TL - Transaction Level) ou nível de transferência entre registradores (RTL - Register Transfer Level). O primeiro nível proporciona um melhor tempo de simulação, enquanto que o segundo oferece uma maior precisão nos resultados, dado que os componentes da rede já são modelados utilizando-se as estruturas equivalentes às usadas na implementação física (BLACK; DONOVAN, 2004). Dependendo da linguagem de descrição escolhida e do nível de abstração usado na modelagem da rede e dos componentes do sistema, o custo computacional da simulação pode tornar inviável uma avaliação que envolva muitos ciclos de execução do sistema, limitando a qualidade dos experimentos de avaliação de desempenho, seja pela restrição do tempo de simulação ou do número de experimentos realizados. Por exemplo, Zeferino et al. (2007) desenvolveram uma plataforma de avaliação de desempenho baseada em simulação para a rede SoCIN System-on-Chip Inteconnection Network,

16 uma NoC de baixo custo proposta por Zeferino e Susin (2003). Neste simulador, a NoC SoCIN foi modelada em SystemC, no nível RT. O simulador permite a avaliação e a comparação do desempenho de diferentes alternativas arquiteturais da rede SoCIN, porém, apresenta um custo computacional elevado (ou seja, tempo de execução) para a realização de cada experimento. 1.1 PROBLEMA DE PESQUISA Uma alternativa para o problema do custo computacional da avaliação de desempenho consiste em utilizar modelos sintetizáveis de redes e de geradores de tráfego (que emulem o tráfego gerado por componentes de sistemas reais) para realizar a avaliação de desempenho da rede em FPGA (Field Programmable Gate Array). Essa abordagem proporciona um ganho expressivo no tempo de avaliação, pois permite a execução de um número muito maior de ciclos de operação da rede em um mesmo intervalo de duração do experimento em relação à simulação. Além disso, como a avaliação é sobre o modelo sintetizável, esse tipo de experimento já permite a realização da validação física da rede. Alguns autores têm tratado dessa questão. Por exemplo, Genko, Atienza e De Micheli (2005) integraram uma rede completa em FPGA e obtiveram emulações até vezes mais rápidas que as simulações sobre modelos HDL. Já Wolkotte, Hölzenspies e Smit (2007) obtiveram ganhos menores (de 80 a 300 vezes) em relação à simulação SystemC, porém, na sua abordagem, os autores propuseram uma emulação seqüencial em que um único roteador da rede é implementado em FPGA e a plataforma emula redes maiores executando-as seqüencialmente. A vantagem, nesse caso, está na eliminação da restrição de capacidade de integração do FPGA usado, permitindo a emulação de redes de qualquer dimensão. Para que a avaliação de desempenho em hardware possa ser realizada, como foi feito nesses trabalhos, é preciso dispor de uma infra-estrutura composta por geradores e medidores de tráfego e por ferramentas (software) de apoio que automatizem as tarefas de configuração do tráfego, controle da execução dos experimentos, coleta dos dados medidos e análise desses dados Solução Proposta Como alternativa para diminuir o custo computacional da avaliação de desempenho da rede SoCIN, no segundo semestre de 2007, foram iniciados estudos para avaliar a viabilidade de implementação de uma plataforma baseada na emulação de tráfego aplicado a uma rede SoCIN 15

17 sintetizada em FPGA. Dois estudos preliminares foram realizados para avaliar, comparar e selecionar a melhor alternativa para implementação de geradores de tráfego sintetizáveis: uma baseada em processadores de propósito geral programáveis (GPP General Purpose Processor) e outra baseada em processadores de propósito único (SPP Single Purpose Processor), as quais são descritas a seguir. Frantz e Zeferino (2009) implementaram geradores de tráfegos baseados no processador PicoBlaze. Os resultados obtidos demonstraram a viabilidade do uso desta abordagem, porém, evidenciaram que a solução apresenta uma latência na criação dos fluxos produzidos pelo gerador de tráfego, pois a criação de cada pacote consome diversos ciclos do processador. Para lidar com o problema, é preciso que o processador opere a uma freqüência de relógio maior que a da rede. Pereira e Zeferino (2008), por outro lado, implementaram os geradores diretamente em hardware, como processadores de propósito específico. Os resultados demonstraram que a abordagem também é viável, com a vantagem de reduzir a latência na geração dos pacotes a poucos ciclos. Porém, a abordagem apresenta desvantagens quanto à pouca flexibilidade para alterações no gerador de tráfego quando comparado à solução baseada em software rodando em um processador de propósito geral. Neste contexto, o presente trabalho tem sua origem nesses estudos e busca desenvolver uma plataforma para avaliação de desempenho da rede SoCIN em FPGA utilizando geradores e medidores de tráfego implementados como processadores de propósito específico para maximizar o desempenho dos experimentos realizados na plataforma. A plataforma proposta originalmente por Pereira e Zeferino (2008), consiste de um computador executando um software de configuração de experimento e análise de resultados e um FPGA integrando um sistema composto por roteadores (blocos ParIS Parameterizable Interconnect Switch), geradores de tráfego (blocos TG Traffic Generator) e medidores de tráfego (blocos TM Traffic Meters). Além destes, outros blocos com funções distintas, são necessários para a comunicação entre o computador e o FPGA. 16

18 1.2 OBJETIVOS Objetivo Geral Disponibilizar uma plataforma em hardware para acelerar a exploração do espaço de projeto da rede SoCIN com avaliação de desempenho baseada em emulação Objetivos Específicos Desenvolver um referencial teórico como base de pesquisa envolvendo tecnologias e o estado da arte sobre avaliação de desempenho associadas ao projeto de SoCs baseado em NoCs ; Especificar a plataforma hardware/software para avaliação de desempenho de NoCs em FPGA; Desenvolver software de execução e análise de experimentos e integralizar com geradores de tráfegos e medidores de tráfegos; e Integrar os módulos que compõem a plataforma e validar os módulos através de teste de funcionalidade. 1.3 ESTRUTURA DA DISSERTAÇÃO O trabalho está organizado em cinco capítulos. O Capítulo 1 apresenta a introdução, a contextualização do assunto abordado nesse trabalho, o problema de pesquisa, a solução proposta, a especificação do objetivo geral e especificações dos objetivos específicos. O Capítulo 2 apresenta a fundamentação teórica necessária para esclarecimento dos conceitos abordados nesse trabalho, como por exemplo, modelos de arquiteturas de NoC, avaliação de desempenho e também é apresentado os resultados de alguns trabalhos que serviram como base para a aprimorar as técnicas de geração de tráfego e avaliação de desempenho em NoCs. O Capítulo 3 apresenta o desenvolvimento do trabalho elaborado. Nesse capítulo, são mostrados os procedimentos do desenvolvimento da plataforma de avaliação de desempenho de NoC implementada em hardware, mais especificamente em FPGA. Também nesse capítulo são 17

19 apresentadas a visão geral dessa plataforma e a descrição dos componentes, como por exemplo, os módulos de geradores de tráfego e os módulos de medidores de tráfego. O Capítulo 4 apresenta as conclusões alcançadas através do desenvolvimento dessa plataforma de avaliação de desempenho de NoC. Também é feito um comparativo dos objetivos citados no Capítulo 1 e uma avaliação dos resultados obtidos através dos experimentos relatados nesse trabalho. 18

20 2 FUNDAMENTAÇÃO TEÓRICA Neste capítulo, são apresentados conceitos sobre arquiteturas de NoCs e geração de tráfego para avaliação de desempenho de NoCs, assim como uma revisão do estado da arte das pesquisa relacionadas a esse tema. 2.1 REDES-EM-CHIP Primeiramente, é destacado o conceito de SoC (do inglês System-on-Chip) e sua necessidade de utilização de uma rede-em-chip em sua estrutura interna de conexão. A seguir, é feita uma explanação do conceito de redes-em-chip ou NoC (do inglês Network-on-Chip), sendo abordados assuntos referentes às topologias utilizadas, métodos de controle de fluxo, memorização e chaveamento Interconexão em sistemas integrados em um único chip Um sistema integrado ou SoC (do inglês, System-on-Chip) pode ser definido como um sistema computacional completo em um único chip (MELLO, 2003, p. 1). Um SoC consiste na integração de um grupo de módulos reutilizáveis comumente denominados núcleos (ou cores) com funcionalidades distintas. Por serem frutos de propriedade intelectual, os núcleos são também referenciados pelo termo blocos de IP ou, simplesmente, IP (de Intelectual Property, em inglês). A arquitetura genérica de um SoC é ilustrada na Figura 1. Pode-se notar que esta possui núcleos que podem ser módulos específicos, tais como decodificadores MPEG2 ou MPEG3, interfaces de comunicação Ethernet ou USB, dentre outros. A estrutura de interconexão tem como finalidade realizar a comunicação entre os núcleos e o resto do sistema. Nota-se a presença de interface com o mundo externo (E/S), que é utilizada para interconectar os periféricos, como porta serial, porta USB entre outros (MADISETTI; SHEN, 1997, p ). 19

21 Nucleo1 Núcleo2 Núcleo n Estrutura de Interconexão Memória Processador I N T E R F A C E E/S Figura 1. Arquitetura genérica de um SoC Fonte: Adaptado de Bastos (2006, p. 28). O principal objetivo do uso de núcleos no projeto de um SoC é a redução do tempo para o projeto (time-to-project) e do tempo para o lançamento do produto no mercado (time-to-market). No entanto, apesar das vantagens inerentes dessa abordagem, identificam-se quatro grandes problemas que devem ser resolvidos para que se possa construir facilmente um SoC: (i) como integrar núcleos entre si; (ii) quais linguagens para descrição de sistemas usar; (iii) como proteger a propriedade intelectual do autor e do usuário do núcleo; (iv) como testar projetos baseados em núcleos (MORAES et al., 2004, p. 2). Assim, vale salientar que há um movimento em pesquisas para o desenvolvimento de técnicas voltadas à implementação de soluções para a melhoria de desempenho dos SoCs e diminuição dos custos de produção incluindo o projeto do mesmo como por exemplo, trabalhos apresentados por Wang, Jerger e Steffan (2010), que mostra uma solução flexível para emulação de Rede-em-Chip implementada em FPGA e Genko et al (2005), que mostra um ambiente para avaliação de desenpenho de Rede-em-Chip baseado na emulação hardware-software. Neste trabalho, é direcionada uma atenção especial ao primeiro problema descrito anteriormente: Como integrar núcleos entre si?. Atualmente, os núcleos são interconectados em um SoC através de uma das seguintes abordagens: canais ponto-a-ponto dedicados e barramento (OST, 2004, p. 10). A primeira alternativa, ilustrada na Figura 2, é a que oferece o melhor desempenho, pois cada comunicação ocorre independentemente das demais por meio de canais exclusivos. Contudo, esta requer um projeto específico e, portanto, possui reusabilidade limitada. 20

22 Núcleo 1 Núcleo 2 Núcleo 3 Núcleo 4 Figura 2. Interconexão de modelo ponto-a-ponto Fonte: Adaptado de Bastos (2006, p. 29). Já na arquitetura multiponto, Figura 3, conhecida por barramento, a mesma estrutura pode ser reutilizada em diferentes sistemas, reduzindo o tempo de projeto (ZEFERINO, 2003, p.25). Contudo, apresenta desvantagens quanto ao desempenho, pois permite a realização de apenas uma comunicação por vez, serializando as comunicações entre os núcleos. Em outras palavras, a largura de banda do sistema é compartilhada entre os núcleos a estes conectados. Essa alternativa apresenta ainda outras restrições físicas decorrentes do crescimento do sistema: a capacitância de carga cresce com o número de núcleos e a capacidade das linhas do barramento aumenta com o comprimento dos fios. Isso leva a uma degradação da freqüência de operação dos canais e ao aumento do consumo de energia do sistema (SANTO; ZEFERINO, 2004, p. 11). Núcleo 1 Núcleo 2 Árbitro Núcleo 3 Núcleo 4 Figura 3. Interconexão multiponto (ou barramento) Fonte: Adaptado de Bastos (2006, p. 29). Conforme discutido na literatura (BENINI; De MICHELI, 2002), os futuros SoCs poderão integrar de várias dezenas a centenas de núcleos e irão requerer arquiteturas de comunicação reutilizáveis e com largura de banda escalável, cujo desempenho aumenta com o tamanho do sistema. Conforme descrito anteriormente, as arquiteturas ponto-a-ponto possuem baixa 21

23 reusabilidade e as arquiteturas multipontos possuem desempenho limitado. A Tabela 1 apresenta uma síntese comparativa das estruturas utilizadas para a interconexão dos núcleos em um SoC. Tabela 1. Comparação entre as estruturas de interconexão mais utilizadas em SoCs e as NoCs. Característica Estruturas de Interconexões Paralelismo Consumo de Energia por fio Fios Ponto-a-ponto dedicados Canais ponto-a-ponto dedicados As conexões ponto-a-ponto são independentes, logo, é possível haver paralelismo. Menor, se comparado ao barramento. Motivo: fios mais curtos Escalabilidade Projetado para uma situação especifica. Reusabilidade Reuso bastante restrito. Motivo: projetado para uma situação específica. Barramento Fios multi-ponto compartilhados Permite apenas uma comunicação por vez. Barramentos hierárquicos podem prover paralelismo, limitado ao número de barramentos independentes. Maior. Motivo: fios mais longos, além de aumento de carga capacitiva a cada núcleo acrescentado. Limitada a dezenas de núcleos. NoC Canais ponto-a-ponto compartilhados, chaveados por roteadores Comunicação também ponto-a-ponto, com paralelismo suportado. Menor, se comparado ao barramento. Motivo: Fios mais curtos. Novos núcleos não acrescentam a capacitâncias à estrutura de interconexão já existentes. Escalável através do acréscimo de mais chaves à rede. Totalmente reutilizável. Totalmente reutilizável. Fonte: Ost (2006, p. 22) Características de NoCs Uma NoC pode ser descrita por um conjunto de atributos que incluem a sua topologia e as técnicas utilizadas na comunicação entre os núcleos (roteamento, controle de fluxo, chaveamento, memorização e arbitragem). A topologia corresponde ao arranjo dos nodos (roteadores) e canais de comunicação na forma de um grafo. O roteamento define o caminho a ser utilizado por uma mensagem para atingir o seu destino. O chaveamento define como uma mensagem é transferida da entrada de um roteador para um de seus canais de saída. O controle de fluxo lida com a alocação 22

24 dos recursos necessários para uma mensagem avançar pela rede, realizando a regulação de tráfego nos canais. A memorização determina o esquema de filas utilizado para armazenar uma mensagem bloqueada na rede quando um canal de saída requisitado está alocado para outra mensagem. A arbitragem resolve conflitos internos na rede, quando duas ou mais mensagens competem por um mesmo recurso (fila ou canal de saída) (DALLY; TOWLES, 2004, p ). Devido às restrições de projeto e aos requisitos de custo e de desempenho dos SoCs, as NoCs herdam muitos dos conceitos e soluções já consolidados nas Redes de Interconexão, que são redes de comunicação utilizadas em computadores paralelos. Dessa forma, as topologias e técnicas de comunicação adotadas nas NoCs propostas na literatura são similares ou derivadas daquelas já consolidadas no âmbito da computação paralela. A seguir, são descritas algumas das topologias de rede comumente utilizadas nas NoCs e técnicas de comunicação abordadas anteriormente Topologia As topologias de rede de interconexão podem ser agrupadas em duas classes principais, as redes diretas e as redes indiretas. Nas redes diretas, cada nodo 1 de chaveamento (responsável pela transferência de mensagens entre os nodos de processamento) possui um nodo de processamento associado (responsável pelo processamento da mensagem). Nas redes indiretas, os nodos de processamento possuem uma interface para uma rede de nodos de chaveamento. Cada nodo de chaveamento possui um conjunto de portas bidirecionais para ligações com outros nodos de chaveamento e/ou com os nodos de processamento. Somente alguns nodos de chaveamento possuem conexões para nodos de processamento e apenas esses podem servir de fonte ou destino de uma mensagem. Essa característica é o que diferencia as redes diretas das indiretas (BASTOS, 2006, p. 37). Existem diferentes alternativas de topologia de rede, contudo as mais utilizadas nas redes de interconexão resumem-se a um subconjunto restrito de topologias como as redes multiestágio e as redes k-ary n-cube, que possuem n dimensões e k roteadores em cada dimensão. Exemplos de redes de interconexão para máquinas paralelas que utilizam essas topologias incluem a grelha 3-D do Intel/ASCI, o hipercubo do SGI/Origin, a multiestágio do IBM/SP e o toróide 3-D do Cray T3E. 1 Elemento que corresponde a uma entidade que gera informação a ser comunicada a outras entidades ou consome informação gerada por outras entidades similares. 23

25 Considerando as tecnologias de fabricação de circuitos integrados, as topologias preferidas para as redes-em-chip são do tipo planar (exemplo Figura 4.a) ou bidirecional, as redes multiestágio e k-ary 2-cube (malha 2-D e torus 2-D, ilustradas na Figura 4.b e o hipercubo na Figura 4.c, respectivamente) (BENINI; MICHELI, 2006, p ). (a) (b) (c) Figura 4. Exemplos de topologia: (a) em malha; (b) toróide ou torus; (c) hipercubo Fonte: Adaptado de Duato; Yalamanchili; Ni (2003, p. 27). Cabe ao projetista analisar qual dentre estas topologias adapta-se melhor a sua aplicação. Para garantir a transferência de mensagem entre os núcleos, torna-se necessário impedir que situações como deadlock, livelock e starvation venham a ocorrer. Deadlock é definido como uma dependência cíclica entre as solicitações de acesso a recursos de comunicação e de armazenamento. Livelock ocorre quando pacotes ficam circulando pela rede sem se aproximar dos seus respectivos destinos. Starvation ocorre quando um pacote armazenado em um buffer solicita um canal de saída, sendo que este permanece bloqueado porque o canal de saída é sempre alocado para outro solicitante de mais alta prioridade (OST, 2004, p. 15). 24

26 2.1.4 Estratégias de Roteamento Para que um nodo, pertencente a um conjunto de nodos interconectados, possa se comunicar com qualquer outro nodo do conjunto, é necessário que um endereço seja atribuído a cada nodo, identificando-os de forma única. Quando um nodo origem quer que a rede entregue uma mensagem a um determinado nodo destino, este especifica o endereço do destino. Se os nodos origem e destino não estão conectados diretamente, então os roteadores da rede usam este endereço para decidir como a mensagem é enviada na direção do destino. O processo que determina como enviar mensagens na direção do nodo destino, baseado em seu endereço, é chamado roteamento (MELLO, 2006, p. 20). O roteamento é realizado na Camada de Rede, conforme o modelo OSI da ISO. Um bom roteamento é considerado aquele que consegue escolher um caminho com poucos roteadores entre a origem e o destino, ser tolerante a falhas e adaptativo de forma a conseguir diminuir o hop count, que corresponde ao número de canais que a mensagem deve cruzar para ir do nodo fonte ao nodo destino seguindo algum caminho disponível na rede. Também se deve considerar o balanceamento de carga através dos diversos caminhos existentes, para que a rede não fique desbalanceada (alguns dos caminhos fiquem sobre-utilizados em relação a outros) (BASTOS, 2006, p. 38). Existem muitas estratégias diferentes de roteamento, as quais são expostas na Tabela 2, classificadas segundo os diferentes critérios descritos a seguir (SANTO, 2004, p. 17):

27 Tabela 2. Classificação dos Mecanismos de Roteamento. Critério Tipo Descrição Número de Destinos Unicast Mensagem tem um único destino Multicast Mensagem tem múltiplos destinos Local de Roteamento Centralizado O caminho da mensagem é definido por um controlador central Fonte O núcleo emissor da mensagem define o caminho a ser utilizado Distribuído O caminho da mensagem é definido pelos roteadores Implementação Física Tabela O roteamento é feito por uma consulta a uma tabela em memória Algoritmo O roteamento é feito por um algoritmo de software ou de hardware Adaptatividade Determinístico O roteamento fornece sempre o mesmo caminho entre um determinado par fontedestino Oblivious (inconsciente ou distraído) O roteamento fornece caminhos alternativos para um determinado par fontedestino, mas não utiliza nenhuma informação a respeito do tráfego da rede e/ou estado dos canais Adaptativo O roteamento utiliza alguma informação a respeito do tráfego da rede e/ou do estado dos canais para evitar regiões congestionadas ou com falhas Fonte: Adaptado de Ni e McKinley (1993). 26

28 2.1.5 Chaveamento Conforme já definido, o chaveamento determina como uma mensagem é transferida da entrada de um roteador para um de seus canais de saída. Os dois tipos principais de técnicas de chaveamento são baseados no estabelecimento de um caminho completo entre a fonte e o destinatário da mensagem (circuito) ou na divisão das mensagens em pacotes que reservam seus caminhos dinamicamente na medida em que avançam em direção ao destinatário. A seguir, são descritas as principais técnicas de chaveamento (ZEFERINO, 2003, p.39). Chaveamento por circuito Na técnica de chaveamento por circuito, é estabelecido um caminho entre a origem e o destino antes do inicio do envio da mensagem. Quando este caminho é estabelecido, a mensagem pode ser enviada, sendo que qualquer outro pedido de comunicação que utilize os canais já alocados não será aceito. O caminho somente é desfeito quando toda a mensagem chega no seu destino. Segundo Mello e Möller (2003, p ), a grande vantagem desta técnica é que não são necessárias filas nos roteadores intermediários, pois, uma vez que a comunicação foi estabelecida, a mensagem não é bloqueada. A desvantagem é que esta causa perda no desempenho da rede como um todo, já que todos os roteadores no caminho reservado para o envio ficam bloqueados durante a transmissão de dados (BASTOS, 2006, p.41). Chaveamento por pacotes Na técnica de chaveamento por pacotes, as mensagens são divididas em unidades menores com a mesma estrutura de uma mensagem (cabeçalho, corpo e terminador), as quais são denominadas pacotes. No encaminhamento de um pacote, são alocados apenas os canais necessários para a sua transmissão, permitindo assim que diferentes conexões compartilhem os mesmos recursos da rede. Existem três técnicas básicas de chaveamento por pacotes: Store-and-Forward SAF: Nesta técnica, também chamada de armazena e repassa, um pacote recebido por um roteador tem que ser completamente armazenado em um buffer antes de ser encaminhado para o próximo roteador. A vantagem deste método é a sua simplicidade e o baixo congestionamento dos canais da rede devido ao armazenamento por completo do pacote em cada roteador. Como desvantagem, pode-se citar a maior 27

29 latência (tempo gasto para entregar uma única mensagem no seu destino) na rede, já que o roteador deve receber todo o pacote para depois iniciar o seu envio ao próximo roteador. Destaca-se que o roteador aloca apenas os recursos necessários para que os pacotes possam avançar de nodo em nodo em direção ao destino (OST, 2004, p. 16). Virtual Cut-Through (VCT): Esta técnica é um aperfeiçoamento do SAF do ponto de vista de eficiência. Sua vantagem é a redução da latência na comunicação, já que somente pressupõe o armazenamento do pacote inteiro caso o canal por este desejado encontre-se indisponível (ZEFERINO, 2003, p. 40). Após o roteador receptor garantir que pode receber todo o pacote, o roteador fonte pode iniciar a transferência, mesmo que ainda não tenha recebido o pacote por inteiro. A desvantagem é que, apesar de um pacote somente ser armazenado localmente quando o canal desejado por este estiver indisponível, o roteador ainda necessita de espaço de armazenamento suficiente para estocar completamente o pacote no caso de bloqueios (BASTOS, 2006, p. 41). Wormhole: Esta técnica é uma variação do virtual cut-through com menor utilização de buffers. Nesta, os pacotes são quebrados e transmitidos entre as chaves em unidades menores denominadas flits (Unidade de controle de fluxo, do inglês, flow control digit ou flow control unit). Isso permite construir roteadores rápidos e de mais baixo custo do que usando as outras técnicas de chaveamento por pacotes. Porém, como apenas o flit cabeçalho contém informações sobre o roteamento, os demais flits que compõem o pacote devem seguir o mesmo caminho reservado para o cabeçalho. Se um cabeçalho não puder avançar na rede em função da contenção de recursos, todos os flits restantes são bloqueados ao longo do caminho, até que o caminho seja liberado (OST, 2004, p. 16). Por conta disso, é mais suscetível à ocorrência de deadlock (impasse), já que os pacotes possuem permissão para reter alguns recursos enquanto requisitam outros (BASTOS, 2006, p. 42). No entanto, há soluções para evitar o surgimento de condições que levem ao deadlock, como, por exemplo, a restrição de caminhos utilizados pelos pacotes durante o roteamento. 28

30 2.1.6 Controle de Fluxo Quando um pacote não pode prosseguir, pois algum recurso que este necessita já está sendo utilizado por um outro pacote, é dito que ocorreu uma contenção de recurso. Nesse caso, alguma política deve ser usada para decidir se o pacote deve ser descartado, bloqueado no lugar onde está, recebido e armazenado temporariamente ou, então, desviado para um outro caminho. Essa política é denominada controle de fluxo (ZEFERINO, 2003, p. 42) e é implementado na Camada de Enlace do modelo OSI/ISO. O controle de fluxo em nível de enlace é feito nos canais que interligam os roteadores e os núcleos. Tipicamente, em uma NoC, cada canal físico é do tipo paralelo e simplex, com múltiplos fios de dados unidirecionais, sendo que a largura do canal, em bits, é denominada phit (ou physical unit). Um enlace é tipicamente composto por um par de canais unidirecionais opostos e cada canal requer um mecanismo para regular o tráfego de phits através do canal. As principais técnicas de controle de fluxo utilizadas em NoCs são descritas a seguir: Controle de fluxo handshake Na abordagem para controle de fluxo denominado handshake, o transmissor inicialmente informa ao receptor a intenção de enviar um dado através de um sinal de solicitação. Ao receber este sinal o receptor verifica se existe espaço para receber o dado. Em caso afirmativo, este é lido e armazenado, e o receptor envia o sinal de reconhecimento de recepção ack (confirmação) ao transmissor. Caso não exista espaço disponível, o receptor pode enviar um sinal de não reconhecimento (nack) ou não tomar nenhuma ação. Quando isso ocorrer, o roteador transmissor retransmite o dado até o recebimento de um sinal de confirmação (ack). Algumas desvantagens são encontradas nessa abordagem de controle de fluxo. Segundo Dally e Towles (2004, p ), o controle de fluxo handshake é menos eficiente no uso das filas do que o controle de fluxo baseado em créditos. Essa menor eficiência ocorre porque os dados ficam armazenados nas filas por um tempo extra até receberem o sinal de ack. Além disso, é colocado que o handshake é ineficiente no uso da largura de banda quando não há espaço em fila, já que se torna necessário reenviar o dado. Como principal vantagem para a utilização desta abordagem é a simplicidade para implementação (BASTOS, 2006, p.43). 29

31 Controle de fluxo baseado em créditos O controle de fluxo baseado em créditos é um tipo de controle que produz uma rede de comunicação que nunca descarta dados. Uma transmissão só é realizada quando o receptor tem espaço suficiente em seu buffer para armazenar o pacote a ser recebido. Para isso, o seguinte protocolo é utilizado: (i) o receptor envia ao transmissor uma informação de créditos relativa ao espaço disponível para recepção de dados em seu buffer; (ii) o transmissor, por sua vez, inicia uma transmissão apenas quando possuir crédito suficiente; e (iii) o crédito do transmissor diminui com o envio de dados e aumenta com o recebimento de informações de controle apropriadas (ZEFERINO, 2005, p. 44). Canais Virtuais Cada canal físico é compartilhado por dois (ou mais) canais lógicos. Se um determinado canal lógico é bloqueado devido a uma contenção na rede, o canal físico pode ainda ser utilizado por um outro canal lógico, sendo que cada canal lógico tem seu tráfego regulado individualmente Memorização O roteador de uma rede com chaveamento por pacotes deve garantir o armazenamento de pacotes recebidos e destinados a saídas que já estejam sendo utilizados por outros pacotes. Além disso, o roteador deve ser capaz de controlar o fluxo proveniente dessa porta a fim de evitar a perda de dados. Todo roteador é capaz de armazenar um número limitado de pacotes ou uma fração de um pacote em sua memória, dependendo da técnica de chaveamento utilizada. Por esse motivo, o bloqueio de pacotes pode ocorrer em maior ou menor escala, dependendo da estratégia de armazenamento temporário utilizada. Essas estratégias podem influenciar significativamente o desempenho da rede. Dentre as mais utilizadas pode-se destacar o armazenamento na entrada, na saída e o centralizado de forma compartilhada (BASTOS, 2006, p. 44), os quais são descritos a seguir: Memorização de Entrada: O espaço de memória é distribuído sob a forma de partições implementadas através de filas independentes (buffers), as quais são associadas aos canais de entrada. Pode haver uma ou mais filas associadas a cada canal; Memorização de Saída: O espaço de memória é distribuído sob a forma de partições implementadas através de filas independentes, as quais são associadas aos canais de saída; e 30

32 Memorização Centralizada Compartilhada: Uma fila central é utilizada para armazenar os pacotes bloqueados de todas as portas de entrada e o espaço de endereçamento é dinamicamente distribuído entre os pacotes bloqueados. Em redes que utilizam controle de fluxo baseado em canais virtuais e memorização de entrada, por exemplo, cada canal virtual requer uma fila específica para armazenar os seus pacotes temporariamente Arbitragem Quando um determinado recurso do roteador, como uma fila ou um canal de saída é compartilhado por dois ou mais pacotes, é necessário um mecanismo para escalonar o uso dos recursos por esses pacotes quando estes requisitam o acesso ao recurso simultaneamente. A esse mecanismo dá-se o nome de arbitragem. Por exemplo, quando se utiliza chaveamento por pacotes, estes chegam através de canais nas portas de entrada do roteador e são transferidos para os canais das portas de saída. Quando pacotes de diferentes portas chegam simultaneamente ao roteador e requisitam acesso à mesma porta de saída, é necessária uma arbitragem para selecionar quem ganhará o direito a utilizar a porta de saída por primeiro. O processo de arbitragem é realizado por um circuito denominado árbitro, o qual deve garantir a utilização do recurso escalonado conforme os requisitos do sistema, além de assegurar que não existam problemas de starvation, ou seja, uma porta de entrada ficar esperando acesso a uma porta de saída indefinidamente (BASTOS, 2006, p. 47). Alguns dos esquemas de arbitragem mais utilizados em redes de interconexão e em NoCs são descritos a seguir (SANTO; ZEFERINO, 2004, p. 11): Prioridades estáticas: Cada canal de entrada possui uma prioridade fixa ao competir pelo canal de saída; Prioridades dinâmicas: As prioridades dos canais de entrada variam a cada arbitragem realizada. É tipicamente implementada por uma fila circular (Round-Robin); Deadline: A mensagem esperando a mais tempo pelo uso do canal de saída é selecionada pelo árbitro; LRS (Least Recently Served): O canal de entrada menos recentemente servido é selecionado; 31

33 FCFS (First-Come, First-Served): O primeiro canal de entrada a solicitar o canal de saída é selecionado pelo árbitro; e Multinível: Implementa em mais de um nível diferentes esquemas de arbitragem, como os ilustrados acima (Ex: prioridade dinâmica + prioridade estática) Estudo de caso: SoCIN (System-on-Chip Interconnection Network) A rede SoCIN, desenvolvida inicialmente na Universidade Federal do Rio Grande do Sul UFRGS e mantida na Universidade do Vale do Itajaí UNIVALI em cooperação com pesquisadores da UFRGS e da Universidade de Santa Cruz do Sul - UNISC, visa a exploração de arquiteturas de NoCs com baixo custo de silício, visando à realização de sistemas embarcados escaláveis com alta demanda de comunicação. A rede SoCIN se baseia em uma arquitetura de roteador parametrizável denominado ParIS (Parameterized Interconnection Switch), cujo modelo VHDL permite a simulação e a síntese de redes em malha 2-D com diferentes configurações de mecanismos de roteamento, controle de fluxo, arbitragem e memorização (buffers de entrada e de saída com profundidade parametrizável) (ZEFERINO et al., 2007). Como estudo de caso sobre NoCs, esta subseção apresenta as características da rede SoCIN. A topologia utilizada na rede SoCIN é uma malha 2-D, ilustrada na Figura 5, na qual cada roteador possui uma porta de comunicação local, a qual pode ser conectado a um núcleo ou um subsistema. Além dessa, o roteador possui também de duas a quatro portas de comunicação para conexão com roteadores vizinhos, conforme a posição do roteador na rede. Essas portas são chamadas de North (superior), East (à direita), South, (inferior) e West (à esquerda), ou, simplesmente, N, E, S e W. Os roteadores são endereçados por um sistema de coordenadas XY (Coluna, Linha), conforme ilustrada no detalhe do roteador ParIS em detalhe na Figura 5. 32

34 Y 3 0,3 1,3 2,3 3,3 L N 2 0,2 1,2 2,2 3,2 W ParIS X,Y E S 1 0,1 1,1 2,1 3,1 0 0,0 1,0 2,0 3, X Figura 5. Topologia em malha 2-D da rede SoCIN Fonte: Adaptado de Zeferino et al. (2007). A rede SoCIN utiliza o chaveamento por pacotes wormhole e o controle de fluxo pode ser configurado em uma de duas alternativas: handshake ou baseado em créditos. O roteamento também é configurável entre modelos determinístico (XY) e parcialmente adaptativos (West First, North First,...). A rede SoCIN utiliza memorização na entrada e, opcionalmente, na saída. A arbitragem é implementada de forma distribuída e cada porta de saída do roteador possui um árbitro que seleciona o buffer de entrada do roteador a ser conectado ao canal de saída dessa porta. Os árbitros utilizam um critério baseado em prioridades dinâmicas rotativas (Round-Robin) que garante que nenhum pacote sofrerá com o problema de starvation (ZEFERINO, 2005, p. 129). 2.2 MODELO DE GERAÇÃO DE TRÁFEGO A geração de tráfego tem por objetivo definir uma estrutura de transmissão de dados originados por iniciadores para seus destinos, além de definir os próprios iniciadores (nodos fonte ou origem) e destinos (nodos destinatários). É através da geração de tráfego que são caracterizadas as aplicações que venham fazer uso de uma determinada rede (TEDESCO, 2005 p. 9). 33

35 Esta seção apresenta conceitos sobre geração de tráfego, complementando o conteúdo discutido na seção anterior e fornecendo a base necessária para a discussão sobre avaliação do desempenho de NoCs Padrões para distribuição espacial de tráfego Através dos padrões de distribuição espacial de tráfego, é possível definir a relação existente entre iniciadores e destinos, explicitando que determinado nodo comunica-se com outro nodo da rede. A seguir, são descritos alguns conceitos relacionados a padrões de tráfego (DUATO; YALAMANCHILI; NI, 2003, p. 424). Localidade espacial A localidade espacial de um padrão de distribuição espacial é função da distância média entre os nodos comunicantes. Quando esta é menor do que a observada no padrão de tráfego uniforme 2, diz que o padrão exibe alta localidade espacial, consumindo menos recursos da rede e resultando em uma menor contenção de tráfego. Do contrário, é dito que o padrão possui uma baixa localidade espacial, o que resulta em uma maior contenção. Localidade temporal A localidade temporal ocorre quando há uma afinidade de comunicação entre um subconjunto de nodos. A probabilidade de um nodo enviar mensagens para nodos anteriormente escolhidos como destino é maior do que para outros nodos que não receberam mensagens recentemente. Padrão de tráfego uniforme Neste padrão de tráfego, todos os nodos possuem a mesma probabilidade de serem destinos. No estudo de redes de comunicação de dados, a distribuição uniforme é a mais freqüentemente utilizada. 2 Padrão de Trafego Uniforme é aquele em que todos os nodos da rede possuem a mesma probabilidade de serem destinos de um mesmo nodo. Ou seja, neste padrão, todos os nodos comunicam-se com todos os nodos e com a mesma probabilidade cada nodo ser destinatário de um mesmo nodo iniciador. 34

36 Padrão de tráfego não-uniforme Neste padrão de tráfego, a probabilidade de um nodo enviar pacotes para um de seus nodos vizinhos é o dobro em relação ao envio de pacotes para os nodos restantes. Esta distribuição produz uma maior localidade espacial do tráfego em relação à distribuição uniforme, o que a torna mais adequada para caracterização de aplicações reais (TEDESCO, p. 10). Padrão de tráfego baseado em coordenadas No padrão de tráfego baseado em coordenadas, os nodos possuem seus endereços no formato binário, e sua distribuição de nodos no plano é ilustrada na Figura 6. Y Endereço = x 1 x0, y1 y ,11 01,11 10,11 11, ,10 01,10 10,10 11, ,01 01,01 01,10 11, ,00 01,00 10,00 11, X Figura 6. Topologia em malha 2-D, representando os endereços dos nodos em forma binária segundo um sistema de coordenadas XY (X = coluna, Y = linha). Fonte: Adaptado de Tedesco (2005, p. 13). A Tabela 3 apresenta os padrões de distribuição dos endereços, fazendo uma relação dos modelos de padrão de tráfego baseados em coordenadas binárias de endereços, e como é referenciada a forma de comunicação de um nodo destino com um nodo origem. 35

37 Tabela 3. Relação de ligações entre nodos destino e origem Padrão Nodo origem Nodo destino Bit-reversal an 1, an 2,..., a1, a0 Perfect Shuffle an 1, an2,..., a1, a0 Butterfly an 1, an2,..., a1, a0 a 0, a1,..., a n 2, an 1 a n2, an3,..., a0, an 1 a 0, an 2,..., a1, an 1 Matrix transpose an 1, an 2,..., a1, a0 Complemento an 1, an2,..., a1, a0 a a n,..., a0, an1, an n2, an3,..., a0, an1 Fonte: Adaptado de Tedesco (2005, p.11). a a Assim, no padrão Bit-reversal o nodo que possui as coordenadas no formato binário n 1, an2,..., a1, a0 se comunicará com o nodo que possui as coordenadas no formato binário 0, a1,..., a n 2, an 1. No padrão Perfect Shuffle, o endereço do destino é definido fazendo a rotação de 1 bit para a esquerda no nodo de origem. No padrão Butterfly, o nodo destino é determinado trocando o bit mais significativo do nodo de origem pelo bit menos significativo. No padrão Matrix Transpose, o nodo destino é determinado pela rotação de n / 2 bits para a esquerda, sendo que n é o número de bits que identificam o nodo e o padrão Complemento o nodo destino é determinado pela inversão de todos os bits do nodo de origem. Na Tabela 4, são ilustrados exemplos de mapeamento do endereço de um nodo de origem utilizando os diferentes padrões descritos na Tabela 3. 36

38 Tabela 4. Exemplo de ligação no Padrão de Tráfego utilizando coordenadas binárias Padrão de Tráfego Nodo origem Nodo destino Exemplo de nodo origem Exemplo de nodo destino Bit-reversal 1 x0, y1 y0 Perfect Shuffle 1 x0, y1 y0 Butterfly 1 x0, y1 y0 Matrix transpose 1 x0, y1 y0 Complemento 1 x0, y1 y0 x 0 y1, x0x1 x 0 y1, y0x1 x 0 x0, y1x1 x 1 y0, x1x0 x 1 x0, y1 y0 Fonte: Adaptado de Tedesco (2005, p.11). y 11,10 01,11 x 11,10 11,01 y 11,10 01,11 y 11,10 10,11 x 11,10 00, Categoria de serviços A divisão de aplicações em categorias envolve a diferenciação das mesmas quanto à variabilidade de suas taxas de transmissão, latência e variação de latência dos fluxos de dados. Tais parâmetros são especificados por descritores de tráfego, através do qual a fonte de tráfego solicita serviços a rede de comunicação. A rede por sua vez atribui níveis de QoS (Quality-of-Service ou qualidade de serviço) ao tráfego oriundo da fonte solicitante, de modo a procurar atender aos seus requisitos de desempenho. O compromisso básico que deve haver entre a rede e a aplicação é que, uma vez a conexão estabelecida, a QoS negociada é assegurada para todos os pacotes que respeitam os limites de taxa de injeção estabelecidas nos parâmetros especificados pelos descritores de cada categoria de serviço (DALLY; TOWLES, 2004). A seguir, são abordados conceitos de algumas destas categorias de serviços, como VBR, CBR, ABR e UBR. A categoria de serviço VBR (Variable Bit Rate) é dirigida a fluxos com a taxa de dados variável, como os encontrados em aplicações multimídia com compressão, como vídeo e áudio MPEG. A categoria de serviço CBR (Constant Bit Rate) é empregada em situações que exigem largura de banda estática, como aplicações de comunicação de áudio sem compressão (ex. telefonia digital). A categoria de serviço ABR (Available Bit Rate) é direcionada a conexões que transportam tráfego em rajadas que podem prescindir da garantia de banda, variando a taxa de bits de acordo com a disponibilidade da rede. Já a categoria de serviço UBR (Unspecified Bit Rate) é destinada a 37

39 conexões que transportam tráfego que não tem requisitos de tempo real e cujos requisitos e atraso ou variação do atraso são mais flexíveis (KUMAR et al. 2002) Modelos de serviços Para que uma rede consiga atender aos requisitos de garantia de serviços oferecidos, esta depende diretamente de alguns dos serviços descritos a seguir: melhor esforço, serviço garantido e serviços diferenciados. Estes modelos de serviços são responsáveis pela classificação e ordenação dos pacotes de dados transitados na rede e ainda poderão definir a largura de banda oferecida. Melhor Esforço (BE Best-Effort) Os pacotes pertencentes à classe de tráfego BE não possuem garantias de tempo de entrega. A rede, neste caso, realiza seu melhor esforço para encaminhar o pacote para o seu destino. Uma rede que oferece o serviço BE é caracterizada por filas FIFO, as quais não diferenciam os fluxos das aplicações entre si. No contexto de NoCs, os pacotes são injetados pelo núcleo na fila de entrada do seu roteador, desde que haja espaço nesta fila. Dentro da rede, a mesma estratégia é utilizada no encaminhamento de cada flit do pacote do canal de saída de um roteador para um canal de entrada de um roteador vizinho (TEDESCO, p. 19). Serviço Garantido (GS Guaranteed Service) Neste modelo de serviço oferecido, é feita a disponibilidade total dos recursos da rede para determinado fluxo, sendo acertado um contrato entre a fonte (cliente) e o destino de fluxo (rede). Assim, o cliente do contrato determina as características do fluxo, por exemplo, a vazão máxima oferecida e a rede aceita o contrato se possuir recursos suficientes para garantir o desempenho requisitado pelo cliente (nesse caso, o serviço é chamado de Vazão Garantida ou GT Guaranteed Throughput). Geralmente, o contrato é acertado antes da transferência de dados, durante o processo de estabelecimento de conexão, e é mantido ao longo do tempo de vida da conexão (DALLY; TOWLES, 2004). Serviço Diferenciado (DS Differented Service) Este modelo de serviço, também é conhecido como serviço probabilístico, é mais flexível e possui maior escalabilidade do que o GS, porque não necessita armazenar informação de estado para cada fluxo. O DS distingue classes de fluxos para as quais os recursos são alocados, ao invés de distinguir fluxos individuais. Pacotes são classificados em classes e, geralmente, carregam a 38

40 informação da classe a que pertencem em seu cabeçalho. Baseado nestes dois componentes, o DS possui duas importantes diferenças em relação ao GS. Primeiro, quanto ao estabelecimento da conexão, pois, no DS, a conexão é estabelecida com base em medidas, ao contrário do GS, que se baseia nas características das conexões existentes. Como a carga de rede medida pode variar, o acordo de serviço no DS é menos confiável. Segundo, no GS, somente o cliente pode alterar as características da conexão, enquanto que no DS, as características da conexão são determinadas pela rede e podem variar conforme a carga desta (MELLO, 2006, p. 31). 2.3 AVALIAÇÃO DE DESEMPENHO DE NOCs A avaliação de desempenho permite a verificação dos serviços propostos pela NoC, ou seja, se esta apresenta o desempenho para o qual foi projetada, o que é demonstrado através de experimentos cujos resultados são comparados com os objetivos esperados. Para fazer a verificação do desempenho da NoC, geralmente é usado como referência de avaliação a latência e vazão. Com a coleta de dados feita pelos componentes responsáveis pela captação dos resultados da emulação, nesse trabalho são denominados de medidores de tráfego, é possível determinar valores, por exemplo, latência média, latência acumulada, menor latência, maior latência, largura de banda requerida entre outros. A verificação da latência permite avaliar o tempo decorrido a partir do momento em que a transmissão de um pacote é iniciada até o momento que o último flit é entregue ao nodo de destino (DUATO; YALAMANCHILI; NI, 2003, p. 5). Já a avaliação da vazão da rede permite verificar a taxa pela qual os pacotes são encaminhados pelo canal de comunicação entre os nodos. Esta é calculada através da equação(1), apresentada a seguir (TEDESCO, p. 20): bits _ trans vazão n _ ciclos _ sim * T (1) onde: bits_trans: número de bits transmitidos; n_ciclos_sim: número de ciclos para que todo o tráfico seja entregue aos destinos; e 39

41 T: período de relógio. Nesta seção, são apresentadas características de algumas das principais soluções usadas por grupos de trabalhos relacionados à avaliação de desempenhos de NoCs utilizando ferramentas baseadas em simulação por software. Na próxima seção, serão descritos trabalhos que caracterizam o estado da arte da avaliação de desempenho de NoC baseada na emulação em hardware Avaliação do desempenho da rede SPIN A rede SPIN Scalable, Programmable, Integrated Network foi uma das primeiras NoCs descritas na literatura, apresentadas por Guerrier e Greiner (2000). Esta utiliza uma topologia em árvore-gorda quaternária (indireta), roteamento parcialmente adaptativo, chaveamento wormhole, controle de fluxo baseado em créditos, memorização na entrada e centralizada e arbitragem multinível (fixa e Round-Robin). Experimentos de avaliação de desempenho sobre a SPIN são descritos por Zeferino (2003) e Adriahantenaina et al. (2004), que compararam o desempenho da SPIN com do barramento PI-Bus (um barramento centralizado da Philips para conexão de processadores a periféricos). A avaliação de desempenho foi baseada na simulação realizada com precisão de ciclos de modelos RTL de SoC baseados nessas arquiteturas e em geradores de tráfego e memórias RAM. Foi utilizado o simulador CASS e, como resultados, obtiveram dados sobre a escalabilidade e o ponto de saturação dessas arquiteturas. A escalabilidade foi determinada através de experimentos contendo 4, 8, 16 e 32 núcleos, onde os tamanhos dos pacotes foram mantidos com peso fixo, metade dos núcleos foi formada por iniciadores (geradores de tráfego GT) e a outra metade por composta pelos destinos (memórias RAM). Conforme ilustrado na Figura 7, foi utilizada uma distribuição espacial em que cada GT gera fluxos a cada memória RAM, enviando requisições de acesso de leitura a posições da memória, a qual deve retornar com pacotes contendo os dados lidos. O número de pacotes a ser injetado pode ser controlado de modo a demandar uma parcela da largura de banda dos canais (ex. 5%). 40

42 Figura 7. Modelo de sistema para comparação do desempenho SPIN x PI-Bus: (a) requisição dos geradores de tráfegos; (b) respostas dos destinos aos iniciadores Fonte: Adaptado de Zeferino (2003). Os resultados dos experimentos de escalabilidade podem ser observados na Figura 8, que mostra o número de ciclos gastos (number of cycles) pelas arquiteturas PI-Bus e SPIN para encaminhar requisições de iniciadores e respostas de alvos modelados segundo o padrão de tráfego mostrado na Figura 7. Figura 8. Avaliação da escalabilidade das arquiteturas de comunicação através da análise da latência Fonte: Adaptado de Adriahantenaina et al (2003). Nota-se que o desempenho da arquitetura SPIN vem a ser melhor quando o número de núcleos do sistema é maior do que 12 (destaque Figura 8), para o padrão de tráfego utilizado. Os 41

43 autores dos trabalhos destacam que o tamanho de pacote utilizado representa o pior caso para a rede. Se forem utilizados pacotes maiores (modelando, por exemplo, transferências de blocos de cache) o desempenho da SPIN será ainda melhor, devido ao fato de haver diminuição da sobrecarga de roteamento, ocasionada pelo processamento do cabeçalho de cada pacote. Esse experimento, portanto, identifica, para as condições consideradas, qual a configuração de sistema mínima a partir do qual a SPIN sobrepõe o desempenho do PI-Bus Avaliação do desempenho da rede QNoC A QNoC foi apresentada por Bolotin et al. (2004) e é um dos primeiros exemplos de NoC projetada visando o provimento de QoS baseado em diferenciação de serviços, com quatro níveis de serviço para diferentes classes de tráfego (cada um com um nível de prioridade diferente): 1. Sinalização: este nível é reservado para sinais de controle e interrupções, sendo que sua estrutura é definida por apenas 2 flits; 2. Tempo Real: destinado para o processamento de streams utilizadas em aplicações áudio e vídeo que exigem uma alta largura de banda e baixa latência; 3. Leitura/Escrita: corresponde a acessos a pequenas quantidades de memória e registradores; e 4. Transferências de Blocos: nível de serviço para fluxos compostos de grande quantidade de dados, como preenchimento de setores de memória cache e transferências DMA. A QNoC utiliza uma topologia em malha 2-D, roteamento determinístico do tipo XY 3, chaveamento wormhole, controle de fluxo baseado em créditos com canais virtuais (um para cada nível de serviço), memorização na entrada (com um fila para cada um dos quatro canais virtuais) e arbitragem multi-nível, atribuindo maior prioridade à classe Sinalização, seguida das classes Tempo Real, Leitura/Escrita e Transferência de Bloco. 3 Consiste em um estabelecimento de rotas em que um pacote encaminhado de um roteador para outro deverá percorrer primeiramente, todos os enlaces na direção X e, somente após atingir a coluna especificada, deverá seguir pela direção da coordenada Y, até atingir o nodo destinatário. 42

44 O fluxo de projeto da rede QNoC, ilustrado na Figura 9, utiliza simulação TL como ferramenta para a caracterização do desempenho da rede frente aos requisitos do tráfego. As etapas do fluxo de projeto incluem: Definição dos módulos e sua interconexão: onde os módulos do sistema são definidos e assume-se que estejam conectados em uma infra-estrutura ideal, com largura de banda infinita e latência programável; Caracterizações do tráfego entre módulos: que ocorre através da análise da interconexão dos módulos e sua especificação de tráfego; Validação das caracterizações de tráfego: onde uma ferramenta em alto nível mede o tráfego entre os módulos e o particiona em níveis de serviço. Nesta etapa também são obtidos os requisitos de QoS para cada classe de tráfego; Posicionamento de módulos: para minimizar a densidade de tráfego espacial do sistema; Mapeamento da NoC na topologia escolhida: nesta etapa os núcleos são posicionados na rede e realiza-se análise interna para verificar a utilização dos canais; Otimização da rede: para balancear sua utilização, minimizar custo e atingir QoS. Nesta etapa é possível remover enlaces ociosos, dimensionar enlaces e variar a freqüência de transmissão, com base em medições de carga relativa nos enlaces (avaliação interna);e Estimativa de custo: verifica-se nesta etapa se a otimização da rede conseguiu minimizar custo e atingir QoS. 43

45 Figura 9. Fluxo de projeto da QNoC Fonte: Adaptado de Tedesco (2005 apud Bolotin et al., 2004). Bolotin et al. (2004) apresentaram experimentos de avaliação de desempenho para uma malha 4x4. Para cada nível de serviço, foi definida uma carga de tráfego com seu requisito de latência, como mostrado na Tabela 5. As distribuições espaciais de tráfego utilizadas foram a uniforme e a não-uniforme. 44

46 Tabela 5. Modelagem de tráfego - QNoC com freqüência de 1GHz. Nível de Serviço Descrição do tráfego Tamanho Médio do pacote (em flits) Intervalo de chegada médio (em ns) Carga Total Requisitos de Latência ETE (fim-a-fim) máximo (para 99% dos pacotes) Sinalização A cada 100 ciclos cada núcleo envia 1 sinal de interrupção para um núcleo aleatoriamente escolhido (16 bits x 2 flits)/100 ns = 0.32Gbps 20 ns Real-time 15 conexões periódicas a partir de cada núcleo (para os outros 15) de 320 canais de voz (PCM 64 Kbps) (16 bits x 40 flits)/2000 ns = 0.32Gbps 125µs Leitura/Escrita Transações de leitura e escrita realizadas entre núcleos aleatórios a cada 25 ciclos 4 25 (16 bits x 4 flits)/25 ns = 2.56Gbps 150ns Transferência de Blocos Transações realizadas entre núcleos aleatoriamente escolhidos, envolvendo grandes blocos, a cada 12.5µ (16 bits x 4000 flits)/ ns = 2.56Gbps 50µs Fonte: Adaptado de Bolotin et al. (2004). A carga de tráfego relativo, ilustrada na Figura 10, mostra todos os canais da malha, que representam os índices dos roteadores, enquanto que as barras verticais representam as cargas relativas entre os canais. Dessa forma, é possível observar que as maiores cargas relativas ocorrem nos enlaces que correspondem às coordenadas (1,3) e (2,3), enquanto que as menores cargas relativa ocorrem nos canais entre ((0,0),(1,0)) e ((2,0), (3,0)). 45

47 Figura 10. Carga Relativa dos enlaces da malha Fonte: Adaptado de Bolotin et al. (2004). De acordo com a distribuição de carga relativa, é realizada a otimização da rede. Tal otimização é realizada através do re-dimensionamento de enlaces, que pode ser feita variando-se parâmetros como número de fios ou freqüência. Caso existam enlaces sub-utilizados, os mesmos podem ser removidos, tornando a rede uma malha irregular. A Tabela 6 ilustra, para cada largura de banda alocada, os valores obtidos para a utilização média dos canais da rede, bem como os valores de latência média em cada classe de serviço. Para avaliação de desempenho, deve-se tomar como referência a Tabela 6, que descreve os requisitos de cada nível de serviço. Nas duas primeiras situações (2560 Gbps e 1280 Gbps) a rede apresenta desempenho melhor que o requerido, mas apresenta baixos valores de utilização dos enlaces, sendo desta forma sub-utilizada. Para a largura de banda alocada de 850 Gbps obteve-se a melhor relação custo/desempenho (destaque em itálico). Reduzindo ainda mais o custo da rede (redução da largura de banda para 512Gbps) os requisitos de QoS para as pacotes pertencentes às classes de sinalização e transferência de blocos não são satisfeitos (TEDESCO, p. 29, 2005). O experimento demonstra a importância da avaliação de desempenho da rede para identificar uma configuração ótima que atenda aos requisitos da aplicação a um menor custo (baixa sub-utilização). 46

48 Tabela 6. Latência média dos pacotes em função da largura de banda alocada. QoS desejado é marcado em itálico. Largura de banda Alocada (Gbps) Utilização Média do Canal (%) Sinalização (para 99.9% dos pacotes) Latência Média (ns) Real-Time (para 99.9% dos pacotes) RD/WR (para 99.9% dos pacotes) Transferência de blocos (para 99% dos pacotes) , , Fonte: Adaptado de Tedesco (2005 apud Bolotin et al. (2004). OBS: O não-atendimento a requisitos de QoS é marcado em negrito. Para verificar a latência média na rede (mean ETE delay[cicles]) em função da carga de tráfego oferecida (Total Traffic Load [Gbps]), mostrado na Figura 11, a configuração de rede e a largura de banda foram fixadas e foram aplicadas várias cargas de tráfego, alternando-se o intervalo de chegadas do pacote em cada nível de serviço. A Figura 11 ilustra o resultado do experimento realizado. Nesta, percebe-se que enquanto a carga de tráfego está crescendo, a latência média dos tráfegos relacionados aos níveis de serviço Leitura/Escrita e Transferência de Bloco cresce de maneira rápida, enquanto que a latência média de tráfegos sensíveis ao atraso (Sinalização e Tempo Real) permanece praticamente constante. Este experimento demonstra o uso da avaliação de desempenho para verificar a capacidade da rede de assegurar o provimento de QoS às classes de maior prioridade. 47

49 Figura 11. Carga aplicada vs. latência média obtida Fonte: Bolotin et al. (2004) Avaliação do desempenho da rede HERMES Nos trabalhos desenvolvidos por (MELLO, 2006) e por (CARARA, 2007), foi utilizado a arquitetura da NoC HERMES, sendo que esta NoC possui uma topologia em malha e cada roteador pode possuir um número de portas diferentes de acordo com sua posição no projeto físico da rede. Por exemplo, na Figura 12, o roteador central possui cinco portas de interligação (Norte, Sul, Leste, Oeste, Local) e os demais roteadores possuem de três a quatro portas de interligação. 48

50 Figura 12. Topologia em malha bidirecional 3x3 da NoC HERMES Fonte: Adaptado de MELLO, (2006) A técnica de chaveamento usado pela NoC HERMES é a Wormhole, que consiste em quebrar os pacotes em flits garantindo com isso uma menor utilização de buffers nos roteadores para armazenamento das mensagens. Caso o pacote seja maior que o espaço livre no buffer do roteador, a mensagem é armazenada em diferentes roteadores, porém, evitando com isso a multiplexação de diferentes flits de outras mensagens naquele momento nos roteadores que compõem o canal lógico de comunicação. O roteamento da NoC HERMES pode ser definido pelo usuário, sendo que em (MELLO, 2006) o roteamento aplicado foi o determinístico e distribuído. Já o controle de fluxo, a NoC Hermes suporta duas estratégias de controle: handshake e credit based, sendo que controle de fluxo baseado em créditos (credit based) é utilizado ao longo do trabalho citado. Trata-se de um protocolo síncrono que possui melhor desempenho se comparado ao handshake. No trabalho desenvolvido por Mello (2006), foi elaborado uma estrutura para prover QoS em redes-em-chip, onde, evidenciou-se que o mecanismo baseado em prioridades dinâmicas mostrou-se ineficiente para garantir QoS, devido à ausência da alocação de recursos. Mecanismos baseados em prioridades fixas e chaveamento por circuito podem garantir QoS. Entretanto, ambos apresentam limitações, especialmente quando fluxos com requisitos de QoS competem por recursos da rede. Quando usado chaveamento por circuito, todos os requisitos de QoS são garantidos após o estabelecimento da conexão. No entanto, se algum outro fluxo QoS que compartilhe parte do 49

51 caminho da conexão possua prazo final para o estabelecimento da conexão, então este mecanismo não será capaz de garantir este requisito(mello, p. 109, 2006). No trabalho desenvolvido por Carara (2007), foi desenvolvido uma estratégia para otimização de desempenho de redes-em-chip com implementação e avaliação na NoC Hermes, no qual foi apresentado vários mecanismos para alcançar os resultados esperados. Para a largura de banda, a replicação de canais físicos mostrou-se uma solução eficiente em relação ao consumo de área e principalmente em relação ao desempenho, quando comparada a multiplexação dos canais físicos (canais virtuais). Em relação à transmissão, foi proposto um método baseado em chaveamento por circuito e nível de sessão, garantindo a maximização dos recursos através de transmissões em rajada e curta alocação de recursos. Conforme Carara (2007), outro fator que colabora com um ganho em desempenho é a adaptatividade do roteamento em função do tráfego. Essa abordagem mostrou-se eficiente por adicionar um nível de inteligência aos algoritmos de roteamento adaptativos, através da seleção de uma porta de saída baseada nas condições de congestionamento de roteadores vizinhos, evitando regiões de tráfego congestionado. 2.4 ESTADO DA ARTE DA AVALIAÇÃO DE DESEMPENHO ON-CHIP Genko et al. (2005) Genko et al (2005) apresentam um ambiente para avaliação de desempenho da rede xpipes baseado na emulação hardware-software, sendo capaz de comparar vários modelos em nível físico através de experimentos realizados com a NoC implementada diretamente em hardware. A estrutura desse ambiente é ilustrada na Figura 13, na qual são destacados os seus principais componentes: gerador de tráfego (Traffic Generator - TG), receptor de tráfego (Traffic Receptor - TR) e a própria rede. Neste ambiente, todos os experimentos são realizados sobre um sistema sintetizado em dispositivo de lógica programável do tipo FPGA. 50

52 Figura 13. Arquitetura de emulação de NoC Fonte: Genko et al. (2005) Na plataforma, a geração de tráfego pode ser realizada de duas maneiras: baseada em traces de aplicações reais ou de forma estocástica, sendo que, na primeira opção, o gerador de tráfego utiliza uma amostra de um tráfego real obtido a partir da execução de alguma aplicação e cada trace de tráfego contém o tamanho dos pacotes, o endereço do destino e o momento em que o pacote deve ser injetado na rede. Na segunda opção de geração de tráfego, a estocástica, o usuário pode especificar a taxa de injeção de dados, características dos pacotes e as distribuições de probabilidade. A partir das especificações de tráfego, é feita a inicialização da plataforma e a sua emulação em FPGA. Na etapa de emulação, são executadas as comunicações e a coleta de estatísticas de tráfego, gerando ao final um relatório enviado ao usuário, descrevendo os valores de latência média obtida, a quantidade de pacotes enviados e recebidos nos geradores e receptores de tráfego, período de duração para cada rajada de flits, tempo total de emulação e histograma de flits encaminhados com granularidade definida pelo usuário. Existem dois tipos de receptor de tráfego. O primeiro pode ser configurado quanto a granularidade de amostragem, (ou seja, o intervalo, em ciclos de relógio, para a coleta de dados) gerando uma contagem dos flits recebidos que permite produzir um histograma indicando a atividade no receptor. O segundo tipo gera um trace para cada pacote recebido, no mesmo formato 51

53 utilizado pelo gerador de tráfego baseado em traces e armazenado em memória para posterior análise. Genko et al. (2005) apresentaram alguns experimentos ilustrando o uso do ambiente desenvolvido. No primeiro, a rede utilizada foi uma malha de tamanho 3x2 e cada roteador continha um gerador e um receptor de tráfego e dois tipos de taxas de injeção foram aplicados, sendo que para o tráfego uniforme, o tamanho dos pacotes foi mantido fixo em 5 flits, mantendo um intervalo de injeção escolhido aleatoriamente entre 4 e 8 ciclos de relógio. Ainda no primeiro experimento, o tráfego foi injetado em rajadas, no qual pacotes do mesmo tamanho são gerados consecutivamente. Conforme é observado na Figura 14, o tempo total para encaminhamento de pacotes (Run Time (M Clk)) pertencentes ao tráfego em rajada é maior que para o tráfego uniforme. Isso ocorre porque o modelo de tráfego uniforme possui menor probabilidade de haver colisões. Figura 14.Comparação de tráfego uniforme com tráfego em rajadas Fonte: Genko et al. (2005). Para realizar o segundo experimento, ilustrado na Figura 15, foi utilizada uma malha 2x2 com um gerador e um receptor de tráfego para cada roteador. A avaliação de desempenho considerou a taxa de congestionamento (Congestion rate (k)) com relação a diferentes tamanhos de pacotes (S) e tamanhos de rajadas (N). Os resultados obtidos mostram que a taxa de congestionamento não cresce linearmente com o tamanho das rajadas, porque o intervalo de inatividade entre duas rajadas aumenta de acordo com o número de pacotes enviados neste modo, sendo que a probabilidade de haver colisões cresce menos do que linearmente. 52

54 Figura 15. Avaliação do tamanho da rajada Fonte: Genko et al. (2005). A abordagem utilizada por Genko et al. (2005) permite acelerar um experimento de avaliação de desempenho em até quatro ordens de magnitude em relação a uma abordagem baseada em simulação no nível RT. Segundo os autores, um experimento envolvendo a transferência de um bilhão de pacotes consome menos de quatro minutos no ambiente de emulação, sendo que a simulação SystemC de nível RT do mesmo experimento gasta cerca de seis dias. Isso pode ser explicado pelo fato de que na simulação, cada componente do roteador e dos geradores e receptores de tráfegos são simulados através de blocos de código executados seqüencialmente em um único processador. Na emulação, todos esses componentes são executados em paralelo, pois estão mapeados fisicamente em um chip. Mesmo sendo executados em freqüências muito menores que as de um processador de Desktop (50 MHz nos experimentos descritos), a taxa de pacotes transferidos na emulação é muito maior que numa simulação Wolkotte, Hölzenspies e Smit (2007) No artigo apresentado por Wolkotte, Hölzenspies e Smit (2007), também é verificado um melhor desempenho na emulação se comparado com a simulação. Nesse trabalho, o gerador de tráfego é implementado por software e executado em um processador ARM9 externo ao chip de FPGA no qual a rede é implementada, essa abordagem facilita a definição de novos testes e a análise dos resultados e permite avaliar o desempenho de grandes sistemas paralelos baseados em NoC sintetizados em FPGA de 80 a 300 vezes mais rápido do que a avaliação de um modelo 53

55 SystemC sendo executado em um computador. A Figura 16 mostra a distribuição geral dos blocos principais que compõem a plataforma. Figura 16. Visão esquemática do hardware Fonte: Wolkotte, Hölzenspies e Smit (2007). Essa plataforma é composta pelos seguintes componentes: Placa de SoC: contém um dual-core ARM, que é um processador de propósito geral. O SoC está conectado a 1 MB de memória RAM (Random Access Memory - Memória Estática de Acesso Aleatório) e a vários periféricos e conectores. Um dos conectores conecta a placa FPGA com a placa de SoC. Este conector contém uma memória de interface de 32 bits. Através desta, pode-se controlar a lógica do FPGA e trocar blocos de dados entre a RAM do SoC e da memória instanciada no FPGA. A simulação é controlada por software nos processadores ARM. Este software é dividido em processos que se comunicam via buffers cíclicos. Todos os processos podem ser executados em paralelo e não possuem dependências; e Placa de FPGA: a placa de FPGA em si não tem uma memória externa distinta. A implementação do FPGA pode ser dividida em duas grandes partes. A parte do roteador que descreve a lógica de um único roteador e sua interface de estímulos. E a parte global que controla o FPGA e a NoC simulada (WOLKOTTE, HÖLZENSPIES e SMIT, 2007). 54

56 2.4.3 Wang, Jerger e Steffan (2010) Nesse trabalho apresentado por Wang, Jerger e Steffan (2010), uma solução flexível para emulação de NoC implementada em FPGA, denominada DART, sua configuração é desassociada e independente e segundo os autores, essa arquitetura permite uma maior velocidade para implementar diferentes ambientes de simulação, pois não é necessário reescrever um projeto HDL para cada execução para outras estruturas de NoCs. Para o desenvolvimento desse trabalho, foi utilizado um FPGA VIRTEX 2 PRO. O resultado dos experimentos foi comparado com o resultado obtido por um softaware de simulação de NoC desenvolvido em SystemC com configurações equivalentes para ambos os casos e executado em um computador com processador Intel Core 2 Quad de 2.66 Ghz de Clock e sistema operacional Linux. Foi constatado que esse experimento com DART implementado em hardware resultou em um valor 300 vezes menor que o tempo resultante no simulador em software. A arquitetura do DART é composta por três componentes básicos, são eles: Filas de Flits (Flits Queues FQs), Geradores de Tráfego (Traffic Generators - Tgs) e Roteadores (Routers). A Figura 17 ilustra a arquitetura do DART e através dela é possível observar que cada nodo contém um FQ, um TG (embora este possa ou não ser usado, dependendo da aplicação), e um Router. Também é possível observar que o FPGA é conectado em um Host PC através de uma porta de comunicação RS-232, por onde são enviados as configurações e os comandos de operação e são recolhidos os dados estatísticos. 55

57 Figura 17. Modelo da arquitetura DART Fonte: Adaptado de Wang, Jerger e Steffan (2010). Os nodos são agrupados em partições e ligados a um barramento onde todos estão interconectados entre si, permitindo uma comunicação entre qualquer par de nodos. O DART restringe a comunicação através da topologia adotada para o modelo de NoC que ele está simulando e cada nodo pode ser configurado com propriedades específicas de cada componente, sem a necessidade de alterar o modelo DART HDL. Neste trabalho, foi apresentado um modelo de mecanismo de simulação flexível para NoC, que garante um ganho expressivo de tempo se comparado aos modelos de simuladores de NoC baseados em softwares, também é possível integrar o DART a um sistema completo de simulação de NoC, substituindo o tráfego sintético gerado pelos TGs. 56

58 2.5 DISCUSSÃO No âmbito do projeto SoCIN, a abordagem baseada na simulação em nível RT tem utilizado a implementação em SystemC (ZEFERINO et al., 2005). Mais recentemente, começou-se um trabalho visando desenvolver uma plataforma numa abordagem similar à utilizada por Genko et al. (2005). Nesse contexto, foi desenvolvida uma primeira versão de modelos sintetizáveis de um gerador e de um medidor de tráfego (PEREIRA; ZEFERINO, 2008), os quais foram descritos em VHDL e validados por simulação e em dispositivo físico. Os trabalhos discutidos neste capítulo representam abordagens utilizadas pelos grupos de pesquisa para avaliar suas contribuições na área de NoCs. Na rede SPIN, utilizada por Zeferino (2003) e Adriahantenaina et al. (2004), e rede Hermes, utilizada por Mello (2006) e por Carara (2007), foram utilizada simulação no nível RT, enquanto que na QNoC, utilizada por Bolotin et al. (2004), a simulação é realizada em nível de transação (TL). A primeira abordagem oferece maior precisão e a segunda menor tempo de simulação. As abordagens baseadas na emulação em hardware, utilizadas por Genko et al. (2005), Wolkotte, Hölzenspies, Smit (2007) e Wang, Jerger e Steffan (2010) mantém a precisão dos resultados e reduz ainda mais o tempo da avaliação se comparado com as simulações executadas por software. As limitações das emulações em hardware estão na escalabilidade dos experimentos (em algumas das abordagens), que depende da capacidade de integração do FPGA utilizado e na menor flexibilidade, pois modificações no gerador e no medidor de tráfego são mais difíceis de serem feitas, devido alterações serem necessárias em praticamente toda a estrutura do projeto e na menor observabilidade, pois os medidores de tráfego são projetados dentro de um cenário de custo mais restrito e, num simulador, é mais fácil de inserir pontos de monitoração da simulação. A Tabela 7 permite observar a síntese dos trabalhos citados neste capítulo. Foram analisados esses trabalhos objetivando uma integração do estudo das técnicas de avaliação de desempenho e das arquiteturas de NoCs, assunto que é tratado no contexto geral deste trabalho. 57

59 Tabela 7. Caracterização de trabalhos sobre avaliação de desempenho de NoCs. Autores (Ano) Objetivo Simulação Emulação Taxa de Injeção Adriahantenaina et al. (2003) Bolotin et al. (2004) Mello (2006) Carará (2007) Genko et al. (2005) Wolkotte, Hölzenspies e Smit (2007) Wang, Jerger e Steffan (2010) Comparação de arquiteturas baseadas em rede com barramento Proposta de um fluxo de projeto de NoCs com suporte a QoS Apresenta uma proposta para garantir a qualidade de serviço em NoCs Estratégias Para otimização de desempenho em redes NoCs Ambiente de emulação para exploração de soluções de comunicação baseadas em NoCs Permite verificar o desempenho de grandes sistemas paralelos em NoC Permite a reformulação de projeto da NoC sem a necessidade de reescrever os parâmetros módulos HDL Sim Não Variável Sim Não Constante e variável (4 níveis de serviço) Sim Não Variável Sim Não Constante Não Sim Variável Sim Sim Variável Sim Sim Variável A Tabela 8 exibe a comparação entre os valores resultantes da avaliação de desempenho das emulações, obtidos dos trabalhos discutidos neste capítulo (Genko et al. (2005), Wolkotte, Hölzenspies, Smit (2007) e Wang, Jerger e Steffan (2010)) que tiveram suas arquiteturas baseadas em experimentos diretamente em dispositivos de hardware, comparado ao desempenho alcançado pelos mesmos experimentos executados em simulação baseadas em software. 58

60 Tabela 8. Valores resultantes nas emulações comparados com os valores das simulações. Autores (Ano) Genko et al. (2005) Wolkotte, Hölzenspies e Smit (2007) Wang, Jerger e Steffan (2010) Vantagem na Emulação Até vezes De 80 até 300 vezes Até 300 vezes No capítulo a seguir, é descrito o desenvolvimento do trabalho proposto. Foi desenvolvida uma plataforma de avaliação de desempenho para a rede SoCIN implementada em FPGA. Essa plataforma é uma ferramenta que colabora com o projeto de SoCs utilizando NoCs, pois permite avaliar o comportamento da NoC em um ambiente físico, equivalente ao projeto final de um SoC, com estimativas reais de custo de operação, como latência média, latência acumulada, latência mínima e máxima, largura de banda requerida entre outros. 59

61 3 PROJETO DA PLATAFORMA PARA AVALIAÇÃO DE DESEMPENHO ON-CHIP DA REDE SOCIN O foco principal deste trabalho reside no desenvolvimento de uma plataforma para avaliação de desempenho da rede SoCIN baseada na emulação em FPGA (ou seja, on-chip). Este capítulo apresenta uma visão geral dessa plataforma e a descrição dos componentes utilizados e implementados nesta dissertação. 3.1 VISÃO GERAL A plataforma de avaliação de desempenho on-chip da rede SoCIN é constituída por componentes de hardware e de software. Os componentes de hardware são integrados em um SoC composto por instâncias do roteador ParIS e de IPs de geração de tráfego (TG Traffic Generator) e de medição de tráfego (TM Traffic Meter) 4, além de módulos de comunicação e controle (ver Figura 18). Figura 18. Ilustração da organização dos componentes da plataforma 4 Os módulos TG e TM foram desenvolvidos por Pereira (2008). 60

62 Além desses, o sistema integrado no FPGA inclui um módulo de comunicação e controle (CCM Communication and Control Module) e um bloco de identificação do fim da emulação (ECB Emulation Control Block). O CCM se comunica com um software chamado Supervisor que é executado em um computador. O Supervisor é responsável por configurar o SoC, definindo o tráfico a ser gerado pelos TGs, e coletar os dados dos TMs para a análise dos resultados da emulação. A conexão entre o computador e o CCM é feita por meio de um driver de comunicação e de um cabo serial (RS-232). O driver implementa uma camada de comunicação entre o Supervisor e o CCM, tornando transparente ao Supervisor os aspectos referentes ao protocolo de comunicação serial utilizado. O CCM é responsável pela comunicação com o Supervisor, pela configuração e controle dos blocos associados ao experimento (TGs, TMs e ECB) e pelo envio dos dados medidos pelos TMs ao Supervisor. O ECB (Emulation Control Block) é um bloco de controle da emulação que recebe um parâmetro de configuração indicando o número total de pacotes a serem transferidos pela rede. Este monitora a entrega de cada pacote através de sinais que indicam quando um terminador de pacote é recebido por um TG. A partir desses sinais, este determina o número de pacotes recebidos ao longo da emulação. Quando o número de pacotes recebidos se iguala ao número de pacotes a serem transferidos, o ECB envia um sinal ao CCM indicando que a emulação foi concluída. O ECB também é responsável por um contador de ciclos global utilizado para informar o número de ciclos decorridos desde o início do experimento aos blocos TG e TM. Este habilita o seu incremento no início da emulação e paralisa-o no final, quando então o seu valor é disponibilizado ao Supervisor para o cálculo do tráfego aceito (flits/ciclo/nodo). A Figura 19 apresenta uma estrutura em camadas da plataforma que ilustra como seus componentes se relacionam. Na figura, são destacadas as camadas de software (Supervisor e Driver) e de hardware (CCM) que foram alvo deste trabalho. As camadas inferiores (ECB, Cadeia de TGs, Cadeia de TMs e Rede de Roteadores ParIS) foram desenvolvidas em trabalhos realizados previamente por pesquisadores do grupo de pesquisa ao qual esta dissertação está associada. 61

63 Figura 19. Direção do fluxo de projeto da plataforma desenvolvida A Figura 20 ilustra a ordem seqüencial de execução que descreve a operação da plataforma. Nessa figura, é possível observar as principais funções de cada componente da arquitetura e as principais ligações que cada componente faz com outros componentes do projeto. O supervisor configura o ECB e os TGs, após as configurações serem encerradas, o supervisor habilita o ECB, os TGs e os TMs. Os TMs informam o ECB quando os pacotes são recebidos e se todos os pacotes foram entregues. O ECB informa o supervisor sobre o fim do experimento e o supervisor solicita aos TMs os resultados. Os TMs ficam encarregados de enviar para o supervisor os dados recolhidos da execução do experimento. 62

64 Supervisor configura ECB CCM ECB TGs TMs configura TGs START todos injetados pacote recebido pacote recebido fim de experimento solicita resultados dados coletados Figura 20. Ordem seqüencial de execução da plataforma 3.2 COMPONENTES DE HARDWARE PARA EXECUÇÃO DOS EXPERIMENTOS Esta seção descreve os componentes de hardware da plataforma utilizados para realização dos experimentos: TGs, TMs e ECB. Esses blocos foram desenvolvidos por Pereira e Zeferino (2008) Bloco de controle da emulação - ECB A Figura 21 ilustra a organização do caminho de dados do ECB de forma simplificada. Este inclui: (i) um registrador de configuração que armazena o número de pacotes a serem transferidos; (ii) um circuito acumulador (registrador e somador) que contabiliza a quantidade de pacotes entregues; (iii) um comparador de igualdade para comparar esses dois valores e indicar o final do experimento; e (iv) um contador de ciclos que informa o tempo decorrido aos TGs e aos TMs. 63

65 Figura 21. Organização simplificada do ECB Fonte: Pereira (2008) Núcleos de geração e de medição de tráfego TG e TM Os módulos de geração e de medição de tráfego, TG e TM, são conectados às portas locais dos roteadores ParIS da rede SoCIN. Cada TG injeta e retira pacotes da rede, enquanto que o TM monitora o canal de entrada do TG, coletando dados para análise do desempenho da rede. Cada fluxo gerado pelo TG (Traffic Generator) possui um descritor com as informações necessárias para identificar as características do tráfego a ser gerado. Conforme a Figura 22, que ilustra esse descritor, o campo Taxa de Injeção Requerida possui 7 bits de largura para registrar valores de 1 a 100, o campo HLP (Higher Level Protocol) refere-se a um campo do cabeçalho do modelo SoCIN reservado para protocolos de mais alto nível e para futuras implementações da SoCIN. Sua largura é função dos demais campos do cabeçalho do pacote, ocupando os bits não utilizados por estes. Os outros campos do descritor de fluxo possuem largura parametrizável e define a taxa de injeção requerida pelo fluxo, o número de pacotes a serem gerados, o comprimento dos pacotes e o intervalo entre pacotes. 64

66 Figura 22. Descritor de Fluxo Fonte: Pereira e Zeferino (2008). A Figura 23, a seguir, apresenta uma ilustração simplificada da organização do TG. Essa organização possui uma interface serial de entrada e saída usada para construção de uma cadeia de TGs (pela qual estes são configurados) e uma interface de comunicação conectada a um terminal da rede para injetar e ejetar pacotes da rede. Internamente, o TG é composto por um árbitro, uma cadeia de descritores de fluxo (FD Flow Descriptor) e um gerador de fluxo (FG Flow Generator). Cada FD é responsável por armazenar a configuração de um fluxo e determinar o ciclo em que um novo pacote será enviado. Isto é feito através da comparação do valor de um registrador que armazena o ciclo que o próximo pacote deve ser enviado com o valor do contador de ciclos global responsável por contar o número de ciclos decorridos desde o início da emulação. Quando o contador de ciclos global é igual ou maior que o ciclo de envio do próximo, um pedido é enviado para o árbitro, que escalona todos os pedidos dos FDs e escolhe um deles para ser ligado ao FG. O FG então injeta um pacote na rede para o FD selecionado contendo as seguintes informações: o endereço destino e origem, a largura de banda necessária e o ciclo em que o pacote foi criado. Após o envio do pacote do FD selecionado, o FG atualiza o seu registrador com o ciclo para enviar o próximo pacote (de acordo com a largura de banda necessária) e decrementa o número de pacotes para serem enviados ao seu fluxo (PEREIRA, p. 51, 2008). 65

67 Descritor de Fluxo Recebe do TG anterior Arbitro... FD n-1 FD n-2 FD 0 Envia para o próximo TG Controle Gerador de Fluxo Envia para o Terminal da NoC Caminho de Dados Recebe do Terminal da NoC Figura 23. Organização Simplificada do TG Fonte: Pereira e Zeferino (2008). Os núcleos medidores de tráfego (TMs) são responsáveis pela coleta dos resultados para uma posterior geração de relatório pelo software Supervisor. Na Figura 24, é mostrada a organização do caminho de dados do medidor de tráfego desenvolvido por Pereira e Zeferino (2008). Ela tem uma interface para o Contador de Ciclos Global, um canal de entrada para coletar dados a partir do terminal da NoC (portal local) e uma interface serial (com uma entrada e uma saída), a qual é usada para a criação de uma cadeia de TMs visando o envio dos dados coletados na emulação ao Supervisor. Recebido do TM anterior > Latência Máxima < Latência Minima Latência Acumalada Pacotes Acumalada Flits Acumulad os Banda Req. Acu. Envia para o próximo TM Contador Global Recebe do terminal da NoC Figura 24. Organização Simplificada do TM Fonte: Adaptado de Pereira e Zeferino (2008). 66

68 3.3 COMPONENTES DE HARDWARE E DE SOFTWARE PARA CONFIGURAÇÃO DA PLATAFORMA O Software Supervisor O software Supervisor é responsável por configurar a plataforma de hardware, comandar as execuções dos experimentos e receber os resultados coletados pela plataforma. Este foi desenvolvido para ser integrado à ferramenta de simulação de NoCs chamada de BrownPepper, que consiste em um ambiente integrado de avaliação de desempenho de NoCs baseado em simulação e desenvolvido utilizando bibliotecas do SystemC. O BrownPepper inclui um conjunto de ferramentas que automatiza várias tarefas necessárias para a exploração do espaço de projeto de NoCs (BRUCH, J. V.; PIZZONI, M. R.; ZEFERINO, 2009). A Figura 25 ilustra o fluxo de projeto que integra o software Supervisor à ferramenta BrownPepper e à interface de comunicação serial RS-232 (UART). Inicialmente (1), o Supervisor lê o arquivo traffic.tcf (1) e gera o arquivo intermediário traffic.mif. Após (2), o Supervisor gera o arquivo traffic.bst, o qual, finalmente (3) é transferido para o módulo CCM, no FPGA, por meio da interface RS-232. As subseções a seguir descrevem a função e a estrutura desses arquivos. 67

69 } Figura 25. Fluxo de projeto do Supervisor Descrição do Arquivo traffic.tcf O arquivo traffic.tcf gerado pela ferramenta BrownPepper é constituído por M N seções, no qual M é o número de colunas e N é o número de linhas da rede em malha 2-D. Cada seção inclui um rótulo identificador do TG (tg_x_y), um identificador do número de fluxos do TG (maior ou igual a 0) e por descritores de fluxo, um para cada fluxo. O descritor é constituído por uma seqüência de 16 parâmetros, conforme mostrado no Quadro 1, o qual ilustra um arquivo de configuração de tráfego que define um fluxo a ser gerado pelo TG de coordenadas (0, 0). 68

70 Tg_0_ tg_0_1 0 tg_1_0 0 tg_1_1 0 // Parameters 0 type 1 x_dest 2 y_dest 3 flow_id 4 traffic_class 5 switching_type 6 pck_2send 7 deadline 8 required_bw 9 payload_length 10 idle_cycles 11 iat 12 burst_size 13 last_payload_length 14 alfa_on 15 alfa_off Quadro 1. Exemplo de arquivo traffic.tcf para uma rede 2x2 gerado pelo BrownPepper Fonte: Bruch, Pizzoni e Zeferino (2009). Na ferramenta BrownPepper, o descritor de fluxo é constituído pelos seguintes campos: Type : tipo de injeção (baseado em pareto On-Off ou não); x_dest: indica o endereço destino na coordenada do eixo x; y_dest: indica o endereço destino na coordenada do eixo y; flow_id: determina o controle de fluxo; traffic_class: classe do tráfego (Real-Time 0/1, Non Real-Time 0/1); switching_type: define o modelo de chaveamento; pck_2send: determina o número de pacotes para ser enviado (em pacotes); 69

71 deadline: determina o número de ciclos para terminar a execução (em ciclos); required_bw: define a largura de banda requerida (em mbps); payload_length: define o comprimento dos pacotes (em flits); idle_cycles: intervalo de envio entre o último pacote e o próximo a ser enviado (em ciclos); iat (em ciclos) : tempo entre chegadas de pacotes sucessivos; burst_size: quantidade de pacotes que são enviados em seqüência (em pacotes); last_payload_length : especifica o comprimento do último pacote enviado (em flits); alfa_on: parâmetro do pareto On-Off; e alfa_off: parâmetro do pareto On-Off. Descrição do Arquivo traffic.mif A partir do arquivo traffic.tcf, o supervisor gerado um arquivo intermediário cujo formato é baseado no modelo de arquivo de inicialização de memória (MIF - Memory Initialization File) da Altera 5. A geração deste arquivo poderia ser dispensada com a conversão direta do traffic.tcf no arquivo de bitstream (traffic.bst). No entanto, este é gerado para facilitar a verificação dos valores dos campos de configuração dos fluxos, pois cada um deles é representado por uma linha do arquivo MIF (no bitstream, esses campos são integrados em pacotes de comunicação, o que dificulta a análise). O arquivo traffic.mif é constituído por um vetor de valores, conforme descrito a seguir: Posição 0: Número total de pacotes a serem enviados por todos os geradores de tráfego da plataforma (usado para configurar o bloco de controle da emulação, o ECB); Demais posições: Configuração dos descritores de fluxo. No exemplo, são listados, em sequência, os descritores de fluxo de 3 a 0 do primeiro TG do sistema (de coordenadas (0,0)). 5 O uso desse formato se deve à necessidade de realizar uma geração de arquivo compatível com a versão anterior da plataforma de emulação que se baseava em FPGA da Altera. 70

72 O TG sintetizável utiliza um descritor de fluxo que inclui um subconjunto dos campos adotados na ferramenta BrownPepper, os quais são relacionados na Tabela 9. Tabela 9. Especificações dos arquivos traffic.mif e traffic.tcf Campo do traffic.mif Campos do traffic.tcf Observação dest_addr x_dest y_dest Operador concatenação hlp 0 Reservado req_bw [required_bw/(data_width fclk)] 100 req_bw em %; fclk em MHz Pck_size payload_length + 1 flits Wait_cycles idle_cycles ciclos No Quadro 2, é ilustrado um exemplo de arquivo traffic.mif, com as descrições dos campos que compõem cada fluxo correspondente ao arquivo traffic.tcf. São mostrados o parâmetro a ser enviado ao ECB (total_pck2send) e os parâmetros de configuração de fluxo do TG de coordenadas (0,0), assumindo-se que os demais TGs não irão gerar fluxo (seus parâmetros são todos iguais a 0). WIDTH=32; DEPTH=97 ADDRESS_RADIX=UNS DATA_RADIX=HEX CONTENT BEGI 0: A --total_pck_2send TG_0_ Flow 3 1 : ; -- dest_addr 2 : ; -- hlp 3 : ; -- req_bw 4 : A; -- pck_2send 5 : ; -- pck_size 6 : FC; -- wait_cycles -- Flow 2 [7..12] : Flow 1 [13..18] : Flow 0 [19..24] : (...) Quadro 2. Exemplo de arquivo traffic.mif para uma rede 2x2 - apenas para o TG (0,0) 71

73 Descrição do arquivo traffic.bst O arquivo traffic.bst é uma versão do arquivo traffic.mif que contém uma seqüência de bytes utilizada para configurar o ECB (Emulation Control Block) e os TGs (Traffic Generators). O arquivo é formado por uma seqüência de pacotes de 32 bits contendo até 24 bits de dado (bit 0 ao bit 23), cinco bits que definem o tamanho do campo de dados (bit 24 ao bit 29) e três bits que definem um comando que informa ao CCM o tipo do pacote e a operação a ser realizada com os dados do pacote (ex. envio dos dados à cadeia de TGs), conforme é ilustrado na Figura Comando Tamanho Dados (até 3 bytes) Figura 26. Pacote do traffic.bst. Tabela 10. A lista de comandos utilizados para controlar a execução dos experimentos é mostrada na Tabela 10. Especificações dos comandos para execução dos experimentos Comando Descrição 000 Comando reservado (Reservado) 001 Habilita a configuração dos TGs (TG_Config_ENA) 010 Comando reservado (Reservado) 011 Habilita a configuração do ECB (ECB_Config_ENA) 100 Inicia a emulação (Start_Emulation) 101 Habilita a coleta de dados dos TMs (TM_Collect_ENA) 110 Indica o final da Emulação (End_Of_Emulation) 111 Coleta de dados (Data_Collected) 72

74 Os parâmetros de configuração do ECB e dos TGs são empacotados obedecendo as dimensões definidas, as quais são ilustradas na Tabela 11 e na Tabela 12. Tabela 11. Descrição dos campos de configuração do ECB ECB_PCK_2SEND_WIDTH Nome Tamanho Definição ECB_PCK_RECEIVED_ACC_WIDTH Fonte: Adaptado de Pereira (2008). 20 bits 24 bits Largura do campo que define o número de pacotes para ser enviado ao registrador Largura do campo que define o número de pacotes acumulados para ser recebidos Tabela 12. Descrição dos campos dos descritores do TG Nome Tamanho Definição DEST_ADDR_WIDTH 8 bits Largura do campo de endereço de destino HLP_WIDTH 9 bits Largura do HLP (high logic protocol) REQ_BW_WIDTH 7 bits Largura do campo de banda requerida NEXT_PCK_CYCLE_WIDTH PCK_2SEND_WIDTH WAIT_CYCLES_WIDTH Fonte: Adaptado de Pereira (2008). 16 bits 16 bits 16 bits Largura que armazena o ciclo do próximo pacote Largura do campo do número de pacotes para ser enviado Largura do campo que armazena o número de ciclos para aguardar O Quadro 3 apresenta o arquivo traffic.bst para os arquivos traffic.mif e traffic.tcf ilustrados anteriormente. Destaca-se que o traffic.bst é gerado na ordem reversa do arquivo traffic.mif de modo que os primeiros pacotes referem-se aos parâmetros do TG de coordenadas (1,1) e os últimos ao TG de coordenadas (0,0) e ao ECB. 73

75 1. 0x x x x x x x x x x x x x x x x x380500FC 18. 0x A 19. 0x x A Quadro 3. Exemplo de arquivo de configuração traffic.bst O Driver de Comunicação Serial RS-232 O driver de comunicação serial entre o Supervisor e o CCM lê o arquivo de configuração traffic.bst e envia o seu bitstream pela porta serial RS-232. Esse software é executado no PC e permite o acesso ao dispositivo de comunicação RS-232, controlando todo o fluxo de entrada e saída de dados por esse canal Módulo de Comunicação e de Controle O Módulo de Comunicação e Controle (CCM - Communication and Control Module) é responsável pela comunicação com o Supervisor e pela configuração dos TGs e do ECB, pelo controle da execução (habilitação e identificação do fim do experimento), pela coleta dos dados dos TMs e pelo envio dos dados recolhidos ao Supervisor (listados na Tabela 13). 74

76 Tabela 13. Descrição dos campos coletados do TM Nome Req_bw_acc Flits_acc Packets_acc Latency_acc Min_latency Max_latency Definição Soma acumulada dos requisitos de largura de banda de todos os pacotes recebidos Número total de flits recebidos Número total de pacotes recebidos Soma da latência de todos os pacotes recebidos A menor latência entre os pacotes recebidos A maior latência entre os pacotes recebidos A organização do módulo de comunicação e controle (CCM - Communication and Control Module) é ilustrada na Figura 27. Este é constituído por um processador MicroBlaze da Xilinx e interconectado a uma UART e a um periférico específico (core) por meio do barramento PLB (Processor Local Bus), ambos integrados no mesmo FPGA do sistema constituído por roteadores ParIS e núcleos TG e TM. CCM Micro Blaze Core UART Figura 27. Organização interna do módulo CCM No MicroBlaze, é executado um sistema embarcado que se comunica com o PC através da UART e com o SoC através do periférico. O periférico realiza a adaptação do protocolo PLB ao protocolo adotado para configuração dos TGs e dos ECBs e para a coleta de dados dos TMs. Este é formado por uma máquina de estados de controle e por um caminho de dados constituído por três registradores de deslocamento (serial paralelo, paralelo-paralelo e paralelo-serial), por um contador de bits transferidos e por um comparador. A Figura 28 ilustra o diagrama RTL do caminho de dados do periférico, gerado a partir da síntese de sua descrição em VHDL. 75

77 Figura 28. Estrutura interna do caminho de dados do periférico (core) 3.4 IMPLEMENTAÇÃO E VALIDAÇÃO Supervisor e Driver O software Supervisor foi implementado em C++ e executado no sistema operacional Linux Ubuntu versão Sua função principal é gerar um conjunto de dados compatíveis para a configuração dos experimentos. A comunicação com a placa de prototipação é feita através de um driver de comunicação, desenvolvido em linguagem C e estabelece o ajuste de protocolos dessa troca de informação entre o PC que é executado o software Supervisor e a placa que contém o SoC desenvolvido nesse trabalho. Para validar e verificar a consistência dos dados transmitidos pelo algoritmo de criação do bitstream, foi desenvolvido um ambiente de teste utilizando as portas RS-232 de dois computadores distintos e interligando-as através de um cabo de comunicação serial. No computador origem, foi executado o software Supervisor que, a partir de um arquivo traffic.tcf, gerou um bitstream e o enviou ao computador destino por meio da interface RS-232. No computador destino, foi executado um software de controle de entrada e saída de dados pela porta RS-232, denominado Terminal Versão 1.9b, para receber e exibir o bitstream. A Figura 29 ilustra um experimento realizado em que o conteúdo do arquivo traffic.bst, enviado pelo Supervisor, e o bitstream recebido pelo software 76

78 terminal, o qual confirma o recebimento correto dos pacotes. Por exemplo, o último pacote do bitstream (0x ) é apresentado como , pois o byte mais significativo é o último a ser transferido. 0x x x x x x x x x x x x x x x x x380500FC 0x380000C8 0x Figura 29. Arquivo recebido pela RS-232 no formato Hexadecimal CCM O sistema embarcado que é executado no processador MicroBlaze recebe do software Supervisor os pacotes de dados para configuração e execução dos experimentos e converte esses dados em um modelo adaptado compatível com as estruturas dos pacotes de dados para a configuração dos TGs, ECB e coleta de dados dos TMs. Para realizar a validação dos blocos construídos, foi executada uma simulação na ferramenta de desenvolvimento Quartus II da Altera. Foi descrito um modelo integrado incluindo o periférico do CCM e os demais componentes do SoC (uma rede 2x2, quatro TGs, quatro TMs e o ECB). Para a configuração dos TGs e do ECB, foi utilizada a seqüência de pacotes ilustrada no Quadro 4, a qual define um fluxo de comunicação que envolve o envio de 10 pacotes com 4 flits cada, do TG de coordenadas (0,0) para o TG de coordenadas (1,1). Cada pacote é formado por oito dígitos hexadecimais, sendo dois deles o cabeçalho e os outros seis carregam os dados do pacote. 77

79 fc A A Quadro 4. Arquivo de configuração da Plataforma (valores em Hexadecimal) Na Figura 30, é ilustrada a visão geral da simulação para validação da integração realizada. No primeiro momento destacado na imagem, é feita a configuração dos TGs. Na simulação, o periférico recebe pacotes de configuração pela sua interface PLB (sinais i_write e i_data) e, para cada pacote, envia um stream serial de até 24 bits para a cadeia de TGs ou para o ECB, dependendo do comando recebido e do tamanho do corpo de dados (sinais tg_config_ena, ecb_config_ena e o_shift). Após a configuração, o periférico recebe um pacote com comando de início (Start_Emulation) e gera o sinal de habilitação da simulação (emulation_ena). O fim da simulação é informado pelo pulso no sinal o_int_end_of_emulation, o qual solicita ao CCM a leitura dos dados coletados pelos TGs. Esta leitura é feita na sequência, conforme destacado na figura (sinais i_rd e o_data). 78

80 Figura 30. Visão geral da simulação Após o término da simulação, os valores coletados pelos TMs, mostrados na Tabela 14 são verificados, conforme discutido a seguir. O Quadro 5 ilustra todos os valores coletados pelos TMs, resultante da simulação descrita nesse experimento. Esses resultados são apresentados na Tabela 14 de acordo com as métricas utilizadas. Analisando-os, é possível concluir que os módulos da integração estão funcionando corretamente, pois os valores analisados do experimento estão de acordo com o esperado. Foram transferidos 10 pacotes e um total de 40 flits. A latência acumulada foi de 150 ciclos, ou seja, 15 ciclos por pacote. As latências, mínima e máxima são iguais, pois não há concorrência com outro fluxo na rede. 79

81 F F F F F800FFFF F F F F F8FF0000 F80000FF F F F F F8FFFF00 F F F F800000A F F80F000F F Quadro 5. Resultados da simulação recolhidos pelos TMs (valores ilustrados em Hexadecimal) Tabela 14. Descrição dos valores coletados do TM Nome Valor Flits_acc 40 flits Packets_acc 10 pacotes Latency_acc 150 ciclos Min_latency 15 ciclos Max_latency 15 ciclos Na Figura 31 são destacados os valores recolhidos pelos TMs e convertidos na forma decimal. Esses valores, de acordo com o projeto, são coletados pelos TMs, respeitando o comando específico de coleta de dados e posteriormente deslocados para o canal de saída de dados denominado no projeto como o_data. 80

82 Figura 31. Valores resultantes da emulação Na Figura 32, é possível perceber que a emulação é iniciada pelo sinal denominado start_emulation exatamente em 222,22 microssegundos e o termino da emulação é gerado pelo sinal denominado end_of_emulation, exatamente no ponto marcado em 593,92 microssegundos, resultando em um tempo total de emulação no FPGA de 371,7 microssegundos. Já o tempo total de simulação por software para os valores de configuração da NoC apresentado, foi de 2 minutos e 14 segundos (simulação executada em um computador com processador Intel Dual Core 2.1 GHZ modelo T6500, 2 MB de cache, 4 GB de memória RAM e sistema operacional Windows Vista 32 bits). Esse experimento indica que a emulação em hardware para esses mesmos valores é ,78 vezes mais rápida que o mesmo experimento executado por simulação em software. Não foram contabilizados os tempos para configuração e coleta dos dados. 81

83 Figura 32. Tempo previsto para a emulação Integração de hardware e de software A integração completa do sistema em FPGA (CCM + ECB +TGs + TMs) foi realizada em um modelo de sistema em VHDL com uma rede em malha 2 2, com quatro nodos compostos cada um deles por um TG, um TM e um roteador ParIS. A rede SoCIN foi configurada com os seguintes parâmetros: Largura do canal de dados: 32 bits FIFOS dos canais de entrada: 04 palavras de 34 bits (32 bits de dado + 02 bits de enquadramento (136 bits); FIFOs dos canais de saída: não usadas; Roteamento: XY; Arbitragem: Round-Robin; Controle de fluxo: baseado em créditos. 82