UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO …siaibib01.univali.br/pdf/Thiago Felski Pereira.pdfv LISTA...
71
UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR CURSO DE CIÊNCIA DA COMPUTAÇÃO GERADOR DE TRÁFEGO SINTETIZÁVEL PARA REDES-EM-CHIP Área de Sistemas Embarcados por Thiago Felski Pereira Cesar Albenes Zeferino, Dr. Orientador Itajaí (SC), julho de 2008
-
Upload
nguyentuong -
Category
Documents
-
view
213 -
download
0
Transcript of UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO …siaibib01.univali.br/pdf/Thiago Felski Pereira.pdfv LISTA...
UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
GERADOR DE TRÁFEGO SINTETIZÁVEL PARA REDES-EM-CHIP
Área de Sistemas Embarcados
por
Thiago Felski Pereira
Cesar Albenes Zeferino, Dr. Orientador
Itajaí (SC), julho de 2008
UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
GERADOR DE TRÁFEGO SINTETIZÁVEL PARA REDES-EM-CHIP
Área de Sistemas Embarcados
por
Thiago Felski Pereira Relatório apresentado à Banca Examinadora do Trabalho de Conclusão do Curso de Ciência da Computação para análise e aprovação. Orientador: Cesar Albenes Zeferino, Dr.
Itajaí (SC), julho de 2008
ii
SUMÁRIO
LISTA DE ABREVIATURAS.................................................................. iv
LISTA DE FIGURAS.................................................................................v
LISTA DE TABELAS...............................................................................vi RESUMO...................................................................................................vii ABSTRACT..............................................................................................viii 1 INTRODUÇÃO......................................................................................9 1.1 PROBLEMATIZAÇÃO ................................................................................... 10 1.1.1 Formulação do Problema............................................................................... 10 1.1.2 Solução Proposta ............................................................................................. 10 1.2 OBJETIVOS ...................................................................................................... 10 1.2.1 Objetivo Geral ................................................................................................. 10 1.2.2 Objetivos Específicos ...................................................................................... 10 1.3 METODOLOGIA.............................................................................................. 11 1.4 ESTRUTURA DO TRABALHO ..................................................................... 12
2 FUNDAMENTAÇÃO TEÓRICA ......................................................13 2.1 SISTEMAS EMBARCADOS........................................................................... 13 2.1.1 Métricas de Projeto de Sistemas Embarcados ............................................. 14 2.1.2 Tecnologias de Projeto de Sistemas Embarcados ........................................ 14 2.2 VHDL.................................................................................................................. 15 2.3 SISTEMAS INTEGRADOS EM UM ÚNICO CHIP .................................... 17 2.3.1 Interfaces padronizadas ................................................................................. 19 2.4 ARQUITETURA DE COMUNICAÇÃO DOS SOCS................................... 19 2.4.1 Topologia.......................................................................................................... 21 2.4.2 Controle de fluxo............................................................................................. 23 2.4.3 Roteamento ...................................................................................................... 25 2.4.4 Chaveamento ................................................................................................... 27 2.4.5 Chaveamento por circuito.............................................................................. 27 2.4.6 Chaveamento por pacote................................................................................ 28 2.5 GERAÇÃO DE TRÁFEGO ............................................................................. 29 2.5.1 Padrões para distribuição espacial de tráfego ............................................. 30 2.5.2 Carga oferecida ............................................................................................... 31 2.5.3 Modelagem de tráfego .................................................................................... 32 2.6 ANÁLISE DE DESEMPENHO ....................................................................... 33 2.6.1 Estimativas de desempenho de redes de interconexão ................................ 33 2.7 GERADORES DE TRÁFEGO PARA NOCS ................................................ 36 2.7.1 Fluxo de avaliação de desempenho em SystemC ......................................... 36 2.7.2 Gerador de tráfego baseado em SPP............................................................. 40
iii
2.7.3 Gerador de tráfego baseado em GPP............................................................ 41 2.7.4 Gerador de tráfego em FPGA........................................................................ 43 2.8 DISCUSSÃO ...................................................................................................... 43
3 DESENVOLVIMENTO ......................................................................45 3.1 VISÃO GERAL DA PLATAFORMA............................................................. 45 3.2 ANÁLISE DE REQUISITOS........................................................................... 47 3.2.1 Requisitos do TG............................................................................................. 47 3.2.2 Requisitos do TM ............................................................................................ 49 3.3 PROJETO ARQUITETURAL......................................................................... 50 3.3.1 Organização do TG......................................................................................... 50 3.3.2 Organização do TM ........................................................................................ 55 3.3.3 Núcleos adicionais ........................................................................................... 57 3.4 IMPLEMENTAÇÃO ........................................................................................ 58 3.5 VALIDAÇÃO POR SIMULAÇÃO ................................................................. 61 3.6 GANHO DE DESEMPENHO.......................................................................... 64 3.7 VALIDAÇÃO FÍSICA...................................................................................... 65
4 CONCLUSÕES ....................................................................................67
REFERÊNCIAS BIBLIOGRÁFICAS ...................................................69
iv
LISTA DE ABREVIATURAS
ASIC Application Specific Integrated Circuit ASIP Application Specific Instruction Set Processor BIST Build In Self Test CLEI Conferência Latinoamericana de Informática CMOS Complementary Metal Oxide Semiconductor CPLD Complex PLD DARPA Defense Advanced Research Projects Agency DFT Design For Test DSP Digital Signal Processing ECB Emulation Control Block FD Flow Descriptor FG Flow Generator FIFO First-in First-out FPGA Field-Programmable Gate Array GPP General Purpose Processor GSED Grupo de Sistemas Embarcados e Distribuídos GT Gerador de Tráfego GTS Gerador de Tráfego Simples HDL Hardware Description Language HLP Higher Level Protocol HOL Head-Of-Line blocking IP Intellectual Property MMP Markov Modulated Process NoC Network-on-Chip NRE Non-Recurring Engineering OCP Open Core Protocol PbD Plataform-based Design PLD Programmable Logic Device RAM Random Access Memory RT Register Transfer RTL Register Transfer Level SAF Store And Forward SIM Simpósio Sul de Microeletrônica SoC System-on-Chip SPP Single Purpose Processor SRAM Static Random Access Memory TCC Trabalho de Conclusão de Curso TG Traffic Generator TM Traffic Meter TR Receptor de Tráfego UNIVALI Universidade do Vale do Itajaí VCI Virtual Component Interface VCT Virtual Cut-Through VHDL VHSIC Hardware Description Language VHSIC Very High Speed Integrated Circuit VLSI Very Large Scale Integration
v
LISTA DE FIGURAS
Figura 1. Etapas de um projeto...........................................................................................................16 Figura 2. Arquiteturas tradicionais para interconexão em SoCs: (a) ponto-a-ponto e (b) multiponto
....................................................................................................................................................20 Figura 3. Tipos de topologia: (a) direta; (b) indireta..........................................................................22 Figura 4. Parâmetros para o dimensionamento da carga oferecida....................................................32 Figura 5. Padrão de configuração para estimativa de uma rede.........................................................34 Figura 6. Plataforma de avaliação de desempenho da rede SoCIN em SystemC ..............................37 Figura 7. Fluxo de avaliação de desempenho da rede SoCIN em SystemC ......................................39 Figura 8. Gerador de tráfego sintetizável para validação da rede SoCIN ..........................................41 Figura 9. Plataforma de avaliação de desempenho em hardware ......................................................42 Figura 10. Plataforma de avaliação de desempenho em hardware para a rede SoCIN......................46 Figura 11. Cadeia de TGs para uma rede 2x2 ....................................................................................50 Figura 12. Descritor de fluxo .............................................................................................................51 Figura 13. Organização simplificada do TG ......................................................................................52 Figura 14. Organização simplificada do FD ......................................................................................53 Figura 15. Organização simplificada do FG ......................................................................................54 Figura 16. Organização simplificada do TM .....................................................................................55 Figura 17. Organização simplificada do ECB....................................................................................57 Figura 18. Arquitetura da plataforma de validação integrada ............................................................59 Figura 19. Parâmetros de configuração..............................................................................................60 Figura 20. Emulação da transferência de um único pacote................................................................62 Figura 21. Emulação da transferência de vários pacotes ...................................................................64 Figura 22. Simulação do envio de 100 pacotes por fluxo ..................................................................65 Figura 23. Kit de desenvolvimento DE2 da altera .............................................................................66 Figura 24. Circuito utilizado na visualização dos resultados em diplay de 7 segmentos ..................66 Figura 25. Comparação entre os resultados obtidos na validação por simulação e física..................67
vi
LISTA DE TABELAS
Tabela 1. Visão geral dos gastos em um Cyclone II FPGA (EPC2C35F672C6) ..............................61 Tabela 2. Visão detalhada dos gastos em um Cyclone II FPGA (EPC2C35F672C6) .......................61
vii
RESUMO
PEREIRA, Thiago Felski. Gerador de tráfego sintetizável para Redes-em-Chip. Itajaí, 2008. 71 f. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação)–Centro de Ciências Tecnológicas da Terra e do Mar, Universidade do Vale do Itajaí, Itajaí, 2007. A utilização de uma aplicação em um modelo de sistema real, com processadores, memórias e dispositivos de entrada-e-saída para avaliar e validar um projeto de Redes-em-Chip (NoCs – Networks-on-Chip) é complexa e custosa em termos de tempo. Alternativamente, podem ser utilizados modelos de geradores de tráfego que injetem tráfegos a taxas e destinos específicos e permitam confirmar que o projeto está correto e ainda, extrair métricas de desempenho ou de consumo de energia. Nesta monografia, foi realizado um estudo a respeito da avaliação de desempenho de NoCs e o desenvolvimento de um conjunto de núcleos para geração e medição de tráfego a serem utilizados na construção de uma plataforma para avaliação de desempenho baseada na emulação de tráfego sobre uma NoC sintetizada em FPGA. No texto, é apresentada uma revisão de conceitos sobre sistemas embarcados e sistemas integrados em um único chip, com ênfase nos aspectos relacionados à avaliação de desempenho de NoCs. Após, apresenta-se o projeto dos núcleos sintetizáveis usados na geração e medição de trafego, os quais foram modelados em VHDL e validados por simulação e em FPGA. Palavras-chave: Sistemas Integrados. Redes-em-Chip. Geração de Tráfego.
viii
ABSTRACT
The use of an application in a real system model, with processors, memory and input/output devices
to evaluate and validate a project of NoCs (Networks-on-Chip) is complex and time costly.
Alternatively, it can be used traffic generated models which inject traffic at specific rates and
destinations, that allow to confirm if a design is correct and, furthermore, to extract performance or
energy consumption metrics. In this monography, a study was conducted regarding the
performance evaluation of NoCs and development of a number of cores for traffic generation and
measurement to be used in building a platform for performance evaluation based on emulation of
traffic on a NoC synthesized in FPGA. The text presents a revision of concepts on embedded
systems and Systems-on-a-Chip, with emphasis on aspects related to NoCs performance evaluation.
After, it is presented the design of the project of synthesizable cores used in traffic generation and
measurement, which were modeled in VHDL and validated by simulation and by FPGA.
Keywords: Systems-on-Chip. Network-on-Chip. Traffic Generator.
1 INTRODUÇÃO
O aumento do nível de integração de componentes em silício tem possibilitado a construção
de sistemas complexos em um único chip, com múltiplos processadores, memórias, periféricos e
controladores de entrada-e-saída. Tais sistemas são conhecidos como Systems-on-Chip (SoCs) ou
sistemas integrados. Os componentes de um SoC são, em geral, baseados em modelos reutilizáveis
de hardware, pré-projetados e pré-verificados, os quais são denominados núcleos ou cores
(GUPTA; ZORIAN, 1997).
A interconexão entre os núcleos de um SoC é geralmente feita por meio de barramentos.
Mas os futuros SoCs, com várias dezenas de núcleos, irão demandar arquiteturas com melhor
desempenho. Nesse cenário, as Redes-em-Chip ou Networks-on-Chip – NoCs (JANTSCH;
TENHUNEM, 2003) surgem como solução de interconexão por oferecerem desempenho e
comunicação escalável e paralelismo de comunicação, atendendo às necessidades identificadas para
os futuros SoCs.
O projeto de uma NoC envolve etapas como a especificação e o projeto arquitetural, a
implementação, a validação (por simulação e física) e a avaliação (de desempenho e de custos de
área e de energia). As duas últimas etapas podem ser feitas em modelos de sistemas reais ou
utilizando geradores de tráfego que consigam reproduzir o tráfego de sistemas reais, seja por
simulação computacional ou por emulação física. Tipicamente, os geradores de tráfego são
utilizados na avaliação e na validação de modelos de simulação. No entanto, também possuem
aplicabilidade na emulação de tráfego em dispositivos reais para validação física da rede e também
para a tomada de medidas de avaliação de desempenho e de consumo de energia da implementação
física, por exemplo.
Esses geradores de tráfego podem ser classificados como rígidos ou flexíveis. No primeiro
tipo, o tráfego é gerado por um processador de propósito específico, projetado especialmente para
este fim, enquanto que no segundo caso o tráfego é gerado por um processador de propósito geral
executando um software de modelagem de tráfego.
10
1.1 PROBLEMATIZAÇÃO
1.1.1 Formulação do Problema
Geradores de tráfego flexíveis oferecem a vantagem de facilitar a modelagem do tráfego via
software. Entretanto, os geradores de tráfego rígidos poderiam oferecer a mesma facilidade se
houvesse uma ferramenta de modelagem que permitisse a especificação do tráfego em alto nível e
produzisse, automaticamente, a configuração dos geradores.
1.1.2 Solução Proposta
A solução proposta neste Trabalho de Conclusão de Curso – TCC consiste em desenvolver
um modelo sintetizável de gerador de tráfego para Redes-em-Chip para emulação de tráfego em
hardware. Também foi desenvolvido um medidor de tráfego sintetizável que permitirá extrair dados
da resposta da rede ao tráfego injetado pelos geradores. Esses componentes serão disponibilizados
para a construção posterior de uma plataforma para avaliação de desempenho de NoCs em
dispositivos físicos baseados em lógica programável.
1.2 OBJETIVOS
1.2.1 Objetivo Geral
O objetivo geral deste projeto é desenvolver uma arquitetura de gerador de tráfego
sintetizável para validação e avaliação de Redes-em-Chip.
1.2.2 Objetivos Específicos
Os objetivos específicos deste trabalho são:
1. Caracterizar exemplos de geradores de tráfego descritos na literatura;
2. Analisar as alternativas de arquitetura de gerador de tráfego e identificar a mais
adequada para validação e avaliação de Redes-em-Chip;
3. Realizar o projeto de um gerador de tráfego;
4. Efetuar a modelagem do gerador de tráfego em linguagem de descrição de hardware;
5. Validar o modelo de gerador de tráfego em dispositivo físico; e
11
6. Documentar e divulgar o trabalho.
1.3 Metodologia
A metodologia adotada para produção deste documento se dividiu nas Etapas de Estudo,
Análise, Projeto, Desenvolvimento e Validação, Documentação e Divulgação.
Na Etapa de Estudos, foram feitos estudos referentes a temas relacionados ao projeto de
sistemas integrados em chip, incluindo conceitos como: tecnologias para o projeto de sistemas
embarcados, Redes-em-Chip e linguagens de descrição de hardware, entre outros. Após, foi
realizado um estudo sobre geradores de tráfego descritos na literatura. Como material de pesquisa,
foram utilizados livros, dissertações de mestrado e artigos científicos.
Na Etapa de Análise, foi feita a seleção da alternativa de arquitetura de gerador de tráfego a
ser implementada e o levantamento de requisitos. A partir da análise realizada na etapa anterior, foi
efetuado o projeto do gerador de tráfego e do componente complementar para a medição de tráfego.
Na fase de Desenvolvimento e Validação, foi feita a modelagem em linguagem de descrição
de hardware do gerador e do medidor de tráfego utilizando-se procedimentos de validação baseados
em simulação. Os modelos foram integrados com uma rede 2x2, sobre a qual foi feita uma
validação final por simulação para confirmar que os modelos operavam corretamente1.
Ao longo do desenvolvimento, foram elaborados artigos submetidos a eventos científicos.
Um artigo foi apresentado e publicado nos anais do SIM 2008 – Simpósio Sul de Microeletrônica
(FELSKI, T.; ZEFERINO, C. A., 2008) e um segundo artigo foi submetido ao CLEI 2008 –
Conferencia Latinoamericana de Informática e está em fase de avaliação. Por fim, a documentação
incluiu a elaboração desta monografia.
1 Até a data da defesa pretende-se realizar uma validação física em placa de prototipação de FPGA.
12
1.4 Estrutura do trabalho
Este documento está estruturado em quatro capítulos. O Capítulo 1, Introdução, apresenta
uma visão geral do trabalho.
No Capítulo 2, Fundamentação Teórica, é apresentada uma revisão bibliográfica sobre
sistemas embarcados, assim como um estudo a respeito de VHDL. Nesse capítulo, também é feita
uma descrição de sistemas integrados em um único chip e arquitetura de comunicação dos SoCs.
Por fim é feita uma análise sobre geração de tráfego, análise de tráfego e um estudo sobre geradores
de tráfego na literatura.
O Capítulo 3 apresenta o projeto detalhado do gerador de tráfego desenvolvido, incluindo
uma visão geral da plataforma; os requisitos e a organização do gerador e do medidor de tráfego. O
capítulo também discute como foi implementado o sistema, apresentando a metodologia utilizada
no desenvolvimento e o cronograma de atividades para o TCC II.
Por fim, no Capítulo 4 apresentam-se as conclusões, onde são abordados os resultados
obtidos, custo do sistema e ganho de desempenho em relação à execução de um software em um
processador de propósito geral.
2 FUNDAMENTAÇÃO TEÓRICA
Este capítulo apresenta uma síntese dos estudos realizados com uma revisão de conceitos
sobre sistemas embarcados, VHDL, SoCs, arquiteturas de comunicação para SoCs, com ênfase em
conceitos base para o entendimento de NoCs, geração de tráfego e análise de desempenho.
2.1 Sistemas Embarcados
Segundo Wolf (2002), “um sistema embarcado é qualquer computador que é um
componente em um sistema maior e que necessita de seu próprio microprocessador”.
Conforme Vahid e Givargis (2001, p. 1-3) comparando com computadores do tipo desktop,
os computadores embarcados custam muito menos e são encontrados em uma quantidade muito
maior. Por exemplo, já em 1999, uma casa estadunidense típica tinha um desktop e de 35 a 50
computadores embarcados. Esses autores destacam algumas características típicas de sistemas
embarcados:
1. Um sistema embarcado usualmente executa um programa específico repetidamente. Há
exceções como os celulares atuais, mas estas exceções representam sistemas com uma
função específica.
2. Nos sistemas embarcados as métricas de projeto são especialmente rígidas, pois devem
ter custo muito baixo, caber em um único chip, processar dados em tempo real e
consumir o mínimo de energia para estender o tempo de vida da bateria ou prevenir a
necessidade de uma fonte ou de um dispositivo de resfriamento.
3. Devem reagir continuamente a mudanças no ambiente e computar certos resultados em
tempo real, sem atrasos.
De acordo com Wolf (2002) os primeiros microprocessadores eram tão limitados que dizer
que eles “computavam” seria generosidade. Sendo que a função primária desses
microprocessadores era controlar os dispositivos de entrada e saída; e melhorar o desempenho
desses sistemas requeria mais habilidade que ciência. Atualmente os sistemas embarcados podem
suportar dispositivos, sistemas operacionais e aplicações carregadas pelo usuário, assim como os
desktops, mas com menos recursos elétricos e de energia, requerendo atenção tanto a software
quanto a hardware.
14
2.1.1 Métricas de Projeto de Sistemas Embarcados
Uma métrica de projeto é uma característica mensurável da implementação de um sistema.
De acordo com Vahid e Givargis (2001, p. 4-5) um projetista de sistemas embarcados deve
construir um produto que cumpra a funcionalidade desejada, mas o grande desafio é aperfeiçoar
simultaneamente várias métricas de projeto. Métricas comumente usadas no projeto de sistemas
embarcados incluem:
• Custo de projeto (ou custo NRE – Non-Recurring Engineering costs);
• Custo unitário;
• Tamanho (ex. bytes para softwares e portas ou transistores para hardware);
• Desempenho (ex. latência e vazão – throughput);
• Consumo de energia;
• Flexibilidade;
• Tempo de projeto;
• Time-to-market (ou seja, tempo para desenvolver o sistema a um ponto que possa ser
disponibilizado comercialmente);
• Correção do sistema;
• Segurança; e
• Tolerância a falhas.
2.1.2 Tecnologias de Projeto de Sistemas Embarcados
Vahid e Givargis (2001, p. 9) definem tecnologia como a maneira que se realiza uma tarefa,
usando em especial processos, métodos ou conhecimento. Três tipos de tecnologias são centrais
para o projeto de sistemas embarcados:
• Tecnologia de processador: consiste da arquitetura do motor computacional usado para
implementar a funcionalidade desejada pelo sistema. Existem três tipos principais que
são o GPP (General Purpose Processor – Processador de Propósito Geral), o ASIP
(Application Specific Instruction Set Processor – Processadores de Aplicação
Específica), o SPP (Single Purpose Processor – Processadores de Propósito Único). Os
15
primeiros são os microprocessadores de uso geral, como MIPS e ARM. Os ASIPs são
processadores especializados destinados a uma classe de aplicações, como, por exemplo,
os microcontroladores para aplicações de controle, e os processadores de DSP (Digital
Signal Processing), para aplicações de processamento de sinais;
• Tecnologia de circuito integrado: varia com o grau de customização do CI, também
conhecido como chip, dispositivo semicondutor constituído de um grupo de transistores
conectados e outros dispositivos, sendo CMOS (Complementary Metal Oxide
Semiconductor – Semicondutor de Óxido Metálico Complementar) a tecnologia mais
utilizada atualmente. Os três principais tipos de tecnologia de circuito integrado são:
VLSI (Very Large Scale Integration – Integração em Escala Muito Alta) ou full-custom,
ASIC (Application Specific Integrated Circuit – Circuito Integrado de Aplicação
Específica) ou semi-custom, e PLD2 (Programmable Logic Device – Dispositivos de
Lógica Programável); e
• Tecnologia de projeto: consiste em refinar o sistema em vários níveis de abstração.
Existem vários tipos de abstração em que um sistema pode ser especificado:
especificação do sistema, do comportamento, dos registros de transferência (RT –
Register Transfer) e lógica.
2.2 VHDL
No início dos anos 80, a DARPA (Defense Advanced Research Projects Agency), agência
de pesquisa associada ao Departamento de Defesa dos Estados Unidos da América promoveu o
desenvolvimento de uma linguagem padrão de descrição de circuitos para uso no projeto VHSIC
(Very High Speed Integrated Circuit – Circuito Integrado para Velocidade Muito Alta), a fim de
facilitar o intercâmbio de informações entre diversos fornecedores de equipamentos. Essa
linguagem foi denominada VHDL (VHSIC Hardware Description Language – Linguagem de
Descrição de Hardware) e em 1987 foi padronizada pelo IEEE (Institute of Electrical and Electronic
Engineers – Instituto de Engenheiros Elétricos e Eletrônicos) (IEEE Std. 1076-1987), sendo
2 Os autores referenciados (VAHID; GIVARGIS, 2002) utilizam o termo PLD de forma abrangente, englobando dispositivos de lógica programável com diferentes arquiteturas e níveis de densidade lógica, como os CPLDs (Complex PLDs) e os FPGAs (Field-Programmable Gate Array).
16
revisada em 1993 (IEEE Std. 1076-1993). Segundo D’Amore (2005, p. 1-6), o VHDL possui as
seguintes características:
• Linguagem concorrente, com exceção de regiões específicas de código. A concorrência
de um evento em um sinal leva à execução de todos os comandos sensíveis àquele sinal.
Da mesma forma que em um circuito, a mudança de um sinal em um determinado nó
afeta todas as entradas ligadas a esse ponto do circuito;
• A descrição pode conter diversos níveis de abstração, variando da representação do
comportamento do sistema à interligação de componentes, abordagem conhecida como
projeto top-down;
• Assim como as linguagens de programação, o VHDL permite a definição de
subprogramas na forma de procedimentos e funções;
• A linguagem não faz distinção entre caracteres maiúsculos ou minúsculos (não é
sensível à caixa), como ocorre, por exemplo, na linguagem “C”; e
• Permite descrever modelos de simulação e de síntese, porém, como não foi concebida
originalmente para síntese; nem todas as construções da linguagem são suportadas para
esse fim.
D’Amore (2005, p. 3-6) define os três passos em um projeto empregando uma linguagem de
descrição de circuitos como o VHDL. Esse fluxo é ilustrado na Figura 1 e descrito logo a seguir.
Figura 1. Etapas de um projeto
Fonte: D’Amore (2005, p. 3).
17
• 1º passo: A partir da especificação de um projeto, realizar uma descrição VHDL e
submetê-la a um simulador para validá-la com a aplicação de um conjunto de estímulos
de teste.
• 2º passo: Submeter a descrição a uma ferramenta de síntese que, após a verificação de
erros de sintaxe, executa o processo de inferência e interligação das estruturas
necessárias para o circuito a ser gerado a partir da descrição. Nesta etapa, é produzido
um circuito RTL (Register Transfer Level)3, empregando primitivas disponíveis na
ferramenta, como comparadores, somadores, registradores e portas lógicas. O circuito
gerado nessa etapa ainda não está associado a nenhuma tecnologia de fabricação e não
está, necessariamente, otimizado. Em seguida é especificada a tecnologia de fabricação
onde são executadas minimizações e otimizações com base nas características da
tecnologia especificada. Como resultado é obtido um arquivo contendo uma rede de
ligações entre os elementos disponíveis na tecnologia empregada; e
• 3º passo: Com base nas interligações geradas pela síntese, a ferramenta realiza o
posicionamento e a interligação dos componentes (placement and routing), assenta cada
primitiva em um local do dispositivo empregado e define o caminho para interligação
com as demais primitivas. No caso dos dispositivos lógicos programáveis, as
ferramentas de posicionamento e interligação são, normalmente, fornecidas pelos
próprios fabricantes devido às particularidades de cada tecnologia.
Conforme D’Amore (2005, p. 6), “As etapas descritas podem variar, ou mesmo ser omitidas,
para diferentes ferramentas de síntese. Fabricantes de dispositivos lógicos programáveis fornecem
ferramentas que integram várias etapas, tornando mais simples o processo de síntese.”
2.3 Sistemas Integrados em um Único Chip
Sistemas integrados são constituídos por um conjunto de núcleos ou cores integrados através
de uma arquitetura de comunicação e um controlador de interface para o mundo externo.
Segundo Zeferino (2003, p.53), um núcleo representa uma propriedade intelectual (IP –
Intelectual Property) que o construtor licencia ao usuário. Por isso, os núcleos são também 3 Se a descrição HDL de entrada já estiver no nível lógico (ex. somador modelado com base em equações lógicas e não em um operador aritmético), a síntese já produzirá uma saída no nível lógico, usando apenas portas lógicas, ao invés do RTL.
18
denominados blocos de propriedade intelectual ou IP blocks. Metodologias de projeto de sistemas
integrados baseiam-se no reuso de blocos previamente projetados e verificados. Podendo ser usados
em pastilhas de material semicondutor (chip) para aplicações maiores ou mais complexas. Os
diferentes tipos de núcleos podem ser classificados de acordo com sua implementação e
disponibilização ao projetista do sistema integrado:
• Soft-core: descrição em linguagem de hardware HDL (Hardware Description Language)
que pode ser mapeada para diferentes processos de fabricação;
• Firm-core: com mais informação que o soft-core, normalmente um netlist ou ainda
informações sobre o posicionamento e o roteamento; e
• Hard-core: composto por layout e informações referentes à temporização do circuito
para uma determinada tecnologia e está pronto para ser utilizado no sistema.
Segundo Zeferino (2003, p. 54), SoCs utilizam núcleos que podem ser novos, herdados de
projetos existentes ou provenientes de uma ou mais bibliotecas. Alguns núcleos necessitam de
reprojeto para adequar-se a um protocolo de interface comum devido a problemas com integração e
teste, principalmente núcleos oriundos de fontes independentes.
PbD (Plataform-based Design – Projeto Baseado em Plataforma) é uma metodologia onde
os fabricantes oferecem ferramentas e bibliotecas completas para os projetos de SoCs que
utilizarem suas plataformas.
De acordo com Zeferino (2003, p. 54), “plataforma é uma arquitetura de hardware e
software para um domínio de aplicação, mas altamente parametrizável. Ela inclui ferramentas de
hardware (eg. Processadores, memórias e dispositivos de E/S) e software (eg. Drivers de
dispositivos, sistemas operacionais de tempo real e códigos de aplicação), os quais podem ser
parametrizados para atender os requisitos do sistema alvo”.
O uso de plataformas tem um custo inicial alto, mas projetos futuros se beneficiarão pela
reutilização de componentes de hardware e software reduzindo tempo e custo de projeto, visto que
componentes de projetos similares não precisam ser reimplementados (KEUTZER et al., 2000).
19
2.3.1 Interfaces padronizadas
Para que o potencial de reuso de software em sistemas integrados seja completamente
explorado, é necessário que núcleos de diferentes fabricantes possuam interfaces compatíveis ou
que o núcleo seja envolvido por uma lógica de adaptação. Caso o núcleo possua interface diferente,
essa lógica é conhecida como wrapper e no contexto de comunicação, ela pode ser entendida como
um adaptador de protocolo de comunicação (ZEFERINO, 2003, p. 55).
Na tentativa de solucionar o problema de interligação de núcleos de diferentes fabricantes
que foram estabelecidos padrões abertos para interfaceamento de núcleos, tornando a comunicação
entre os núcleos independente da arquitetura de comunicação utilizada. Neste contexto podem ser
destacados dois padrões:
• Padrão VCI (Virtual Component Interface): este padrão consiste de uma especificação
de interface para interligação ponto a ponto entre núcleos de um SoC,
independentemente da arquitetura da comunicação utilizada para interconectar esses
núcleos; e
• Padrão OCP (Open Core Protocol): este padrão define uma interface de alto desempenho
entre os núcleos, independente da arquitetura de comunicação utilizada. O diferencial do
OCP em relação ao VCI está na inclusão de sinais de teste e de controle em sua
interface.
O VCI foi proposto antes do OCP, mas, este último vem se tornando o padrão de facto por
ser mais genérico e de uso gratuito (ou ter licença gratuita).
2.4 Arquitetura de comunicação dos SoCs
Segundo Zeferino (2003, p.58),
Nos sistemas integrados atuais, a interconexão entre os núcleos é realizada através de canais ponto-a-ponto ou canais multiponto. Em canais ponto a ponto os núcleos são interligados por canais dedicados enquanto nos canais multiponto a interligação ocorre através de um barramento compartilhado onde os núcleos são conectados.
A Figura 2 ilustra os dois tipos de arquitetura de interconexão: ponto-a-ponto e multiponto.
20
Núcleo 1 Núcleo 2
Núcleo 3 Núcleo 4
Árbitro
(a) (b)
Figura 2. Arquiteturas tradicionais para interconexão em SoCs: (a) ponto-a-ponto e (b) multiponto
Fonte: Adaptado de Zeferino (2003, p. 59).
Essas arquiteturas podem ser comparadas com base nas seguintes características:
• Paralelismo: os canais ponto-a-ponto permitem múltiplas conexões simultâneas,
enquanto canais multipontos concorrem pelo uso do barramento. Esta concorrência é
escalonada por um controlador central;
• Consumo de energia: o consumo de energia é menor em canais ponto-a-ponto, pois eles
têm menor taxa de utilização e menor capacitância por terem canais com fios menores;
• Freqüência de operação: por possuírem menor carga capacitiva os canais ponto-a-ponto
conseguem trabalhar em maiores freqüências de operação;
• Escalabilidade: em canais ponto-a-ponto a adição de cada núcleo requer a
implementação de novos canais aumentando com isso a largura de banda do sistema. Em
canais multiponto, novos núcleos são conectados aos canais já compartilhados pelos
demais núcleos. Com isso a largura de banda disponibilizada a cada núcleo diminui;
• Área: o custo em área de silício varia de acordo com a implementação do sistema, sendo
que em uma arquitetura ponto-a-ponto depende do número de núcleos, do número de
portas por núcleo e do tamanho dessas portas. Em uma arquitetura multi-ponto o número
de portas por núcleo e o tamanho delas é fixo. No entanto, o aumento do número de
núcleos resulta no aumento do custo do árbitro e do(s) circuito(s); e
• Reusabilidade: requisito fundamental no mercado de microeletrônica, pois implica
diretamente no time-to-market. Uma arquitetura ponto-a-ponto é fundamentada em uma
abordagem ad-hoc e o seu reuso é bastante restrito.
Mesmo as arquiteturas multiponto possuindo desvantagens em relação a arquiteturas ponto-
a-ponto, a abordagem preferida é a multiponto devido a sua reusabilidade. Em vista disso as
21
limitações do barramento vêm sendo contornadas. Um exemplo é o uso de hierarquias com
múltiplos barramentos (ZEFERINO, 2003, p. 61).
No entanto, na medida em que a demanda de comunicação aumenta, pelo acréscimo de
núcleos de processamento nos novos SoCs, as limitações do barramento tornam-se mais evidentes.
Algumas soluções arquiteturais buscam contornar essas limitações, como, por exemplo, o uso de
hierarquias de barramentos interligados por pontes, as quais isolam diferentes domínios do sistema
(núcleos de alto desempenho dos núcleos de baixo desempenho). Porém, essas soluções também
possuem suas limitações arquiteturais.
Segundo Zeferino (2003), alguns exemplos de limitações do barramento são:
• Consumo de energia: barramentos têm alto consumo de energia por possuírem fios
longos e carregados por todos os núcleos a eles conectados, possuem taxa de
comunicação próxima de 100% e intensa atividade de chaveamento nos seus fios;
• Desempenho: se degrada com a adição de um novo núcleo que irá competir com os
outros núcleos pelo mesmo canal de comunicação;
• Freqüência de operação: devido à alta carga capacitiva dos barramentos eles tendem a
possuir grandes tempos de transição, tornando lenta a freqüência de operação dos canais;
e
• Paralelismo: baixo paralelismo, pois uma transação em um barramento bloqueia outras
comunicações que utilizem o mesmo canal de comunicação chaveado para aquela
comunicação.
Conforme Zeferino (2003, p. 67),
Uma forma de se obter uma arquitetura de comunicação reutilizável e com desempenho escalável consiste no uso de redes de interconexão chaveada, semelhantes àquelas utilizadas em computadores paralelos. Essas redes baseiam-se em ligações ponto-a-ponto, e apresentam boas características quanto ao paralelismo, consumo de energia, freqüência de operação e escalabilidade, atendendo ainda ao requisito de reusabilidade.
2.4.1 Topologia
Uma rede de interconexão caracteriza-se pela estrutura de interligação de seus roteadores,
sendo que sua topologia agrupa-se em duas classes principais: redes diretas e indiretas, ilustradas na
Figura 3 e descritas logo a seguir.
22
(a) (b)
Figura 3. Tipos de topologia: (a) direta; (b) indireta
Fonte: Adaptado de Zeferino (2003, p. 33-34).
Redes Diretas
Redes diretas (Figura 3.a) são compostas por pares de roteador e processador conhecido
como “nodo”. Os nodos são conectados a nodos vizinhos por ligações ponto-a-ponto. A troca de
mensagens entre nodos não vizinhos ocorre através de um ou mais nodos intermediários. Uma
mensagem recebida por um nodo não destino é repassada pelo roteador para algum dos seus nodos
vizinhos para aproximar-se do seu destinatário, sendo que essa aproximação é conduzida por um
algoritmo de roteamento que decidirá a qual nodo vizinho a mensagem será repassada. Toda
comunicação ocorre através dos roteadores, não interferindo nos processadores dos nodos
intermediários (ZEFERINO, 2003, p. 33).
Uma rede completamente conectada seria uma rede direta ideal, não fosse sua restrição a
escalabilidade e ao alto custo em se implementar um grande número de canais por nodo. Por esse
motivo a maior parte das implementações práticas é restrita a alguns modelos com topologia
ortogonal. Uma topologia de rede ortogonal caracteriza-se por nodos arranjados em um espaço n-
dimensional e cada enlace entre nodos vizinhos produz um deslocamento em uma única dimensão.
As topologias de redes diretas ortogonais mais utilizadas são a grelha (ou malha) n-dimensional, o
toróide (ou k-ary n-cube) e o hipercubo.
Redes indiretas
Os nodos em redes indiretas (Figura 3.b) são processadores, módulos de memória ou
computadores completos que possuem uma interface para uma rede de roteadores. Cada roteador
23
possui um conjunto de portas bidirecionais para ligações com outros roteadores e/ou com os nodos
da máquina. Poucos roteadores fazem conexões com nodos sendo os únicos que podem servir de
fonte ou destinatário de mensagens. A topologia de rede é definida pela estrutura de interconexão
desses roteadores (ZEFERINO, 2003, p. 34).
Existem duas topologias clássicas de destaque para redes indiretas: crossbar e as redes
multiestágio:
• Crossbar: topologia ideal para conexão indireta de N nodos, pois consiste de um único
roteador com uma chave NxN, mais econômico que uma rede direta completamente
conectada, mas sua complexidade torna seu custo inviabilizante; e
• Rede multiestágio: usualmente redes regulares, ou seja, os roteadores são idênticos e são
organizados como um conjunto de estágios. Os estágios de entrada e de saída possuem
ligações para os nodos e para os estágios internos da rede. Esses, por sua vez, são
ligados aos seus estágios vizinhos através de padrões de conexão regulares. Redes
multiestágio também podem ser caracterizadas pelo número de estágios e pela forma
como eles são arranjados.
2.4.2 Controle de fluxo
Controle de fluxo é a política de alocação de canais e buffers para um pacote enquanto ele
trafega em uma rede. Esta política vai definir se um pacote colidiu, ou seja, se não pode prosseguir
na rede em direção a seu destinatário e se deverá ser descartado, bloqueado no lugar onde está, ser
recebido e armazenado temporariamente ou, então, desviado para outro caminho.
Em geral, o controle de fluxo é realizado em nível de enlace. Podem existir buffers para
armazenar dados em transferência em cada terminal de um enlace. Quando o buffer do receptor
estiver cheio, um mecanismo de controle deve ser usado para bloquear a saída de dados do
transmissor. O receptor deve enviar uma informação de controle ao transmissor notificando-lhe
quando estiver pronto para receber novos dados. A seguir são discutidas algumas abordagens de
controle de fluxo em nível de enlace.
Controle de fluxo baseado em créditos
Na abordagem baseada em créditos um pacote é enviado apenas quando há espaço suficiente
no buffer receptor para armazenar o dado a ser transmitido. O receptor envia a informação sobre a
24
quantidade de espaço através de uma linha de retorno ao transmissor. Essa informação é
interpretada pelo transmissor como sendo um crédito e ele só pode enviar um dado se tiver crédito
disponível. O crédito diminui com a transmissão e aumenta com a recepção de mensagens
específicas de controle.
Controle de fluxo handshake
Assim como no controle de fluxo baseado em créditos, um pacote é enviado apenas quando
há espaço suficiente no buffer receptor para armazenar o dado a ser transmitido. Nesta abordagem,
o emissor informa a intenção de enviar um dado ao receptor através de uma linha de validação e o
receptor confirma a disponibilidade de espaço em buffer para receber esse dado através de uma
linha de reconhecimento (acknowledgement).
Controle de fluxo baseado em slack buffers – on/off
O controle de fluxo baseado em slack buffer, também conhecido por on/off, é uma
alternativa para reduzir o envio de caracteres de controle, reduzindo, com isso, a latência associada
à transmissão de pacotes de controle de fluxo e o consumo de banda no canal oposto ao de entrada
de dados, ocasionado por envios excessivos de caracteres de controle.
No controle de fluxo baseado em slack buffer existem marcas que informam se o buffer está
muito ou pouco ocupado (as marcas de off e on respectivamente). Sempre que o buffer atingir essas
marcações, um pacote de controle deve ser enviado pelo receptor ao transmissor de modo a regular
o fluxo de dados, seja pela suspensão ou pelo restabelecimento do envio de dados pelo transmissor.
Esse tipo de controle de fluxo é particularmente adequado para redes que usam chaveamento
wormhole (a ser apresentado).
Controle de fluxo baseado em canais-virtuais
O controle de fluxo baseado em canais virtuais busca reduzir o problema de HOL (Head-of-
Line blocking – bloqueio de Cabeça de Linha), que é causado quando o primeiro pacote de um
buffer for bloqueado por conta de uma colisão e o pacote for maior do que o espaço livre disponível
no buffer, levando ao bloqueio do canal de entrada e nenhum outro pacote poderá utilizar esse
canal.
25
Segundo Zeferino (2003, p. 43)
Se o buffer de entrada for organizado em filas de profundidade menor, denominadas canais-virtuais, obtém-se uma coleção de filas que podem ser alocadas independentemente umas das outras. Com isso, se um canal-virtual estiver bloqueado por algum motivo, o canal físico poderá ainda ser usado por outro canal-virtual, resolvendo o problema do bloqueio HOL e aumentando a utilização do canal físico. Essa organização pode ser chamada de multi-via, pois existem múltiplas vias virtuais em uma mesma via física. Da mesma forma, a organização anterior pode ser chamada de mono-via.
2.4.3 Roteamento
Segundo Zeferino, Bampi e Susin (1999), o roteamento é o método usado para escolher um
caminho na rede para a comunicação entre dois nodos, sendo que o desempenho da rede de
interconexão depende fortemente do algoritmo adotado. Esse algoritmo busca atender objetivos
específicos, influenciando diretamente algumas propriedades da rede, como (DUATO;
YALAMANCHILI; NI, 1997, p. 115):
• Conectividade: capacidade de rotear pacotes de qualquer nodo fonte (ou origem) para
qualquer nodo destinatário (ou destino);
• Liberdade de deadlock e livelock: capacidade de garantir que nenhum pacote ficará
bloqueado (em deadlock) ou circulando pela rede sem atingir o seu destinatário (em
livelock);
• Adaptatividade: capacidade de rotear pacotes através de caminhos alternativos quando
ocorrer congestionamento ou falha em algum componente do caminho em uso; e
• Tolerância a falhas: capacidade de rotear pacotes na presença de falhas em componentes.
Para agrupar o grande número de algoritmos de roteamento de requisitos distintos têm sido
propostas algumas taxonomias permitindo que esses algoritmos sejam classificados segundo alguns
critérios. Duato, Yalamanchili e Ni (1997, p. 116-118) apresentam uma taxonomia baseada nos
seguintes critérios:
• Momento da realização do roteamento: o algoritmo de roteamento é dinâmico, se o
roteamento é determinado em tempo de execução; ou estático, se o algoritmo de
roteamento é determinado em tempo de compilação;
• Número de destinatários de um mesmo pacote: unicast, se cada pacote tiver um único
destinatário; ou multicast, se o pacote puder ter múltiplos destinatários;
26
• Local onde as decisões de roteamento são tomadas: centralizado, se os caminhos forem
estabelecidos por um controlador central na rede; fonte, se o nodo emissor definir o
caminho a ser seguido pelo pacote antes de injetá-lo na rede; ou distribuído, se o
caminho for definido pelos roteadores enquanto o pacote atravessa a rede;
• Implementação: o algoritmo pode ser baseado em tabela, se o roteamento é feito a partir
de uma consulta a uma tabela em memória; ou baseado em máquina de estado, se o
roteamento é realizado a partir da execução de um algoritmo implementado em software
ou em hardware; e
• Adaptatividade: o algoritmo de roteamento pode ser classificado como determinístico,
oblivious ou adaptativo. Em um algoritmo determinístico, o roteamento fornece sempre
o mesmo caminho entre um determinado par fonte-destinatário. No roteamento
oblivious, podem ser utilizadas rotas diferentes, mas nenhuma informação a respeito do
estado da rede é levada em consideração4 (DALLY; TOWLES, 2004). Já em uma
abordagem adaptativa, o roteamento utiliza informações a respeito do tráfego da rede
e/ou do estado dos canais para evitar regiões congestionadas ou com falhas.
Um algoritmo adaptativo ainda pode ser classificado de acordo com os seguintes critérios:
• Progressividade: o roteamento é progressivo quando os cabeçalhos dos pacotes sempre
avançam pela rede, reservando um novo canal a cada passo de roteamento; e regressivo
quando o cabeçalho de um pacote puder retornar pela rede, liberando canais previamente
reservados;
• Minimalidade: o roteamento é mínimo, se o algoritmo puder selecionar apenas canais de
saída que aproximem o pacote do seu destinatário; ou não-mínimo, se ele puder
selecionar canais que levem o pacote a se afastar de seu destinatário; e
• Número de caminhos: o algoritmo de roteamento é completo, se ele puder utilizar todos
os caminhos disponíveis; ou parcial, se apenas um subconjunto desses caminhos puder
ser considerado.
4 A palavra oblivious significa falta de ciência sobre determinado assunto, ou seja, é o antônimo de ciente (aware). Em português, não foi possível identificar um termo adequado e por isso optou-se por usar o original em inglês.
27
2.4.4 Chaveamento
Chaveamento é o mecanismo responsável pela transferência dos dados do canal de entrada
para o canal de saída e exerce forte influência sobre a latência de rede.
As principais técnicas de chaveamento baseiam-se ou no estabelecimento de um circuito,
caminho completo entre a fonte e o destinatário da mensagem, ou na divisão das mensagens em
pacotes que irão reservar 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 com base nas definições
apresentas por Duato, Yalamanchili e Ni (1997), Zeferino, Bampi e Susin (1999) e Zeferino (2003).
2.4.5 Chaveamento por circuito
O chaveamento por circuito baseia-se no estabelecimento de um caminho completo entre
fonte e destinatário, o qual é mantido até o término da comunicação. O circuito é estabelecido em
duas etapas:
• Primeira etapa: o nodo injeta um cabeçalho (uma única palavra) que avança pela rede,
reservando canais físicos. Quando o cabeçalho chega ao nodo destinatário, uma
informação de reconhecimento é enviada ao nodo fonte através do caminho de retorno
do circuito estabelecido; e
• Segunda etapa: quando a informação de reconhecimento é recebida são enviados os
dados da mensagem. Para o cancelamento do circuito, um terminador é enviado ao
destinatário, liberando os recursos previamente alocados na medida em que passa pelos
roteadores.
O chaveamento por circuito se originou das redes telefônicas e se caracteriza por:
• Ausência de contenção no envio da mensagem após o estabelecimento do circuito;
• Necessita de apenas uma posição de buffer para manter o cabeçalho enquanto o próximo
canal desejado encontrar-se indisponível; e
• Os canais já alocados a um cabeçalho permanecem bloqueados e não podem ser
utilizados por outro circuito, o que reduz a utilização da rede e aumenta o tempo para o
estabelecimento dos caminhos, sendo esta a maior desvantagem desta técnica.
28
O uso do chaveamento por circuito se justifica nos casos em que as mensagens são longas e
pouco freqüentes.
2.4.6 Chaveamento por pacote
Chaveamento por pacote armazena e repassa (store-and-forward)
O chaveamento por pacotes é uma alternativa para mensagens curtas e freqüentes onde o
chaveamento por circuito resultaria em um aumento da contenção da rede e no estabelecimento do
circuito.
No chaveamento por pacote armazena e repassa as mensagens são fracionadas em pacotes
com comprimento fixo e cada pacote contém um cabeçalho com as informações necessárias para o
seu roteamento pela rede. Os pacotes são enviados seqüencialmente e cada pacote reserva apenas os
recursos necessários para avançar entre os nodos. Ao receber um pacote o roteador o armazena no
buffer do canal de entrada do pacote. Assim que o destinatário do pacote é identificado, o circuito
de roteamento requisita um canal de saída. Essa requisição é escalonada por um árbitro que
determina quando cada canal de entrada será conectado ao canal de saída requisitado. Realizada a
conexão, os pacotes armazenados nos buffers de entrada são encaminhados ao nodo destino. Por
esse motivo a técnica é conhecida como SAF (Store-And-Foward) ou armazena e repassa
(ZEFERINO, 2003, p. 39-40).
No SAF os pacotes alocam apenas os recursos necessários para avançar de nodo na rede.
Porém, cada pacote possui um cabeçalho, maior tempo para roteamento devido ao aumento de
elementos a serem roteados, a latência de comunicação aumenta conforme aumenta o tamanho do
pacote e deve haver espaço em buffer suficiente em todos os roteadores para manter esses pacotes, o
que aumenta o custo da rede.
Chaveamento por pacote com transpasse virtual (Virtual�Cut-Through)
O chaveamento por transpasse virtual ou VCT (Virtual Cut-Through) é uma alternativa ao
chaveamento SAF. Na técnica de chaveamento SAF, quando um pacote chega ao roteador ele é
obrigatoriamente armazenado. Já no chaveamento VCT, quando o cabeçalho do pacote contendo as
informações de roteamento chega a um roteador e o canal de saída desejado encontra-se disponível,
o restante do pacote (carga útil e terminador) desvia o buffer, reduzindo a latência da comunicação.
Um pacote só é armazenado em buffer se o canal desejado estiver alocado a outro pacote. Desde
29
que o buffer tenha espaço para armazenar o pacote bloqueado. No pior caso, quando a rede está
sobrecarregada, o VCT se comporta como o chaveamento SAF.
Chaveamento por pacote wormhole
O chaveamento wormhole é uma variação do chaveamento VCT e seu principal objetivo é
reduzir a quantidade de buffer necessária para manter pacotes bloqueados na rede.
Segundo Zeferino (2003, p. 40-41)
No chaveamento wormhole um pacote é dividido em flits que avançam pela rede em um modo pipeline. Um flit é a menor unidade de dados sobre a qual é realizado o controle de fluxo e pode ser pequeno e ter tantos bits quanto um phit (largura do canal físico de dados), ou ser tão grande quanto um pacote. Em geral, um flit tem o tamanho de um a quatro phits, para conter, no mínimo, a informação necessária ao roteamento do pacote, ou seja, o cabeçalho.
O chaveamento wormhole é recomendado para redes onde os buffers dos roteadores têm
pouca capacidade de armazenamento. Não é possível realizar a multiplexação de flits de diferentes
pacotes em um mesmo canal lógico, pois a informação de roteamento fica apenas no flit cabeçalho
e os flits de dados apenas seguem o flit cabeçalho através da rede.
A principal desvantagem do chaveamento wormhole está no bloqueio de um canal enquanto
o pacote não for completamente transmitido, aumentando a probabilidade de ocorrer o deadlock.
Mas essa restrição pode ser contornada através do uso de canais virtuais, permitindo que vários
canais lógicos compartilhem um mesmo canal físico.
A vantagem do wormhole está na redução dos requisitos de buffers, se comparados às
abordagens SAF e VCT, sendo assim possível construir roteadores pequenos e rápidos.
De acordo com Zeferino (2003, p.41), o chaveamento wormhole é o mais usado atualmente
por ser mais vantajoso com relação à utilização da rede e ao custo dos roteadores.
2.5 Geração de tráfego
Segundo Tedesco (2005, p. 9), o objetivo da geração de tráfego é definir fontes e destinos,
além de uma estrutura de transmissão de dados originados por eles. A geração de tráfego caracteriza
as aplicações que venham fazer uso de uma determinada rede. Essa avaliação serve de referência
para a avaliação de desempenho, pois, nesta etapa, é verificado se a rede atende aos requisitos das
aplicações que utilizam seus serviços. Esta seção é baseada nos conceitos apresentado por Tedesco
30
(2005) e aborda os padrões utilizados para geração espacial de tráfego e aspectos sobre injeção e
modelagem de tráfego.
2.5.1 Padrões para distribuição espacial de tráfego
Os padrões de tráfego são responsáveis por especificar a relação entre fonte e destino, ou
seja, que ponto da rede se comunica com que outro ponto. As similaridades existentes entre
arquiteturas paralelas e SoCs multiprocessados permitem que padrões normalmente observados em
aplicações paralelas possam ser usados para definir a distribuição espacial de pacotes em NoCs.
Tedesco (2005, p. 9-10), considera os seguintes conceitos como padrões de tráfego:
• Localidade espacial: existe localidade espacial quando a distância média entre nodos é
menor do que a observada em um padrão de tráfego do tipo uniforme em que todos os
nodos têm a mesma probabilidade de ser destino (ou seja, todos os nodos se comunicam
entre si com a mesma probabilidade). Como resultado, um pacote fica menos tempo na
rede reduzindo a contenção de tráfego; e
• Localidade temporal: existe localidade temporal quando a probabilidade de enviar
mensagens para nodos que foram recentemente escolhidos como destinatários para
outras mensagens é maior do que para outros nodos. Esses nodos não precisam estar
próximos na rede, ou seja, não é necessário que uma aplicação possua localidade
espacial para que tenha também localidade temporal.
De acordo com Tedesco (2005, p. 10), a combinação correta de um algoritmo de rotamento
com um dado padrão de tráfego pode levar a um uso mais balanceado da rede, pelo fato de reduzir
a possibilidade de congestionamento em pontos críticos da rede.
Conforme Tedesco (2005, p. 10-13) e Duato, Yalamanchili e Ni (1997, p. 481), os principais
padrões de distribuição de tráfego são:
• Uniforme: todos os nodos têm a mesma probabilidade de ser destino. Esse padrão é o
mais utilizado no estudo de redes de comunicação;
• Não-Uniforme: a probabilidade de um nodo enviar pacotes para um de seus nodos
vizinhos é o dobro em relação ao envio dos pacotes para os nodos restantes;
31
• Bit-reversal: o nodo que possui coordenada no formato binário an-1, an-2,..., a1, a0,
comunica-se com o nodo a0, a1, ..., an-2, an-1.;
• Perfect shuffle: o nodo que possui coordenada no formato binário an-1, an-2,..., a1, a0,
comunica-se com o nodo an-2, an-3, ..., a0, an-1 (rotação de 1 bit para a esquerda);
• Butterfly: o nodo que possui coordenada no formato binário an-1, an-2,..., a1, a0 comunica-
se com o nodo a0, an-2, ..., a1, an-1 (trocar o bit mais significativo com o menos
significativo);
• Matrix transpose: o nodo que possui coordenada no formato binário an-1, an-2,..., a1, a0
comunica-se com o nodo a(n/2)-1, ..., a0, an-1, ..., an/2 (rotação de n/2 bits para a esquerda,
onde n é o número de bits que identificam o nodo); e
• Complemento: o nodo que possui coordenada no formato binário an-1, an-2,..., a1,a0
comunica-se com o nodo an-1’, an-2’,..., a1’, a0’ (inversão de todos os bits).
2.5.2 Carga oferecida
Conforme Tedesco (2005, p. 14), carga oferecida corresponde ao percentual de ocupação do
canal (os canais são ocupados pela comunicação de um ou mais núcleos). Esse parâmetro relaciona
a taxa de injeção de dados de um núcleo com a capacidade total do canal que conecta o núcleo a
rede. O projetista pode escolher uma das seguintes alternativas para estabelecer a carga oferecida:
• Fixar o tamanho para o pacote e variar o intervalo entre os mesmos;
• Variar o tamanho dos pacotes e fixar o intervalo entre o fim de um pacote e o início de
outro; e
• Variar o intervalo decorrido entre o envio do início de um pacote e o envio do início do
próximo pacote (intervalos de saída).
A Figura 4 ilustra como os parâmetros podem ser variados quanto ao dimensionamento da
carga oferecida.
32
Figura 4. Parâmetros para o dimensionamento da carga oferecida
Fonte: Tedesco (2005).
2.5.3 Modelagem de tráfego
De acordo com Tedesco (2005, p. 14-15), o objetivo da modelagem de tráfego é inserir
propriedades probabilísticas de aplicações reais à geração de tráfego. Para isso, podem se alterar os
parâmetros de carga oferecida, permitindo a obtenção de certo grau de realismo às aplicações. A
modelagem de tráfego possui a desvantagem de não oferecer uma caracterização exata do tráfego
real. Entretanto, a simulação pode ser feita com muito menos pacotes do que em uma simulação
baseada em traces (amostras de tráfego real). Em modelagem de tráfego são utilizadas distribuições
de probabilidade, como as distribuições exponencial, normal e pareto ON-OFF. A seguir são
apresentados alguns modelos de tráfego:
• Constante: no modelo constante os pacotes são gerados a uma taxa fixa;
• ON-OFF: o modelo ON-OFF caracteriza-se por possuir períodos de atividade e
inatividade. Nos períodos de atividade são gerados pacotes de tamanho fixo em
intervalos regulares, enquanto no período de inatividade nenhum pacote é gerado; e
• Markov ON-OFF: também conhecido como MMP (Markov Modulated Process –
Processo Modulado de Markov) este processo possui períodos de atividade e inatividade
controlados por uma função de probabilidade de mudança de estado exponencial. Este
modelo é um dos mais populares para caracterização de fontes de voz, stream de vídeo e
internet.
33
2.6 Análise de desempenho
Segundo Dally e Towles (2004, p. 449), o projeto de uma rede de conexão começa com uma
especificação de requisitos de desempenho combinados com restrições a respeito de
encapsulamento e custo. Esses critérios influenciam na escolha da topologia, do roteamento e do
controle de fluxo de uma rede específica. Os aspectos iniciais do projeto da rede são definidos
através de métricas simples e que envolvem algumas suposições a fim de estimar o desempenho.
Essas suposições são suficientes para trabalhar com modelos simples nos estágios iniciais, mas
modelos mais detalhados necessitam caracterizar precisamente o desempenho da rede. Esta seção
aborda aspectos sobre análise de desempenho baseados nos conceitos apresentados por Dally e
Towles (2004).
2.6.1 Estimativas de desempenho de redes de interconexão
De acordo com Dally e Towles (2004, p. 449) existem diferentes maneiras de se estimar o
desempenho de uma rede particular, sendo que uma delas é a técnica denominada open-loop.
Conforme ilustrado na Figura 5, a cada terminal é conectado um terminal de instrumentação
responsável pela geração de tráfego que injeta pacotes na rede de acordo com um determinado
padrão de tráfego. Esse padrão especifica os destinatários dos pacotes, os comprimentos dos pacotes
e o tempo entre chegadas. Como os geradores de tráfego não fazem parte da rede em si, utilizam-se
filas com profundidade muito grande, como se fossem infinitas para isolá-los da rede. Entre cada
gerador de tráfego e sua fila, é colocado um processo medidor que conta o número de pacotes
injetados na rede e registra o momento de injeção de cada pacote. Dessa forma, é possível
determinar o tempo gasto pelo pacote na fila até ser injetado de fato na rede. Outro medidor é
conectado ao terminal de recepção, sendo responsável por registrar o tempo em que cada pacote é
completamente recebido.
34
Red
e de
inte
rcon
exão
...
...
Figura 5. Padrão de configuração para estimativa de uma rede
Fonte: Adaptado de Dally e Towles (2004, p. 450).
Entre as métricas mais utilizadas para expressar o desempenho da rede estão a vazão e a
latência. A vazão (throughput) é determinada contando o número de pacotes (ou palavras) recebidos
na unidade de tempo e a latência é determinada pela diferença entre os tempos de criação e de
chegada de cada pacote. Essas métricas são melhor explicadas a seguir.
Vazão
Dally e Towles (2004, p. 451-453) definem vazão como a taxa de entrega dos pacotes na
rede para uma distribuição particular de tráfego. Ela é medida através da contagem dos pacotes que
chegam ao seu destino em um intervalo de tempo. A vazão é expressa como uma fração da
capacidade da rede, o que permite um entendimento mais intuitivo do desempenho da rede e
permite comparação direta entre redes de diferentes tamanhos e topologias.
De acordo com Dally e Towles (2004, p. 451-452) o ponto mais alto em que a vazão e a
demanda (tráfego oferecido) são iguais é conhecido como ponto de saturação. Uma demanda além
da saturação faz com que a rede não seja capaz de destinar pacotes tão rápido quanto eles são
criados. Além da saturação, uma rede estável continua a fornecer e a destinar pacotes na vazão
máxima para o tráfego oferecido. Todavia, muitas redes são instáveis fazendo a vazão cair abaixo
da saturação o que é geralmente uma indicação de um controle de fluxo injusto.
Dally e Towles (2004, p. 454) citam algumas causas de queda no tráfego aceito quando o
tráfego oferecido aumenta:
35
• Controle de fluxo: quando o controle de fluxo é injusto alguns pacotes ficam aguardando
por muito tempo até conseguirem avançar na rede;
• Roteamento não-mínimo: se feito de forma imprecisa, o pacote pode ficar muito tempo
trafegando na rede até atingir seu destino; e
• Deadlock: algumas implementações livres de deadlock podem causar congestionamento
nos canais a fim de evitar a ocorrência do deadlock.
Latência
Segundo Dally e Towles (2004, p. 455), latência é o tempo que um pacote necessita para
atravessar a rede da origem até seu destino. A latência pode ser avaliada de duas formas:
• Com contenção: latência com contenção considera a contenção causada por outros
pacotes através de recursos compartilhados, uma vez inclusa a latência de contenção, por
modelagem ou simulação, a latência torna-se função do tráfego oferecido; e
• Sem contenção: latência sem contenção, ou zero-load, ignora a latência causada por
outros pacotes, sendo avaliada independente do tráfego, sendo uma técnica de open-
loop.
De acordo com Dally e Towles (2004, p. 455), a latência geral é reportada através da média
das latências de todos os pacotes. Em alguns casos, também é importante reportar histogramas das
latências dos pacotes. No pior caso, são apresentadas as latências de cada pacote e estatísticas de
latência para fluxos individuais. Mesmo a latência geral sendo uma informação útil, a análise de
subconjuntos de pacotes pode ter relevância, principalmente quando se trabalha com canais virtuais
dedicados de diferentes prioridades.
Fases de um experimento de medição de desempenho
Quando os processos subjacentes da rede são estacionários, ou seja, não mudam com o
passar do tempo, a medição do desempenho torna-se simples quando feita em regime permanente
(ou estado de equilíbrio), o que ocorre quando a média dos comprimentos das filas atinge um estado
estacionário. De acordo com Dally e Towles (2004, p. 451), na medição do desempenho em regime
permanente, executa-se um experimento (ou simulação) em três fases:
1. Aquecimento (Warm-up): estado inicial onde a rede ainda não atingiu o regime
permanente. Nenhuma contagem de pacotes é feita neste estado;
36
2. Medição: assim que a rede atinge o estado de equilíbrio, são anotados os tempos de
início de cada pacote que chega na fila fonte; e
3. Drenagem: nesta fase, a rede permanece ativa por tempo suficiente para que cada pacote
chegue ao seu destino onde são anotados seus tempos de chegada.
Para análise da vazão, são utilizados apenas os pacotes que chegaram ao seu destino durante
a fase de medição e a análise da latência é feita usando todos os pacotes contados.
2.7 Geradores de Tráfego para NoCs
Esta seção apresenta uma síntese sobre geradores de tráfego aplicados para NoC descritos na
literatura, visando oferecer uma visão geral sobre possíveis opções a serem consideradas neste
projeto. Primeiramente é apresentado um fluxo de avaliação de desempenho por simulação com
gerador de tráfego descrito em SystemC. Então, é descrita a arquitetura de um gerador de tráfego
sintetizável para validação de um modelo VHDL de NoC. Após, apresenta-se uma plataforma para
avaliação de desempenho de NoC em FPGA que utiliza um gerador de tráfego implementado em
um processador de propósito geral. Por fim, é apresentado um modelo que utiliza instâncias
sintetizáveis de gerador e medidor de tráfego.
2.7.1 Fluxo de avaliação de desempenho em SystemC
Zeferino et al. (2007) apresentam um fluxo de desempenho da rede SoCIN (ZEFERINO;
SUSIN, 2003) baseado no método genérico para injeção de tráfego proposto por Tedesco (2005).
Esse fluxo é baseado na plataforma ilustrada na Figura 6, a qual é formada por modelos SystemC do
roteador ParIS (Parameterizable Intecornnect Switch), de um gerador de tráfego (TG) de um
medidor de tráfego (TM). O roteador ParIS é modelado no nível RT e utiliza apenas construtores
equivalentes ao modelo VHDL sintetizável apresentado em (ZEFERINO; SANTO; SUSIN, 2004) .
Já o TG e o TM são descritos no nível de transação (TL – Transaction Level) e utilizam
construtores mais abstratos da linguagem C e que oferecem mais flexibilidade para a modelagem.
37
TG T M
ParIS
TG T M
ParIS
TG T M
ParIS
TG T M
ParIS
TG T M
ParIS
TG T M
ParIS
TG T M
ParIS
TG T M
ParIS
TG T M
ParIS
TG T M
ParIS
TG T M
ParIS
TG T M
ParIS
TG T M
ParIS
TG T M
ParIS
TG T M
ParIS
TG T M
ParIS
Figura 6. Plataforma de avaliação de desempenho da rede SoCIN em SystemC
Fonte: Zeferino et al. (2007).
Na plataforma, cada TG possui um endereço de rede (baseado em coordenadas XY) e gera
fluxos de comunicação destinados a outros TGs conectados à rede. Cada fluxo é formado por uma
seqüência de pacotes de um mesmo tamanho que devem ser enviados a um mesmo destinatário e
utilizando uma determinada taxa de injeção (percentual da largura de banda disponível). A
configuração do fluxo é determinada por uma ferramenta interativa (denominada gtr) que solicita
alguns parâmetros do fluxo ao projetista (ex. distribuição espacial, taxa de injeção requerida e
comprimento do pacote) e calcula os demais parâmetros necessários à caracterização do fluxo (ex.
intervalo ocioso entre pacotes). A configuração final é armazenada em um arquivo (traffic.cfg) a ser
lido pelo TG no início de um experimento de avaliação de desempenho.
Destaca-se que a taxa de injeção pode ser constante ou variável. No caso de uma taxa
variável, ela pode ser baseada em três distribuições de probabilidade diferentes: Normal,
Exponencial ou Pareto. Nas duas primeiras, a ferramenta gtr desdobra o fluxo de comunicação em
vários subfluxos. Por exemplo, para a distribuição Normal, o número de pacotes a ser enviado é
distribuído entre o subfluxo principal (média) e os demais subfluxos da curva Normal (estes com
um menor número pacotes a ser enviado e com uma taxa de injeção requerida em torno da taxa de
injeção média). No caso do uso da distribuição Pareto, os atributos do fluxo são calculados em
tempo de execução.
38
Com relação ao bloco TM, ele monitora a chegada de pacotes no enlace entre o roteador e o
TG, extrai informações desses pacotes e as registra em arquivo de saída. Ao término da simulação,
os arquivos criados pelos TMs são lidos por uma ferramenta de análise de tráfego, denominada atr,
que calcula métricas de desempenho, como a latência média dos pacotes (em ciclos) e o tráfego
aceito pela rede (em flits/nodo/ciclo).
O fluxo completo de avaliação de desempenho é ilustrado na Figura 7. Conforme Zeferino et
al. (2007), ele opera da seguinte maneira:
A ferramenta gnoc gera redes compatíveis com a arquitetura SoCIN (socin.h), enquanto que a ferramenta gsys gera a descrição de um sistema (main.cpp) com arquitetura baseada na plataforma (...). Essa descrição é compilada pelo gcc que gera um simulador do sistema (system.x). Na sua execução, esse simulador lê o arquivo de configuração de tráfego gerado pela ferramenta gtr e produz arquivos de log (ext_x_y.out) gerados pelos medidores de tráfego. Esses arquivos são então analisados pela ferramenta atr que determina os índices de desempenho da rede.
39
ext_x_y.outext_x_y.outext_x_y.out
ext_x_y.out
gnoc gsys
socin.h
Dimensões da Rede
paris tg tm
Parâmetros do tráfego
gtr
traffic.cfgmain.cpp
gcc
system.x
atr
Relatório Final
Figura 7. Fluxo de avaliação de desempenho da rede SoCIN em SystemC
Fonte: Zeferino et al. (2007).
40
2.7.2 Gerador de tráfego baseado em SPP
Zeferino (2003, p. 140-143) apresenta um modelo de gerador de tráfego sintetizável
utilizado na validação da rede SoCIN. Esse gerador de tráfego permite a configuração de múltiplos
fluxos originados de um nodo fonte para diversos nodos destinos, iguais ou diferentes. Ele é
denominado de GT e é constituído por submódulos GTS (GT Simples) responsáveis pela geração de
cada fluxo de comunicação. Conforme descrito por Zeferino (2003, p. 140), cada GTS é
configurado por um conjunto de parâmetros:
• SOURCE_ID: identificador da instância de GT (gerador de tráfego) ao qual o GTS está associado;
• TARGET_ID: identificador da instância de GT em direção à qual serão encaminhados os pacotes gerados pelo GTS;
• ROUTE_WIDTH: largura da informação de roteamento (RIB) a ser incluída no cabeçalho do pacote;
• DATA_WIDTH: largura do canal de dados da rede;
• RIB: informação de roteamento a ser colocada no cabeçalho dos pacotes. Ela define a rota a ser utilizada para o encaminhamento dos pacotes ao nodo destinatário;
• PACKET_LENGTH: número de flits da carga útil dos pacotes a serem gerados pelo GTS;
• GAP: intervalo de geração de pacotes que define o número de ciclos de relógio entre o envio do terminador de um pacote e a geração do pacote seguinte a ser enviado ao destinatário definido pelo parâmetro RIB; e
• NUMB_PACKETS: número de pacotes a serem gerados.
Ainda, segundo Zeferino (2003, 141),
As múltiplas instâncias de GTS de um mesmo GT concorrem pelo uso da porta do roteador à qual o GT está conectado. Essa concorrência é gerenciada por um árbitro que recebe requisições dos GTSs, aplica um critério de arbitragem quando existirem múltiplas requisições simultâneas, seleciona um dos módulos e comanda um multiplexador para conectar o módulo selecionado à porta local do roteador. Para garantir o uso balanceado dessa porta pelos diversos GTSs, o árbitro utiliza uma política de prioridades baseada em uma fila circular (round-robin) que determina que o GTS selecionado em um ciclo de arbitragem receba o menor nível de prioridade no ciclo de arbitragem seguinte.
A Figura 8 apresenta a arquitetura de um GT com dois GTS responsáveis, cada um, pela
geração de um fluxo de comunicação. Na figura, a tabela ao lado descreve a configuração dos
parâmetros dos GTS. Por exemplo, o GTS0 é configurado para gerar um fluxo formado por 100
pacotes com 2 flits na carga útil em intervalos de geração de 10 ciclos. Esses pacotes serão
encaminhados ao GT de identidade 2 por meio da rota descrita pelo RIB de 8 bits igual a 09h
(parâmetros particulares à arquitetura da versão da rede SoCIN para a qual o gerador foi projetado).
41
ÁRBITRO
req0 gnt0 req1 gnt1
sel
GTS1GTS0
0 1
0
2
16
0
1
16
GTS0 GTS1NUMB_TARGETS = 2
8 8
09h
2
100
10h
1
10
10 100
SOURCE_ID
TARGET_ID
DATA_WIDTH
ROUTE_WIDTH
RIB
PACKET_LENGTH
GAP
NUMB_PACKETS
Figura 8. Gerador de tráfego sintetizável para validação da rede SoCIN
Fonte: Zeferino (2003, p. 141).
Destaca-se que esse gerador de tráfego não chegou a ser utilizado para avaliação de
desempenho, sendo aplicado apenas para validação funcional da rede.
2.7.3 Gerador de tráfego baseado em GPP
Outro exemplo de gerador de tráfego é brevemente descrito no artigo apresentado por
Wolkotte, Hölzenspies e Smit (2007). O gerador de tráfego é implementado por software rodando
sobre um processador ARM9 externo ao chip de FPGA no qual a rede é implementada (Figura 9).
Segundo os autores, 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 SystemC rodando em um
computador.
42
Figura 9. Plataforma de avaliação de desempenho em hardware
Fonte: Wolkotte, Hölzenspies e Smit (2007).
Conforme Wolkotte, Hölzenspies e Smit (2007), a Figura 9 mostra o diagrama de blocos
com os componentes mais importantes da plataforma:
• 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 (Static 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-bit. Através dela pode-se controlar a lógica do FPGA e
trocar blocos de dados –ntre a RAM (Random Access Memory - Memória de Acesso
Aleatório) 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.
43
2.7.4 Gerador de tráfego em FPGA
Genko et al. (2005) utiliza uma abordagem baseada em hardware para a avaliação de
desempenho de NoCs em FPGA. São usadas instâncias de um gerador de tráfego sintetizável
(chamado TG) para gerar e injetar fluxos de pacotes na NoC. Também são utilizadas instâncias de
um medidor de tráfego (chamada TR – Traffic Receptor) para ejetar esses fluxos a partir do NoC e
recolher dados para a avaliação de desempenho. TGs podem gerar fluxos baseados em tráfego
estocástico (distribuição uniforme ou em rajada) ou em traces de tráfegos reais. Conforme descrito
pelos autores, utilizando a sua plataforma, a emulação de 1 bilhão de pacotes que gasta 6 dias para
ser executado em uma plataforma SystemC simul’ção de condução, precisa apenas 3 minutos e
20segundos (menos de quatro minutos) para ser executada em chip, uma aceleração de quatro
ordens de grandeza.
2.8 Discussão
Este capítulo apresentou uma revisão de conceitos base para o desenvolvimento deste
trabalho. Foram estudados e discutidos aspectos sobre sistemas embarcados, VHDL, SoCs,
arquiteturas de comunicação para SoCs (com ênfase em conceitos base sobre NoCs), geração de
tráfego e análise de desempenho.
No final do capítulo, foram apresentadas abordagens alternativas para implementação de
gerador de tráfego. A primeira baseou-se na descrição de um modelo de um gerador de tráfego para
avaliação de desempenho por simulação. A segunda foi baseada em uma arquitetura de processador
de propósito único aplicado à validação funcional de uma NoC. A terceira baseou-se em um
processador de propósito geral que executa o software de geração de tráfego para avaliação de
desempenho de uma NoC em FPGA. A quarta baseou-se em um modelo que implementa tanto o
módulo para medição de tráfego quanto o módulo para geração de tráfego em FPGA, solução
similar a proposta neste trabalho.
Este trabalho está inserido no contexto de um projeto maior (Projeto SoCIN) que visa
pesquisar alternativas arquiteturais para NoCs. Um dos temas de pesquisa do Projeto SoCIN é a
avaliação de desempenho de NoCs para a análise de alternativas implementadas na rede SoCIN. No
último ano (2006-2007), foram feitos esforços para desenvolver uma plataforma de avaliação de
desempenho baseada na simulação de modelos SystemC RTL. Os resultados iniciais dessas
pesquisas foram publicados nos anais do Workshop em Desempenho de Sistemas Computacionais e
44
de Comunicação (ZEFERINO et al., 2007), onde foi apresentado o fluxo de avaliação de
desempenho de um modelo da rede SoCIN apresentado previamente. Embora esse fluxo de
avaliação de desempenho seja mais eficiente que uma avaliação baseada em simulação VHDL, pois
permite simular mais ciclos por segundo e com a mesma precisão, a simulação SystemC no RTL é
ainda computacionalmente cara. Por isso, no Projeto SoCIN, começou-se a explorar alternativas que
possibilitem reduzir o tempo de simulação para avaliação de desempenho de NoCs, como
modelagem da rede em níveis mais abstratos e avaliação de desempenho em hardware. A
abordagem proposta é similar àquela utilizada por Genko et al. (2005) e deve reduzir
substancialmente o tempo de avaliação.
3 DESENVOLVIMENTO
O objetivo geral deste trabalho foi o de desenvolver uma arquitetura de gerador de tráfego
sintetizável para validação e avaliação de Redes-em-Chip. Foram desenvolvidos dois modelos
sintetizáveis de componentes: um gerador de tráfego e um medidor de tráfego, ambos
implementados como processadores de propósito único não programáveis. Esses modelos serão
integrados posteriormente a uma plataforma de avaliação de desempenho em hardware que incluirá,
também, um núcleo para comunicação com um programa de configuração de experimentos e de
análise de resultados (aqui chamado de Supervisor). Como o desenvolvimento desse núcleo de
comunicação e do Supervisor estão fora do contexto deste TCC, foi implementado um núcleo com o
objetivo de emular as funções realizadas por esses componentes.
Neste capítulo, são apresentadas uma visão geral da plataforma proposta, o levantamento
dos requisitos e o projeto arquitetural do gerador e do medidor de tráfego, aspectos relativos à sua
implementação em VHDL e a validação por simulação.
3.1 Visão geral da plataforma
A plataforma de avaliação de desempenho em FPGA baseia-se na arquitetura originalmente
utilizada na plataforma baseada em SystemC descrita previamente. Nessa plataforma, em um
FPGA, será sintetizada uma rede SoCIN baseada no núcleo de roteador ParIS e nos módulos
geradores de tráfego (TG) e medidores de tráfego (TM) desenvolvidos neste TCC, conforme
ilustrado na Figura 10. Cada TG deve gerar fluxos de comunicação5 para um ou mais destinatários,
enviando-lhes pacotes com tamanhos e intervalo entre envios configurados com base no método
genérico de injeção de tráfego proposto por Tedesco (2005). Cada TM coleta dados referentes aos
pacotes recebidos pelos TGs, extraindo informações que permitam, posteriormente, calcular
métricas de desempenho como latência média e tráfego aceito pela rede.
5 Um fluxo de comunicação representa uma comunicação realizada entre dois nodos (fonte e destino) e envolve a transferência de vários pacotes. Exemplos incluem fluxos que representem comunicações entre uma interface de E/S e um processador, entre um processador e um co-processador, entre outros.
46
Figura 10. Plataforma de avaliação de desempenho em hardware para a rede SoCIN
Para a execução de um experimento de avaliação de desempenho, o Supervisor deve enviar
bits de configuração dos fluxos de comunicação a serem gerados por cada TG e coletar os dados
extraídos por cada TM. Para este fim, o núcleo de comunicação (não ilustrado na figura) deve ser
capaz receber informações do Supervisor e repassá-las aos TGs, assim como receber informações
dos TMs e repassá-las ao Supervisor. A definição do padrão de interface entre o Supervisor e o
núcleo de comunicação não foi realizada, pois foge do contexto deste trabalho. Porém, a interface
entre ele e os TGs e os TMs é do tipo serial, utilizando-se uma arquitetura baseada em uma cadeia
de registradores de deslocamento para enviar os bits dos dados de configuração e receber os bis dos
dados de medição.
TG T M
ParIS
TG T M
ParIS
TG T M
ParIS
TG T M
ParIS
TG T M
ParIS
TG T M
ParIS
TG T M
ParIS
TG T M
ParIS
TG T M
ParIS
TG T M
ParIS
TG T M
ParIS
TG T M
ParIS
TG T M
ParIS
TG T M
ParIS
TG T M
ParIS
TG T M
ParIS
M Ó D U L O
D E
C O M U N I C A Ç Ã O
Supervisor
- Configuração da NoC - Configuração do TGs - Coleta de dados dos TMs - Análise de desempenho
Driver de comunicação
Barramento serial
RS-232 ou USB
47
3.2 Análise de requisitos
Nesta seção são apresentados os Requisitos Funcionais e Não-Funcionais previstos na
primeira etapa do desenvolvimento deste TCC. Esses requisitos serviram de base para o projeto e o
desenvolvimento deste TCC.
3.2.1 Requisitos do TG
Requisitos Funcionais (RF)
• RF01: O TG deverá estar ligado a um contador de ciclos global para obter informação
sobre o número de ciclos decorridos desde o início de um experimento;
• RF02: O TG deverá ser capaz de ser configurado por meio de uma interface serial,
recebendo um stream de bits do núcleo de comunicação;
• RF03: O TG deverá manter uma tabela de configuração para cada fluxo a ser gerado,
incluindo: endereço de rede do destinatário, comprimento da carga útil do pacote
incluindo o seu terminador (até 1Kflits/pacote6), número de pacotes a ser enviado (até 1
Mpacotes/fluxo), taxa de injeção requerida (1 a 100 %), intervalo ocioso entre dois
pacotes sucessivos (até 100 Kciclos7), tamanho de rajada (1 Kpacotes/rajada8), e
comprimento da carga útil do último pacote da rajada9;
• RF04: O TG deverá ser capaz de iniciar a geração de pacotes a partir de um comando
recebido do núcleo de comunicação;
• RF05: O TG deverá manter informações dinâmicas sobre o estado de cada fluxo,
calculando o ciclo mínimo para injeção do próximo pacote10 e o número de pacotes
restantes para serem enviados;
6 Valor máximo aproximado do número de ciclos ociosos para o envio de pacotes com 1 Kflits a uma taxa de injeção de 1% da largura de banda disponível no canal. 7 Valor máximo aproximado do número de ciclos ociosos para o envio de pacotes com 1 Kflits a uma taxa de injeção de 1% da largura de banda disponível no canal. 8 Valor estimado sem um referencial consolidado. Deverá ser confirmado posteriormente se o seu dimensionamento está adequado. 9 Por atender à taxa de injeção requerida, no envio de pacotes em rajada, o comprimento da carga útil do último pacote de uma rajada é tipicamente menor que o dos demais pacotes. 10 O ciclo real de injeção pode ser maior que o previsto quando houver contenção de recursos e o pacote tiver que esperar para ser injetado na rede. Esse tempo de espera é contabilizado no calcula da latência de comunicação.
48
• RF06: O TG deverá ser capaz de gerar fluxos de comunicação baseados no método
genérico para injeção de tráfego proposto por Tedesco (2005), suportando injeção de
pacotes a taxas constantes ou variáveis, estas baseadas nas distribuições normal e
exponencial, assim como o envio de pacotes em rajadas;
• RF07: O TG deverá ser capaz de gerar fluxos de comunicação para diferentes
destinatários na rede;
• RF08: O TG deverá ser capaz de gerar diferentes fluxos de comunicação para um
mesmo destinatário na rede;
• RF09: O TG deverá incluir, em cada pacote enviado, informações para posterior análise
de desempenho, ou seja: taxa de injeção requerida pelo fluxo de comunicação e ciclo
previsto para injeção do pacote;
• RF10: O TG deverá escalonar o envio de pacotes de cada fluxo de forma balanceada,
evitando que um determinado fluxo seja postergado indefinidamente;
• RF11: O TG deverá ativar um bit de sinalização quando todos os seus fluxos de
comunicação tiverem concluído o envio dos seus pacotes;
• RF12: O TG deverá possuir interface de comunicação compatível com o enlace da rede
SoCIN; e
• RF13: O TG deverá ser capaz de receber pacotes a ele destinados, retirando-os da rede.
Requisitos Não-Funcionais (RNF)
• RNF01: O TG deverá ser descrito em VHDL; e
• RNF02: O TG deverá ter um custo em área de silício mínimo, compatível com a
capacidade de configuração de tráfego desejada11.
11 O custo de um dado TG será proporcional ao número de fluxos a serem gerados por ele, pois será necessário armazenar informações de cada fluxo. Além disso, no caso de um fluxo usar taxa de injeção variável (ex. baseada em uma distribuição normal), ele será implementado por múltiplos sub-fluxos, cada um com os mesmos requisitos de recursos de um fluxo.
49
3.2.2 Requisitos do TM
Requisitos Funcionais (RF)
• RF01: O TM deverá estar ligado a um contador de ciclos global para obter informação
sobre o número de ciclos decorridos desde o início de um experimento;
• RF02: O TM deverá ser capaz de monitorar um enlace SoCIN identificando a presença
do cabeçalho e do terminador de um pacote;
• RF03: O TM deverá manter contadores para contabilizar (acumular) o número de
pacotes que passam pelo enlace monitorado, a taxa de injeção requerida e a latência de
comunicação desses pacotes12;
• RF04: O TM não irá manter informações individuais de cada pacote ou fluxo
monitorado13; e
• RF05: O TM deverá ser capaz de enviar as informações contabilizadas ao Supervisor por
meio de uma interface serial, enviando um stream de bits ao núcleo de comunicação
quando solicitado.
Requisitos Não-Funcionais (RNF)
• RNF01: O TM deverá ser descrito em VHDL; e
• RNF02: O TM deverá ter um custo em área de silício mínimo.
12 Essas informações serão utilizadas pelo Supervisor para calcular as medias da taxa de injeção requerida pelos fluxos e da latência de comunicação dos pacotes. 13 Estima-se que a quantidade de memória necessária para manter essas informações esteja acima da capacidade de armazenamento embutida nos FPGAs disponíveis no laboratório ao qual este projeto está associado. Por isso, por simplificação, cada TM irá apenas contabilizar dados que permitam calcular a latência média geral da rede para uma dada taxa de injeção requerida média. Outros parâmetros poderão ser incluídos posteriormente.
50
3.3 Projeto Arquitetural
Nesta seção, é apresentado o projeto dos módulos TG e TM desenvolvidos neste TCC.
Deve-se ressaltar, antecipadamente, que dos requisitos funcionais e não-funcionais previamente
listados, apenas o envio de pacotes em rajada não foi atendido (ver RF03 e RF06 do TG). A não
implementação dessa funcionalidade foi uma decisão baseada na avaliação de que sua
complexidade poderia inviabilizar a execução do projeto em tempo hábil, além de elevar o custo do
TG significativamente. Por isso, o projeto arquitetural foi revisado, refletindo os requisitos
efetivamente atendidos pela implementação.
3.3.1 Organização do TG
Os TGs da plataforma são interligados em cadeia como a exemplificada na Figura 11. Eles
recebem um stream de configuração enviado pelo Supervisor que é deslocado do primeiro ao último
TG da cadeia. Cada TG pode ter múltiplos fluxos configurados pelo Supervisor no início de um
experimento de avaliação de desempenho (a quantidade máxima de fluxos por TG é definida em
função do custo do circuito associado). A latência para configurar todos os geradores depende do
número de TGs, do número de fluxos por TG e dos tamanhos dos campos de descrição desses
fluxos.
TG
ParIS
TG
ParIS
TG
ParIS
TG
ParIS
Do núcleo de comunicação com o Supervisor
Figura 11. Cadeia de TGs para uma rede 2x2
51
Cada fluxo a ser gerado por um TG possui uma palavra de descrição do fluxo com as
informações necessárias para o envio dos seus pacotes, os quais estão apresentados na Figura 12 . 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 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 eles. Os outros campos
do descritor de fluxo possuem largura parametrizável. Considerando-se que o canal da rede tenha
largura de 32 bits, que um endereço de rede tenha 8 bits (o que suporta endereçar nodos em uma
rede com até 16x16 roteadores) e os valores máximos especificados no RF03, um descritor de fluxo
possui até 71 bits de largura.
Figura 12. Descritor de fluxo
A Figura 13, a seguir, apresenta uma representação simplificada da organização do TG. Ele
possui uma interface serial de entrada e saída usada para construção da cadeia de TGs, e uma
interface de comunicação conectada a um terminal da rede para inserir e retirar pacotes.
Internamente, o TG é composto por um árbitro, uma cadeia de descritores de fluxo (FD –
Flow Descriptor) e um gerador de fluxo. 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 ciclo de envio do próximo pacote é igual ou maior
que o contador de ciclos global, um pedido é enviado para o árbitro, que escalona todos os pedidos
dos FDs e escolhe um deles para ser ligado ao Gerador de fluxo. O Gerador de fluxo então injeta
um pacote para o FD selecionado na rede contendo uma série de informações: o endereço destino e
origem, a largura de banda necessária, o fluxo e o ciclo em que o pacote foi criado.
52
FDn-2 FD0
Controle
Árbitro
Gerador de fluxo (FG)
...
Caminho de dados
FDn-1
Do terminal da NoC
Descritores de fluxo (FD)
Para o terminal da NoC
Barramento
Figura 13. Organização simplificada do TG
Após o envio do pacote do FD selecionado o gerador de fluxo 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.
O gerador de tráfego pode ser visto como subsistema composto por um conjunto de
periféricos (FDs) ligados a um processador (TG) por meio de um barramento (baseado em
multiplexadores), cujo acesso é escalonado por um árbitro central. Internamente, o gerador de fluxo
tem uma unidade de controle baseada em uma máquina de estados de Moore e caminho de dados
composto por dois somadores, dois subtratores, dois acumuladores e cinco multiplexadores.
Também inclui um FIFO (First-in First-out) e um controlador em nível de link em seu caminho de
dados para conexão com a rede.
Conforme a solução adotada por Tedesco (2005) e Zeferino et al. (2007), no caso de uso de
taxas de injeção variáveis baseadas em distribuições de probabilidade, foram utilizados múltiplos
sub-fluxos para emular o tráfego desejado. Por exemplo, numa distribuição Normal, um sub-fluxo
irá representar a taxa de injeção média e outros representarão as demais taxas de injeção entre a
média e os limites à esquerda (média – desvio padrão) e à direita (média + desvio padrão) da curva
normal.
A seguir são apresentados, de forma mais detalhada, os blocos do gerador de tráfego (TG).
53
Bloco FD (Flow Descriptor)
O bloco FD é responsável por armazenar as informações de um fluxo a ser injetado na rede.
Ele possui uma interface serial de entrada e de saída para a construção de uma cadeia de
configuração dos múltiplos FDs de um fluxo e dos múltiplos TGs da plataforma.
A Figura 14 ilustra a organização interna do bloco FD. Pela cadeia serial são carregados os
registradores: (i) Endereço do destinatário; (ii) HLP(reservado); (iii) Taxa de injeção requerida;
(iv) Número de pacotes; (v) Comprimento dos pacotes; e (vi) Intervalo entre pacotes. O bloco FD
possui ainda um comparador que faz uma requisição ao árbitro quando o número de pacotes for
maior que zero e a emulação estiver habilitada.
Figura 14. Organização simplificada do FD
O barramento representado pelos multiplexadores na Figura 13 é a interface que permite que
múltiplos FDs possam se comunicar a um único FG. Ele é composto por multiplexadores
encadeados que, controlados pelo árbitro, vão conectar o FD selecionado ao bloco gerador de
tráfego.
54
Bloco FG (Flow Generator)
A Figura 15 retrata a organização do FG, mostrando seu caminho de dados. Ele possui
interface com o barramento que o conecta ao FD selecionado pelo árbitro. Esse bloco possui uma
saída que será conectada a um buffer FIFO ligada à rede. Nesta visão, o FG possui dois somadores,
responsáveis por calcular o ciclo do próximo pacote, o qual será armazenado no registrador
correspondente. Possui ainda um subtrator responsável por decrementar o número de ciclos de
espera e o número de flits para enviar. Uma vez que esses registradores tenham sido zerados, outro
subtrator decrementa o número de pacotes pendentes a serem enviado, atualizando-o no registrador
correspondente no FD.
Figura 15. Organização simplificada do FG
Blocos adicionais
O árbitro, o buffer FIFO e módulos de controle de fluxo utilizados na implementação do FG
e na interconexão com a rede foram aproveitados da biblioteca de componentes da rede SoCIN.
3.3.2 Organização do TM
A Figura 16 retrata a organização do TM, mostrando seu caminho de dados. Ele tem uma interface para o Contador de ciclos global,
um canal de entrada para coletar dados a partir da rede terminal, e uma interface serial (uma entrada e uma saída). Esta é usada para a criação
de uma cadeia de TMs visando o envio dos dados coletados na emulação ao Supervisor.
Figura 16. Organização simplificada do TM
Nessa visão, o TM tem seis registradores que partilham três unidades funcionais, a fim de
calcular as seguintes informações:
• Latência máxima: a maior latência entre os pacotes recebidos;
• Latência mínima: a menor latência entre os pacotes recebidos;
• Latência acumulada: soma das latências de todos os pacotes recebidos;
• Flits acumulados: número total de flits recebidos;
• Pacotes acumulados: número total de pacotes recebidos; e
• Largura de banda requerida acumulada: soma dos requisitos de largura de banda de
todos os pacotes recebidos.
A latência de um pacote é determinada subtraindo o valor do Ciclo de envio do próximo
pacote (que é extraído do terminador do pacote) do valor atual do Contador de ciclos global. Essa
latência é acumulada nos respectivo registrador e analisada para determinar se é menor que o valor
mínimo ou maior que o valor máximo corrente,
As informações listadas acima podem ser usadas pelo Supervisor para determinar as
seguintes métricas:
• Latência mínima;
• Latência máxima;
• Latência média (Latência acumulada/Pacotes acumulados);
• Carga oferecida (Largura de banda requerida acumulada/Pacotes acumulados); e
• Tráfego aceito (Flits acumulados/Número de ciclos da emulação/Número de TGs).
O número de ciclos da emulação é obtido por um módulo de controle de emulação,
responsável pelo contador de ciclos global (descrito logo a seguir).
57
3.3.3 Núcleos adicionais
Além do TG e do TM, para fins de controle da execução e emulação da função do
Supervisor, foram desenvolvidos dois blocos descritos a seguir.
ECB (Emulation Control Block)
O ECB é 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. Ele monitora a entrega de cada
pacote através de sinais trailer_present que indicam quando um terminador de pacote é recebido
por um TG. A partir desses sinais, ele acumula 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 ativa um sinal de saída indicando que a emulação foi concluída. O ECB
também é responsável pelo Contador de ciclos global, habilitando o seu incremento no início da
emulação e paralisando-o no final, quando então o seu valor deverá ser disponibilizado ao
Supervisor para o cálculo do tráfego aceito (flits/ciclo/nodo). A Figura 17 ilustra a organização do
caminho de dados do ECB de forma simplificada.
Figura 17. Organização simplificada do ECB
58
Supervisor
Um módulo emulador do Supervisor foi implementado para fins de validação de um sistema
integrado composto pelos módulos desenvolvidos neste TCC. Esse módulo, chamado de
Supervisor, realiza as seguintes funcionalidades:
1. Lê uma memória de configuração de fluxos;
2. Configura os fluxos dos TGs e o ECB;
3. Habilita a execução da emulação;
4. Aguarda o final da emulação; e
5. Coleta dados dos TMs.
Esse módulo foi desenvolvido por outro integrante do grupo de pesquisa ao qual esse projeto
está vinculado (GSED – Grupo de Sistemas Embarcados e Distribuídos).
3.4 Implementação
O desenvolvimento deste trabalho seguiu a metodologia bottom-up, onde os componentes
são construídos e integrados de forma incremental do nível mais baixo ao nível mais alto da
hierarquia do projeto.
Para modelagem de cada componente, foi utilizada a linguagem VHDL e foram feitos testes
unitários baseados em simulação para cada um desses componentes. À medida que esses
componentes ficavam prontos, eles eram integrados e novamente testados. Por fim, obteve-se uma
plataforma genérica e parametrizável para avaliação de desempenho de NoCs.
A Figura 18 ilustra uma versão dessa plataforma para a avaliação de uma rede 2x2,
suficiente para validação da comunicação entre os núcleos. Ela inclui um módulo Supervisor, um
módulo ECB e quatro nodos compostos por um roteador ParIS, um TG e um TM. Na figura, podem
ser observadas as cadeias de configuração dos TGs e do ECB e a cadeia de coleta de dados dos TM,
representadas por linhas tracejadas.
59
TG
ParIS
TG
ParIS
TG
ParIS
TG
ParIS
ECB
TM
TM
TM
TM
Supervisor
Figura 18. Arquitetura da plataforma de validação integrada
Destaca-se que o modelo de topo da plataforma permite a geração automática de um sistema
com qualquer número de roteadores, pois foram definidos parâmetros para as dimensões da rede
(números de linhas e de colunas).
Resultados da síntese
Os modelados VHDL foram desenvolvidos e validados usando ferramentas do ambiente
integrado Altera Quartus II (versão 7.2 Service Pack 3). Cada componente modelado era
devidamente testado e validado por simulação antes e depois de ser integrado a outros
componentes.
Os núcleos são totalmente parametrizáveis, permitindo gerar modelos com diferentes
capacidades. Por exemplo, FDs podem ser personalizados de forma que os seus registradores
tenham apenas o tamanho necessário para os seus fluxos. A Figura 19 lista todos os parâmetros de
configuração da plataforma modelada.
60
-- TG generics XID : NATURAL := 0; YID : NATURAL := 0; DATA_WIDTH : NATURAL := 32 FC_TYPE : STRING := “CREDIT” FIFO_TYPE : STRING := “RING” CREDIT : INTEGER := 4 DEPTH : INTEGER := 4; LOG2_DEPTH : INTEGER := 2; NB_FLOWS : NATURAL := 4; DEST_ADDR_WIDTH : NATURAL := 8; HLP_WIDTH : NATURAL := 9; REQ_BW_WIDTH : NATURAL := 7; NEXT_PCK_CYCLE_WIDTH : NATURAL := 16; PCK_2SEND_WIDTH : NATURAL := 16; PCK_SIZE_WIDTH : NATURAL := 8; WAIT_CYCLES_WIDTH : NATURAL := 16; CYCLES_COUNTER_WIDTH : NATURAL := 32; -- TM generics TM_REQ_BW_ACC_WIDTH : NATURAL := 20; TM_FLITS_ACC_WIDTH : NATURAL := 20; TM_PACKETS_ACC_WIDTH : NATURAL := 20; TM_LATENCY_ACC_WIDTH : NATURAL := 20; TM_MIN_LATENCY_WIDTH : NATURAL := 10; TM_MAX_LATENCY_WIDTH : NATURAL := 20; -- Socinfp generics ROUTER_TYPE : STRING := "PARIS"; NUMB_ROWS : INTEGER := PAR_NUMB_ROWS; NUMB_COLS : INTEGER := PAR_NUMB_COLS; -- ParIS generics PARIS_DATA_WIDTH : INTEGER := PAR_DATA_WIDTH; PARIS_RIB_WIDTH : INTEGER := 8; PARIS_INPUT_FIFO_TYPE : STRING := "RING"; PARIS_INPUT_FIFO_DEPTH : INTEGER := 4; PARIS_INPUT_FIFO_LOG2_DEPTH : INTEGER := 2; PARIS_OUTPUT_FIFO_TYPE : STRING := "NONE"; PARIS_OUTPUT_FIFO_DEPTH : INTEGER := 4; PARIS_OUTPUT_FIFO_LOG2_DEPTH : INTEGER := 2; PARIS_FC_TYPE : STRING := "CREDIT"; PARIS_ROUTING_TYPE : STRING := "XY"; PARIS_WF_TYPE : STRING := "Y_BEFORE_E"; PARIS_ARBITER_TYPE : STRING := "ROUND_ROBIN"; PARIS_SWITCH_TYPE : STRING := "LOGIC"; -- ECB generics ECB_PCK_2SEND_WIDTH : NATURAL := 20; ECB_PCK_RECEIVED_ACC_WIDTH : NATURAL := 20; -- Supervisor generics SUPERVISOR_DATA_REG_WIDTH : NATURAL := 32; SUPERVISOR_MEM_DEVICE_FAMILY : STRING := "Cyclone II"; SUPERVISOR_MEM_INIT_FILE : STRING := "rom_02.mif"; SUPERVISOR_MEM_DATA_WIDTH : NATURAL := 32; SUPERVISOR_MEM_NB_WORDS : NATURAL := 97; SUPERVISOR_MEM_ADDR_WIDTH : NATURAL := 7
Figura 19. Parâmetros de configuração
A Tabela 1 apresenta uma síntese dos custos em flip-flops (FF) e Look-up Tables (LUTs) da
plataforma ilustrada na Figura 18 para os parâmetros listados na Figura 19 para o FPGA Altera
Cyclone II EPC2C35F672C6, escolhido por estar disponível no LSED, laboratório onde este TCC
61
foi desenvolvido. São mostrados os custos de cada um dos módulos ilustrados previamente: tg_core
(TG), tm_core (TM), ecb_core (ECB), socinfp_2x2 (rede com quatro roteadores ParIS) e
supervisor_core (Supervisor). Destaca-se que o tg_core possui custo superior ao dos roteadores
paris implementados. Isto deve-se ao fato dos roteadores paris conterem apenas 3/5 das portas de
comunicação de um roteador completo, cujo custo seria maior (cerca de 770 flip-flops e 890 LUTs,
para a configuração utilizada).
Tabela 1. Visão geral dos gastos em um Cyclone II FPGA (EPC2C35F672C6)
Componente FFs LUTs tg_core 511 593 tm_core 143 307 ecb_core 76 75 paris 461 534 supervisor_core 207 293
A Tabela 2 ilustra os mesmos custos listados na Tabela 1 de forma mais detalhada,
destacando-se os principais componentes dos núcleos do sistema. No final da tabela, é apresentado
o custo total da plataforma para a configuração de parâmetros utilizada.
Tabela 2. Visão detalhada dos gastos em um Cyclone II FPGA (EPC2C35F672C6)
Componente FFs LUTs tg_core 511 593 arb_rr 12 20 fd_array 320 294 fd_bus 0 112 fifo 143 119 fg_core 32 201 ofc 4 16 tm_core 143 307 tm_control 6 9 tm_datapath 137 298 ecb_core 76 75 ecb_fsm 4 6 ecb_datapath 72 70 socinfp_2x2 1850 1889 ParIS 461 534 supervisor_core 207 293 Custo total: 4747 5619
3.5 Validação por simulação
62
A Figura 20 ilustra um diagrama de formas de onda de validação do sistema integrado
apresentado previamente. Nela, considera-se uma rede 2x2 com quatro TGs e quatro TMs, ou seja,
um TG e um TM conectados a cada terminal da rede e cada TG com capacidade de gerar quatro
fluxos (ou seja, com quatro FDs integrados). A simulação ilustrada considera um experimento
configurado para emular o envio de um único pacote com 6 flits pelo TG conectado no roteador de
endereço (0,0) para o TG conectado ao roteador (1,0).
A B C
D
1
3
2
5 6
4
5
Figura 20. Emulação da transferência de um único pacote
Primeiramente, devem ser destacados os intervalos de tempo relevantes do experimento. No
intervalo “A”, para que um único fluxo seja gerado, é feita a configuração de todos dezesseis FDs
do sistema. Para os parâmetros utilizados, isso consome 1230 ciclos, ou seja, 61,5 µs para um
período de relógio de 50 ns. No intervalo “B”, é feita a configuração do ECB para carregar a
quantidade total de pacotes a ser transferida no experimento (ou seja, 1). Essa configuração
consome 20 ciclos (1µs). Logo, independentemente do número de fluxos a serem efetivamente
gerados, a configuração do sistema considerado dura 1250 ciclos (62,5 µs). Após as etapas de
configuração, no intervalo “C” é realizada a experimentação. Nesse experimento, esse intervalo é
bastante curto (apenas 20 ciclos - 1µs) pois um único pacote é transferido. No entanto, numa
63
emulação com fins práticos, milhares de pacotes serão gerados num determinado experimento e
esse intervalo será muito maior, amortizando o custo da configuração. Por fim, em “D”, quando a
emulação é concluída, é feita a coleta dos dados coletados pelos TMs, o que demora 512 ciclos, ou
seja, 25,6 µs, independentemente do número de pacotes transferidos.
Na Figura 20, alguns eventos e intervalos importantes são destacados:
1. Início da configuração dos TGs;
2. Configuração do ECB;
3. Comando de início da emulação;
4. Execução da emulação e transferência do pacote do canal Lin_data[0][0] para o canal
Lout_data[1][0];
5. Início da coleta de dados dos TMs;
6. Início do registro dos dados recebidos dos TMs.
Conforme destacado no evento 6, os dados medidos pelos TMs são lidos e armazenados em
registradores do Supervisor informando:
• Req_bw_acc: somatório das larguras de banda requeridas pelos pacotes,
• Flits_acc: total de flits transferidos na rede;
• Packets_acc: total de pacotes transferidos na rede;
• Latency_acc: somatório das latências de todos os pacotes transferidos;
• Min_latency: menor latência registrada;
• Max_latency: maior latência registrada.
No exemplo, o único pacote transferido, com 5 flits, sofreu uma latência de 16 ciclos, a qual
contabiliza o número de ciclos gastos entre a criação do pacote e o recebimento do terminador pelo
TG destinatário. Desses 16 ciclos, 11 referem-se à transferência do pacote na rede e 4 são devidos a
custos de criação, injeção e ejeção do pacote.
64
A Figura 21, a seguir, ilustra uma segunda simulação em que cada TG gera um fluxo com 10
pacotes de 5 flits sob uma taxa de injeção de 50% para um outro TG usando o padrão de
distribuição espacial complemento (o endereço do destino é o complemento do endereço origem). A
emulação consome 101 ciclos e os resultados obtidos apontam para uma latência média de 18
ciclos.
Figura 21. Emulação da transferência de vários pacotes
Além desses, foram realizados outros experimentos que permitiram confirmar a correção
dos modelos implementados.
3.6 Ganho de desempenho
A Figura 23, a seguir, ilustra uma simulação de uma rede 2x2 com canal de 32 bits, buffers
de 16 flits somente nas entradas, tráfego uniforme, 3 fluxos por TG, sendo 100 pacotes por fluxo e
10 flits por pacote a uma taxa de injeção constante e 50% de largura de banda. O tempo de
execução no FPGA, desconsiderando o tempo de configuração via porta serial ainda não
implementada foi de 1.36ms.
A mesma simulação foi feita em SystemC RTL, desenvolvido por Zeferino et al. (2007) que
também utiliza a rede SoCIN e sua execução ocorreu em 55 segundos em um Computador IBM PC
65
com processador Intel Pentium D de 3 GHz e com 1 GBytes de DRAM e Sistema Operacional
Ubuntu/Linux.
A execução foi 400 vezes mais rápida no FPGA para o exemplo considerado e acredita-se
que esta diferença aumente à medida que o tamanho da rede é aumentado, pois a execução em
FPGA é totalmente paralela.
Figura 22. Simulação do envio de 100 pacotes por fluxo
3.7 Validação física
A Figura 23 ilustra o kit de desenvolvimento DE2 da altera contendo FPGA Altera Cyclone
II EPC2C35F672C6 utilizado na validação física do sistema.
66
Figura 23. Kit de desenvolvimento DE2 da altera
Como a plataforma ainda não possui a uma interface para visualização dos resultados
obtidos, foi desenvolvido um circuito (Figura 24) para visualização dos resultados nos displays de 7
segmentos presentes na placa.
Figura 24. Circuito utilizado na visualização dos resultados em diplay de 7 segmentos
A Figura 25 ilustra que os resultados obtidos nas validações por simulação e física são
iguais, o que confirma o funcionamento correto dos modelos implementados.
DU
AL_B
CD
67
Figura 25. Comparação entre os resultados obtidos na validação por simulação e física
4 CONCLUSÕES
Neste TCC foram estudados e discutidos conceitos relacionados ao projeto de sistemas
computacionais integrados em único chip com foco na geração de tráfego e na avaliação de
desempenho de arquiteturas de comunicação para esses sistemas baseadas em redes chaveadas, as
NoCs. Ainda foram apresentadas alternativas para implementação de geradores de tráfego em
hardware que serviram de base para definição do projeto executado no TCC II.
O projeto consistiu no desenvolvimento de gerador de tráfego e de um medidor de tráfego
sintetizáveis para validação e avaliação de Redes-em-Chip. Esses componentes foram
desenvolvidos em uma abordagem baseada em um processador de propósito único.
68
Com relação à não implementação do envio de pacotes em rajada, prevista originalmente,
mas que não foi realizada devido a dificuldade encontrada e sua implementação consumiria tempo
importante e arriscaria o não cumprimento dos demais objetivos no prazo. Apesar disso, entende-se
que, embora seja um requisito importante, a sua não implementação não comprometeu a qualidade
dos resultados obtidos, podendo ser realizada posteriormente.
Com este TCC, pode-se constatar que apesar da perda de observabilidade que a
implementação em hardware tem em relação a software, a possibilidade de realizar a validação
física e o ganho de desempenho que neste trabalho foi 400 vezes maior que em uma implementação
em software para rede avaliada, justificam o uso desta abordagem.
Como trabalhos futuros, sugerem-se a implementação do núcleo de comunicação e do
software Supervisor para controle dos experimentos e análise dos resultados, com uma interface
web que possibilite que usuários realizem experimentos de avaliação de desempenho usando a
plataforma remotamente.
REFERÊNCIAS BIBLIOGRÁFICAS
ANDRIAHANTENAINA, A. et al. SPIN: a scalable, packet switched on-chip micro-network. In: DATE, 2003, Munich. Proceedings... Los Alamitos: IEEE CS Press, 2003. p. 70 73.
DALLY, William J.; TOWLES, Brian. Principles and practices of interconnection networks. Amsterdan: Morgan Kaufmann. 2004.
D’AMORE, Roberto. VHDL: descrição e síntese de circuitos digitais. Rio de Janeiro: LTC, 2005.
DUATO, J.; YALAMANCHILI, S; NI, L. Interconnection networks: an engineering approach. Los Alamitos: IEEE Computer Society, 1997. 515 p.
GENKO, N.; ATIENZA, D.; DE MICHELI, MENDIAS, G. J. M.; HERMIDA, R.; CATTHOOR, F. A complete Network-on-Chip emulation framework. In: DESIGN AUTOMATION AND TEST ON EUROPE – DATE, 2005, Munich. Proceedings… [S.l.: s.n.], 2005. pp. 246-251.
GUPTA, R. K.; ZORIAN, Y. Introducing core-based system design. IEEE Design & Test of Computers, [S.l.], v. 14, n. 4, p. 15-25, Oct.-Dec. 1997.
JANTSCH, A.; TENHUNEN, H. (Eds.). Networks on Chip. Boston: Kluwer Academic Publishers, 2003. 303p.
KEUTZER, K. et al. System-level design: orthogonalization of concerns and platform-based design. IEEE Transactions on Computer-Aided Design of Integrated Circuits, New York, v. 19, n. 12, p. 1523-1543, Dec. 2000.
MORAES, F. et al. A low area overhead packet-switched Network-on-Chip: architecture and prototyping. In: IFIP WG 10.5 VLSI-SOC, 2003, Darmstadt. Proceedings… Darmstadt: Technische Universität Darmstadt, 2003. p. 318-323.
PEREIRA, T. F.; ZEFERINO, C. A; Soft cores for performance evaluation in FPGA. In: 23th SOUTH SYMPOSIUM ON MICROELETRONICS, 2008. Bento Gonçalvez, RS. Proceedings... Porto Alegre: SBC, 2008. 4p.
TEDESCO, Leonel Pablo. Uma proposta para geração de tráfego e avaliação de desempenho para NoCs. 2005. 126p. Dissertação (Mestrado)– Programa de Pós-Graduação em Ciência da Computação, PUC-RS, Porto Alegre, 2005.
VAHID, F.; GIVARGIS, T. Platform tunning for embedded systems design. IEEE Computer, [S.l.], v. 34, n. 3, p. 112-114, Mar. 2001.
WOLF. Wayne. Embedded Computing - What is embedded computing?. IEEE Computer, [S.l.], v. 35, n. 3, p. 136-137, Jan. 2002.
WOLKOTTE, P. T.; HÖLZENSPIES, K. F.; SMIT, J. M. . Fast, accurate and detailed NoC simulations. In: INTERNATIONAL SYMPOSIUM ON NETWORKS-ON-CHIP (NOCS'07), 1., 2007. Proceedings… [S.l.: s.n.], 2007. p. 323-333.
70
ZEFERINO, C. A.; BAMPI, S.; SUSIN, A. A. A study on interconnection networks for high performance parallel computers. In: MICROELECTRONICS SEMINAR, SIM, 14., 1999, Pelotas. Proceedings... Porto Alegre: Instituto de Informática da UFRGS, 1999. p. 33-40.
ZEFERINO, Cesar Albenes; BRUCH, Jaison Valmor; PEREIRA, Thiago Felski; KREUTZ, M. E.; SUSIN, A. A. . Avaliação de desempenho de Rede-em-Chip modelada em SystemC. In: WORKSHOP EM DESEMPENHO DE SISTEMAS COMPUTACIONAIS E DE COMUNICAÇÃO – WPerformance2007, 2007, Rio de Janeiro. Anais do Congresso da Sociedade Brasileira de Computação. Porto Alegre : Sociedade Brasileira de Computação, 2007. p. 559-578.
ZEFERINO, Cesar Albenes; SANTO, F. G. M. E.; SUSIN, A. A. . ParIS: A Parameterizable Interconnect Switch for Networks-on-Chip. In: 17th (INT.) SYMPOSIUM ON INTEGRATED CIRCUITS AND SYSTEMS, 2004, Porto de Galinhas. Proceedings... New York : ACM Press, 2004. p. 204-209
ZEFERINO, Cesar Albenes; SUSIN, A. A. . SoCIN: A Parametric and Scalable Network-on-Chip. In: 16th (INT.) SYMPOSIUM ON INTEGRATED CIRCUITS AND SYSTEMS, 2003, São Paulo. Proceedings... Los Alamitos : IEEE CS Press, 2003. p. 169-174.
ZEFERINO, C. A. Redes-em-Chip: arquiteturas e modelos para avaliação de área e desempenho. 2003. Tese (Doutorado)–Programa de Pós-Graduação em Computação, Universidade Federal do Rio Grande do Sul, Porto Alegre, 2003.
