UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR CURSO DE ENGENHARIA DE COMPUTAÇÃO

Transcrição

1 UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR CURSO DE ENGENHARIA DE COMPUTAÇÃO DESENVOLVIMENTO DE APLICAÇÃO COM REQUISITOS DE QUALIDADE DE SERVIÇO PARA SISTEMA INTEGRADO BASEADO EM REDE-EM-CHIP Área de Sistemas Embarcados por Douglas Rossi de Melo Cesar Albenes Zeferino, Dr. Orientador Marcelo Daniel Berejuck Co-Orientador São José (SC), novembro de 2008

2 UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR CURSO DE ENGENHARIA DE COMPUTAÇÃO DESENVOLVIMENTO DE APLICAÇÃO COM REQUISITOS DE QUALIDADE DE SERVIÇO PARA SISTEMA INTEGRADO BASEADO EM REDE-EM-CHIP Área de Sistemas Embarcados por Douglas Rossi de Melo Relatório apresentado à Banca Examinadora do Trabalho de Conclusão do Curso de Engenharia de Computação para análise e aprovação. Orientador: Cesar Albenes Zeferino, Dr. Co-Orientador: Marcelo Daniel Berejuck São José (SC), novembro de 2008

3 SUMÁRIO LISTA DE ABREVIATURAS... iii LISTA DE FIGURAS...iv LISTA DE TABELAS... v RESUMO...vi ABSTRACT... vii 1. INTRODUÇÃO PROBLEMATIZAÇÃO Formulação do Problema Solução Proposta OBJETIVOS Objetivo Geral Objetivos Específicos METODOLOGIA ESTRUTURA DO TRABALHO FUNDAMENTAÇÃO TEÓRICA QUALIDADE DE SERVIÇO Requisitos Técnicas para provimento de QoS Serviços integrados Serviços diferenciados Troca de rótulos e MPLS COMUNICAÇÃO EM SISTEMAS INTEGRADOS EM UM ÚNICO CHIP Requisitos de comunicação de SoCs Networks-on-Chip Exemplo de NoC NOCS COM QOS QNoC ÆTHEREAL APLICAÇÕES COM REQUISITOS DE QOS Comunicação de áudio Comunicação de vídeo Discussão DESENVOLVIMENTO VISÃO GERAL ANÁLISE DE REQUISITOS PROJETO ARQUITETURAL Wrapper Gerador de Tráfego Medidor de deadlines perdidos IMPLEMENTAÇÃO VALIDAÇÃO POR SIMULAÇÃO DISCUSSÃO CONCLUSÕES REFERÊNCIAS BIBLIOGRÁFICAS... 57

4 LISTA DE ABREVIATURAS A/D ATM AVC CPU CRT CSIP D/A FDM FLIT I/F IEC IEEE IETF ISO ITU ITU-T JVT MPEG MPLS NBS NoC PAM PCM PHIT QoS RFC RSVP SAF SoC SoCIN TCC TDM UNIVALI VCEG VCT Analógico/Digital Asynchronous Transfer Mode Advanced Video Coding Central Processing Unit Current Routing Table Currently Serviced Input Port Digital/Analógico Frequency Division Modulation Flow Control Unit Interface International Electrotechnical Commission Institute of Electrical and Electronics Engineers Internet Engineering Task Force International Organization for Standardization International Telecommunication Union ITU Telecommunication Standardization Sector Joint Video Team Moving Picture Expert Group MultiProtocol Label Switching Next Buffer State Network-on-Chip Pulse Amplitude Modulation Pulse Code Modulation Physical Unit Quality of Service Qualidade de Serviço Request for Comments Resource reservation Protocol Store-And-Forward System-on-Chip System-on-Chip Interconnection Network Trabalho de Conclusão de Curso Time Division Multiplex Universidade do Vale do Itajaí Video Coding Expert Group Virtual Cut-Through iii

5 LISTA DE FIGURAS Figura 1. Formas de comunicação entre núcleos: (a) ponto a ponto; e (b) multiponto Figura 2. Arquitetura de NoC: (a) formato da mensagem; e (b) interconexão de núcleos Figura 3. Topologias de NoCs: (a) multiestágio; (b) grelha (ou malha); e (c) toróide Figura 4. Formato de pacote da QNoC Figura 5. Fluxo de dados em roteador da QNoC Figura 6. Arquitetura do roteador QNoC Figura 7. Arquitetura do roteador ÆTHEREAL: (a) visão conceitual; e (b) visão de hardware Figura 8. Sistema PCM básico Figura 9. Arquitetura da aplicação disponibilizada Figura 10. Funcionamento da aplicação: (a) fluxos QoS sem concorrência; (b) fluxo de ruído perturbando um dos fluxos QoS Figura 11. Interface de áudio digital (diagrama de blocos) Figura 12. Interface de áudio digital Figura 13. Módulo controlador de CODEC PCM Figura 14. Módulos que constituem o controlador de CODEC PCM Figura 15. Diagrama de seqüencia de comunicação dos CODECS Figura 16. Adaptador de interface de áudio: (a) wrapper_output; e (b) wrapper_input Figura 17. Blocos que constituem a saída do circuito adaptador de interface de áudio Figura 18. Blocos que constituem a entrada do circuito adaptador de interface de áudio Figura 19. Parâmetros do adaptador da interface de áudio Figura 20. Módulo gerador de tráfego Figura 21. Parâmetros do gerador de tráfego Figura 22. Módulo medidor de tráfego Figura 23. Parâmetros do gerador de tráfego Figura 24. Núcleos integrados à rede e seus fluxos de comunicação Figura 25. Medição de deadlines perdidos sem tráfego de ruído Figura 26. Verificação da comunicação entre CODECs sem tráfego de ruído Figura 27. Medição de deadlines perdidos para tráfego de ruído de 33% Figura 28. Verificação da comunicação entre CODECs para tráfego de ruído de 33% Figura 29. Medição de deadlines perdidos para tráfego de ruído de 66% Figura 30. Medição de deadlines perdidos para tráfego de ruído de 100% iv

6 LISTA DE TABELAS Tabela 1. A rigidez dos requisitos de qualidade de serviço Tabela 2. Requisitos de SoCs complexos Tabela 3. Formas comuns de controle de fluxo em NoCs Tabela 4. Mecanismos de roteamento Tabela 5. Mecanismos de arbitragem Tabela 6. Métodos de memorização Tabela 7. Conversão A/D para alguns sinais de áudio e vídeo Tabela 8. Visão geral do custo em FPGA de uma XC5VFX30T-3FF v

7 RESUMO MELO, Douglas R. Desenvolvimento de aplicação com requisitos de qualidade de serviço para sistema integrado baseado em rede-em-chip. São José, 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í, São José, Os avanços tecnológicos têm permitido o desenvolvimento de Sistemas Integrados (SoCs Systems-on-Chip) com nível acentuado de complexidade. Tal progresso aponta a utilização de Redes-em-Chip (NoCs Networks-on-Chip) como alternativa na interligação desses sistemas. Levando em consideração que diversas aplicações de sistemas integrados possuem requisitos de Qualidade de Serviço, é necessário atender esta característica em aplicações que fazem uso de Redes-em-Chip. Neste trabalho é apresentado o desenvolvimento de uma aplicação baseada em NoCs projetada para ser usada como plataforma de avaliação de atendimento a requisitos de QoS por Redes-em-Chip. O documento apresenta estudos realizados sobre Qualidade de Serviço, Sistemas Integrados, comunicação entre SoCs e aplicações com requisitos de QoS. Apresenta-se ainda aspectos relativos ao projeto, implementação e avaliação da aplicação desenvolvida, a qual consiste de um SoC baseado na rede SoCIN (System-on-Chip Interconnection Network) composto de núcleos que emulam tráfegos de telefonia digital e de módulos para medir perdas de prazo na entrega de pacotes (deadlines) em fluxos com requisitos de Qualidade de Serviço. Palavras-chave: Sistemas Integrados. Redes-em-Chip. Qualidade de Serviço. vi

8 ABSTRACT Technological advances have allowed the development of Systems-on-Chip with high level of complexity. This progress indicates the use of Network-on-Chip (NoC) as an alternative for the interconnection of cores in Systems-on-Chip (SoCs). As many applications have Quality of Service requirements, it is necessary to provide this feature in NoC-based applications. In this work, it is presented the development of a NoC-based application with QoS requirements designed to be used as a platform to evaluate the capacity of a NoC in meet QoS requirements. Text presents studies about QoS, Systems-on-Chip, communication in SoCs and applications with QoS requirements. It is also presented issues related to the design, implementation and evaluation of the developed application, which is composed consists of a SoC based on SoCIN network composed by cores which emulate digital telephony traffic and modules used to compute missed deadlines in flows with QoS requirements. Keywords: Systems-on-Chip. Network-on-Chip. Quality of Service. vii

9 1. INTRODUÇÃO Os aprimoramentos da tecnologia têm permitido o aumento do nível de integração de componentes em silício, possibilitando a criação de sistemas complexos em um único chip. Tais sistemas, denominados sistemas integrados ou Systems-on-Chip (SoCs), são compostos de modelos de hardware conhecidos por núcleos ou cores (GUPTA & ZORIAN, 1997). Para efetuar a interconexão dos núcleos de um sistema integrado, geralmente é utilizado um barramento compartilhado ou uma hierarquia de barramentos. Porém, essa metodologia não é adequada para os sistemas integrados previstos para o fim desta década, com de várias dezenas a centenas de núcleos e bilhões de transistores. Para atender às necessidades dos futuros SoCs, foram propostas as Redes-em-Chip ou Networks-on-Chip (NoCs), que oferecem reusabilidade, escalabilidade e paralelismo (JANTSCH & TENHUNEN, 2003, p. 20). Uma NoC é composta por um conjunto de roteadores e canais ponto-a-ponto, interconectando roteadores em um caminho estruturado. Cada roteador possui um conjunto de portas que são utilizados para conectar roteadores a seus vizinhos e ao núcleo de processamento. NoCs são baseadas no modelo de comunicação de troca de mensagens, e podem ser descritas por sua topologia e pelas estratégias utilizadas para roteamento, controle de fluxo, chaveamento, arbitrariedade e memorização (ZEFERINO, 2003, p. 30). Uma seqüência de pacotes desde a origem até o destino é denominada fluxo. As necessidades de cada fluxo podem ser caracterizadas pelos seguintes parâmetros principais: confiabilidade, retardo, flutuação e largura de banda. Esse conjunto de parâmetros define a Qualidade de Serviço ou Quality of Service (QoS) que o fluxo exige. Nenhuma técnica isolada proporciona QoS de forma ótima, sendo necessária a combinação de técnicas para soluções práticas (TANENBAUM, 2003, p. 422). 8

10 1.1 PROBLEMATIZAÇÃO Formulação do Problema Este trabalho está inserido em um projeto sobre Redes-em-Chip denominado SoCIN (System-on-Chip Interconnection Network), e está relacionado a uma dissertação de mestrado cujo objetivo é desenvolver uma versão da rede SoCIN com provimento de QoS (SoCIN-Q). Um problema no contexto desse projeto diz respeito à falta de uma aplicação física para verificação do provimento de QoS pela rede SoCIN-Q. Dessa forma, este TCC se propôs a disponibilizar tal aplicação, na forma de um SoC baseado na SoCIN-Q Solução Proposta A solução proposta consiste numa aplicação com requisitos de QoS de tempo real baseada na rede SoCIN na forma de um sistema integrado. Esse sistema inclui uma rede 3x2, contando com dois núcleos geradores de tráfego e duas interfaces de áudio para terminais de telefonia fixa. A idéia foi avaliar a capacidade da rede em sustentar uma comunicação com requisitos de QoS entre os terminais telefônicos quando sujeita à concorrência com outros pacotes na rede, injetados pelos geradores de tráfego. Em outras palavras, foi construída uma aplicação de testbench que permitiu a injeção de fluxos com requisitos de QoS (áudio telefônico) e sem requisitos de QoS (produzidos pelos geradores de tráfego) e medir a quantidade de deadlines (prazos) perdidos sob diferentes condições de tráfego. Essa avaliação serve de referência para trabalhos posteriores a serem realizados no sentido de disponibilizar uma rede de baixo custos capaz de suportar fluxos com requisitos de QoS. 1.2 OBJETIVOS Objetivo Geral Disponibilizar um modelo sintetizável de sistema integrado com requisitos de qualidade de serviço em comunicação para avaliação de uma NoC Objetivos Específicos Conhecer conceitos de QoS em sistemas de comunicação; Conhecer conceitos de NoCs e o estado da arte de NoCs com QoS; 9

11 Descrever aplicações para sistemas integrados com requisitos de QoS; Desenvolver SoC baseado em NoC para uma aplicação com requisitos de QoS; Validar o sistema; e Divulgar os resultados do trabalho. 1.3 Metodologia Nesta primeira fase, foram feitas pesquisas bibliográficas e estudos sobre os conceitos considerados fundamentais para o desenvolvimento da parte prática do TCC. Foram estudados os seguintes temas: Qualidade de Serviço, Sistemas Integrados, Arquiteturas de Redes-em-Chip com QoS e aplicações com requisitos de QoS (transmissão digital de áudio e vídeo). Após, foi feita a seleção da aplicação alvo e o projeto do sistema a ser desenvolvido. A aplicação escolhida foi a de transmissão digital de áudio, devido à sua maior simplicidade em relação à de transmissão digital de vídeo e pelo interesse particular do projeto ao qual este TCC está vinculado. A aplicação foi desenvolvida através de uma metodologia bottom-up. Todos os seus módulos foram projetados, modelados em VHDL e validados por simulação. Após, os módulos foram integrados e o sistema completo foi validado também por simulação. A validação física pretendida não foi realizada devido a problemas na placa de áudio digital utilizada neste trabalho. 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: Qualidade de Serviço, Sistemas Integrados, Redes-em-Chip e aplicações com requisitos de QoS, assim como uma análise a respeito de transmissão digital de sinais de voz e vídeo. O Capítulo 3 apresenta o projeto detalhado do sistema desenvolvido, incluindo sua especificação e requisitos funcionais e não-funcionais. O capítulo também discute como foi implementado o sistema proposto, apresentando a metodologia utilizada no desenvolvimento. Por fim, no Capítulo 4, apresentam-se as conclusões, onde são abordados os resultados preliminares, mudanças de algumas estratégias de desenvolvimento do projeto, alterações de cronograma, dentre outros. 10

12 2. FUNDAMENTAÇÃO TEÓRICA 2.1 Qualidade de Serviço Quality of Service (QoS) ou qualidade de serviço pode ser definida como o conjunto de características de um sistema necessário para atingir uma determinada funcionalidade (HERMANN; ALMEIDA, 2007). O processamento de QoS num sistema distribuído começa com o estabelecimento dos parâmetros exigidos pelo usuário. Esses parâmetros são mapeados e negociados entre os componentes do sistema, assegurando que todos podem atingir um nível de QoS aceitável. Recursos são então alocados e monitorados, havendo possibilidade de renegociação caso as condições do sistema se alterem. A seguir são descritas alternativas para oferecer uma qualidade de serviço adequada às necessidades das aplicações Requisitos Segundo Tanenbaum (2003, p. 423) uma seqüência de pacotes desde uma origem até um destino é chamada de fluxo, e as necessidades de cada fluxo podem ser caracterizadas por quatro parâmetros principais: Confiabilidade (do inglês, reliability): é a probabilidade de um item desempenhar uma função, sob condições específicas, de forma adequada durante um determinado período de tempo; Retardo (do inglês, delay): corresponde ao tempo de atraso na transmissão de um sinal; Flutuação (do inglês, jitter): é a variação (isto é, o desvio-padrão) dos tempos de chegada das informações (ou seja, dos pacotes) de um fluxo; e Largura de banda (do inglês, bandwidth): corresponde à medida da faixa de freqüência de um sistema ou sinal. A união desses quatro parâmetros define o nível de QoS que o fluxo exige. Algumas aplicações comuns e a severidade de seus requisitos de QoS estão listadas na Tabela 1. 11

13 Tabela 1. A rigidez dos requisitos de qualidade de serviço Aplicação Confiabilidade exigida Sensibilidade ao Retardo Sensibilidade à Flutuação Largura de banda exigida Correio eletrônico Alta Baixa Baixa Baixa Transferência de arquivos Alta Baixa Baixa Média Acesso à Web Alta Média Baixa Média Login Remoto Alta Média Média Baixa Áudio por demanda Baixa Baixa Alta Média Vídeo por demanda Baixa Baixa Alta Alta Telefonia Baixa Alta Alta Baixa Videoconferência Baixa Alta Alta Alta Fonte: Adaptado de Tanenbaum (2003, p. 423). Conforme ilustrado nessa tabela, há aplicações que requerem alta confiabilidade, mas são tolerantes quanto ao retardo e à flutuação, além de requerem pouca largura de banda, como, por exemplo, o correio eletrônico, o qual exige que a rede garanta a integridade da informação transferida. Por outro lado, há aplicações em que os requisitos de QoS são mais exigentes quanto ao retardo, à flutuação e à largura de banda, admitindo uma menor confiabilidade desde que lhe seja garantido um nível de desempenho específico, como na videoconferência. Os fluxos podem ser classificados em diferentes categorias de acordo com as suas demandas de QoS. Nas redes ATM (Asynchronous Transfer Mode), por exemplo, são definidas quatro categorias principais (TANENBAUM, 2003, p. 424): 1. Taxa de bit constante (por exemplo, telefonia); 2. Taxa de bits variável em tempo real (por exemplo, videoconferência compactada); 3. Taxa de bits variável de tempo não-real (por exemplo, assistir a um filme pela Internet); 4. Taxa de bits disponível (por exemplo, transferência de arquivos) Técnicas para provimento de QoS Nenhuma técnica isolada proporciona QoS eficiente e segura de forma ótima. Para alcançar o nível de qualidade desejado foram desenvolvidas diversas técnicas, e as soluções práticas muitas vezes surgem de combinações dessas técnicas. A seguir serão apresentadas algumas técnicas que, segundo Tanenbaum (2003, p ), são utilizadas por projetistas para alcançar QoS. 12

14 Superdimensionamento: consiste em fornecer recursos que suportem tanto quanto o sistema necessita, para que dessa forma exista tanta capacidade disponível que a demanda seja sempre atendida. Sua principal desvantagem é o custo; Armazenamento em buffers: antes de serem entregues, os fluxos podem ser armazenados em buffers no receptor. Esse armazenamento suaviza a flutuação, sem afetar a confiabilidade e a largura de banda. Porém, aumenta o retardo inicial; Moldagem de tráfego: está relacionada à regulagem da taxa média e do volume da transmissão de dados. É normalmente referenciado por acordo de nível de serviço, e sua implementação reduz o congestionamento entre as partes envolvidas; O algoritmo de balde furado: consiste na padronização do fluxo de saída por meio de uma entrada desregulada. É análogo a um balde furado em que a taxa de saída é independente da taxa de entrada. O inconveniente ocorre com a chegada de uma quantidade de informação que extrapola a capacidade do balde, o que acarreta na perda de dados. Trata-se de um sistema de enfileiramento de um único servidor com um tempo de serviço constante; O algoritmo de balde de símbolos: é um aprimoramento do algoritmo de balde furado, mais flexível e que evita a perda de dados. Possibilita uma moldagem de tráfego que ajusta a taxa de saída quando chegam rajadas de dados na entrada; Reserva de recursos: é baseada na capacidade de regular a forma de tráfego oferecido. Tendo uma rota específica para um fluxo, é possível reservar recursos ao longo dessa rota, garantindo que a capacidade necessária estará disponível. É possível reservar largura de banda, espaço de buffer e ciclos de CPU (Central Processing Unit); Controle de admissão: consiste na decisão de aceitar ou rejeitar um fluxo. Para tomar tal decisão, são levados em consideração os recursos disponíveis (largura de banda, buffers, ciclos) aliados a outras especificações, como por exemplo, tolerância à perda de dados; Roteamento proporcional: ocorre na divisão do tráfego correspondente a cada destino entre vários caminhos, evitando a sobrecarga das vias. Como os roteadores não possuem informações referentes a todo o tráfego, uma solução simples e eficiente é utilizar as informações disponíveis no local; e 13

15 Programação de pacotes: ocorre com o processamento de pacotes na ordem de sua chegada, selecionando e encaminhando para os caminhos mais eficazes. Dentre as implementações que utilizam esta técnica, as que se destacam são a de enfileiramento justo e a de enfileiramento justo ponderado, os quais são algoritmos onde os roteadores têm filas separadas para cada linha de saída, uma para cada fluxo Serviços integrados Segundo McCabe (2003, p. 337), durante a década de 90, o IETF (Internet Engineering Task Force) dedicou um grande esforço à criação de uma arquitetura para fluxo multimídia. Esse trabalho resultou em mais de duas dezenas de RFCs (Request for Comments) e ficou conhecido como algoritmos baseados no fluxo ou serviços integrados, tendo como objetivo as aplicações de unidifusão e multidifusão. O principal protocolo da IETF para a arquitetura de serviços integrados é o RSVP (Resource reservation Protocol). Na abordagem de serviços integrados uma aplicação precisa reservar os recursos necessários. Na discussão dos serviços integrados, a reserva de recursos é para estabelecer um fluxo. Isto significa que, ao utilizar serviços integrados, é necessário estabelecer um fluxo, um tipo de circuito virtual o qual foi originalmente desenvolvido para as redes de comutação de pacotes. Um circuito virtual necessita de um sistema de sinalização para configurá-lo antes do início do tráfego de dados. O RSVP é um protocolo de sinalização que auxilia na tarefa de criar e, conseqüentemente, fazer a reserva dos recursos (FOROUZAN, 2006, p. 274) Serviços diferenciados Por conta das configurações antecipadas necessárias na abordagem de serviços, impraticáveis na existência de muitos fluxos, o IETF criou uma abordagem mais simples para oferecer QoS. Essa abordagem é conhecida como QoS baseada em classe (em vez de fluxo). Essa abordagem foi padronizada e denominada arquitetura de serviços diferenciados. Segundo McCabe (2003, p. 338), existem duas alternativas principais de serviços diferenciados: Encaminhamento expedido: Há duas classes de serviços disponíveis: regular e expedido. A grande maioria do tráfego deve ser regular, e uma fração dos pacotes deve ser expedida. Os pacotes expedidos devem transitar pela sub-rede como se nenhum outro 14

16 pacote estivesse presente. Esta técnica visa disponibilizar um caminho não-carregado para o tráfego de pacotes expedidos; e Encaminhamento garantido: Existem quatro classes de prioridade, e cada classe tem seus próprios recursos. São definidas também três probabilidades de descarte de pacotes que estejam sofrendo congestionamento: baixo, médio e alto. A combinação desses fatores resulta em 12 classes de serviço. Esse encaminhamento é composto de três etapas: classificação de pacotes quanto à prioridade, marcação de pacotes de acordo com sua classe e filtragem Troca de rótulos e MPLS Paralelamente ao desenvolvimento dos serviços integrados e serviços diferenciados por parte da IETF, vários fabricantes de roteadores trabalharam na inclusão de um rótulo no início de cada pacote e na execução do roteamento baseado no rótulo, e não no endereço de destino. Utilizando essa técnica, o roteamento pode ser feito com muita rapidez, e quaisquer recursos necessários podem ser reservados ao longo do caminho. Essa abordagem é conhecida por comutação de rótulos ou comutação de tags. A IETF começou a padronizar a idéia sob o nome de MPLS (MultiProtocol Label Switching, ou seja, comutação de rótulos multiprotocolo) (TANENBAUM, 2003, p. 442). 2.2 Comunicação em sistemas integrados em um único chip Com o avanço da tecnologia, o nível de integração de componentes em chip propiciou o desenvolvimento de sistemas complexos em uma única pastilha de silício, incluindo processadores, módulos de memória e controladores de entrada e saída. Tais sistemas são denominados Systemson-Chip (SoCs) e sua metodologia de projeto baseia-se no reuso de blocos previamente projetados e verificados, os quais recebem o nome de núcleos ou, do inglês, cores (ZEFERINO, 2003, p. 26). De acordo com Gupta e Zorian (1997), entende-se por núcleo um bloco de silício préprojetado e pré-verificado, contendo usualmente mais de 5000 portas lógicas, com possibilidade de uso em aplicações maiores ou mais complexas em um chip. Segundo esses autores, existem diferentes tipos de núcleos em função da forma como são implementados: 15

17 Um soft-core consiste de uma descrição em linguagem de descrição de hardware (HDL - Hardware Description Language) que pode ser mapeada para diferentes processos de fabricação; Um firm-core contém mais estrutura, normalmente um netlist pronto para as etapas de posicionamento e roteamento; e Um hard-core inclui o leiaute e informações referentes à temporização do circuito para uma determinada tecnologia e já está pronto para ser utilizado no sistema. Um sistema integrado possui, além de núcleos, uma rede de interconexões, um controlador e uma interface para o mundo externo. Os núcleos podem ser conectados por meio de canais ponto-aponto ou através de canais multiponto compartilhados, conforme ilustra a Figura 1. Núcleo Núcleo Núcleo Núcleo Núcleo Núcleo Núcleo Núcleo Núcleo Núcleo (a) (b) Figura 1. Formas de comunicação entre núcleos: (a) ponto a ponto; e (b) multiponto Fonte: Adaptado de Zeferino (2003). Na abordagem ponto-a-ponto, cada canal conecta um par de núcleos, oferecendo possibilidade de paralelismo na execução de tarefas, porém, apresentas restrições severas quando à reusabilidade. Na abordagem multiponto, os núcleos são conectados por meio de um barramento, permitindo o reuso do sistema em diferentes aplicações. Entretanto, possui desvantagens quando ao desempenho, pois serializa a comunicação (ZEFERINO, 2003) Requisitos de comunicação de SoCs Visando atender os requisitos dos futuros SoCs, que integrarão de várias dezenas a centenas de núcleos, os sistemas de interconexão deverão atender aos seguintes requisitos (SANTO e ZEFERINO, 2004): Paralelismo: suportar comunicações simultâneas; 16

18 Escalabilidade: o desempenho de comunicação deve aumentar com o crescimento do sistema (aumento do número de núcleos); Reusabilidade: poder ser reutilizado em diferentes projetos, o que implica na facilidade de implementação do sistema e na redução do tempo de lançamento do produto no mercado; e Baixo consumo: consumir o mínimo de energia para garantir uma maior autonomia em sistemas embarcados alimentados por bateria. As abordagens anteriormente apresentadas são enquadradas na seguinte disposição, apresentada na Tabela 2. Tabela 2. Requisitos de SoCs complexos Requisitos Canais Ponto-a-Ponto Canais Multiponto Paralelismo Oferece Não oferece Escalabilidade Oferece Não oferece Reusabilidade Não oferece Oferece Baixo consumo Oferece Não oferece Fonte: Baseado em Santo e Zeferino (2004). Mesmo atendendo a maioria dos requisitos, a abordagem ponto-a-ponto carece de reusabilidade, um importante requisito que pode acarretar em perda de oportunidades e atraso no lançamento de produtos. Por isso, a abordagem multiponto, baseada em barramentos tem sido a preferida nos SoCs atuais. No entanto, para os SoCs com maior número de núcleos se faz necessária uma solução alternativa de interconexão intrachip que ofereça paralelismo, escalabilidade, reusabilidade e baixo consumo de energia Networks-on-Chip Visando atender os requisitos de SoCs complexos, diversos grupos de pesquisa desenvolveram soluções baseadas nas redes de interconexão para computadores paralelos. Essas redes, no nível de chip, foram denominadas Redes-em-Chip ou Networks-on-Chip (NoCs). Uma NoC pode ser definida como um conjunto de roteadores e canais ponto-a-ponto que interconectam núcleos, formando uma rede desses elementos. A forma usual de comunicação entre 17

19 os núcleos é a troca de mensagens. Cada mensagem é formada por um cabeçalho (iniciando o pacote), uma carga útil (incluindo o conteúdo da mensagem) e um terminador (sinalizando o fim da mensagem). Núcleo Núcleo Cabeçalho Terminador Carga Útil Núcleo Núcleo (a) (b) Figura 2. Arquitetura de NoC: (a) formato da mensagem; e (b) interconexão de núcleos Fonte: Adaptado de Zeferino (2003). Uma NoC pode ser caracterizada pelo tipo de topologia adotada e pelas técnicas utilizadas pelos mecanismos de controle de fluxo, roteamento, arbitragem, chaveamento e memorização. A seguir, são apresentadas definições relacionadas à caracterização de NoCs, conforme discutido por Zeferino (2003). Topologias de NoC Levando em consideração as tecnologias de fabricação de circuitos integrados, as topologias mais utilizadas em NoCs são as do tipo planar, como as redes multiestágio, grelha (ou malha) e toróide ilustradas na Figura 3. 18

20 (a) (b) (c) Figura 3. Topologias de NoCs: (a) multiestágio; (b) grelha (ou malha); e (c) toróide Fonte: Adaptado de Zeferino (2003). Em uma NoC, os roteadores e os núcleos nela conectados são interligados por meio de canais ponto-a-ponto unidirecionais e assíncronos (as arestas no grafo que representa a sua topologia). Cada canal de fios é responsável pelo transporte de mensagens, enquadramento e regulagem de tráfego. O bloco construtivo de uma NoC é o seu roteador (vértices no grafo que representa a topologia), o qual tem como função encaminhar mensagens transferidas pela rede. Um roteador consiste de um conjunto de filas, multiplexadores e controladores que implementam os mecanismos de comunicação necessários à transferência de mensagens pela rede. Controle de fluxo O mecanismo de controle de fluxo trata da alocação dos recursos necessários para uma mensagem avançar pela rede, realizando a regulação de tráfego nos canais. Essa regulação é feita com o objetivo de evitar a perda indesejada de dados enviados de um emissor a um receptor. A unidade sobre a qual é realizado o controle de fluxo é denominada flit (Flow Control Unit). Tipicamente, um flit corresponde a uma palavra do canal físico (denominada phit Physical Unit), mas pode corresponder a mais de um phit. Existem alguns tipos básicos de técnicas para controle de fluxo, resumidas na Tabela 3. 19

21 Tabela 3. Formas comuns de controle de fluxo em NoCs Tipo Handshake Stop-and-Go Crédito Descrição O receptor retorna um sinal de confirmação quando um flit é consumido. O receptor retorna um sinal solicitando a interrupção ou o estabelecimento do fluxo de flits em função de sua disponibilidade para consumí-los. O receptor possui um contador de créditos (correspondente ao espaço disponível na fila de entrada do receptor) que é decrementado quando um flit é enviado e incrementado quando o receptor consome esse flit. Canais Virtuais Consiste na divisão do canal físico em dois ou mais canais lógicos e permite que, caso o fluxo de um canal lógico seja bloqueado, outro possa utilizar o canal físico. Fonte: Adaptado de Zeferino (2003). Roteamento O mecanismo de roteamento define o caminho a ser utilizado por uma mensagem para atingir o seu destino. Existem muitas estratégias diferentes de roteamento, as quais são tipicamente agrupadas nas classes contidas na Tabela 4. Tabela 4. Mecanismos de roteamento Critério Tipo Descrição Número de Unicast A mensagem tem um único destino destinos Multicast A mensagem tem múltiplos destinos Local de roteamento Centralizado O caminho da mensagem é determinado por um controlador centralizado Fonte O núcleo emissor da mensagem define o caminho a ser utilizado Distribuído O caminho da mensagem é definido pelos roteadores Implementação Tabela O roteamento é feito por uma consulta a uma tabela física Algoritmo O roteamento é feito por um algoritmo de software ou de hardware Adaptatividade Determinístico O roteamento fornece sempre o mesmo caminho entre um determinado par fonte-destino Adaptativo O roteamento utiliza alguma informação a respeito do tráfego da rede e/ou do estado dos canais, evitando regiões congestionadas ou com falha. Oblivious (Inconsciente) O roteamento oferece mais de um caminho alternativo mas não leva em conta o estado da rede, como no roteamento adaptativo. Fonte: Adaptado de Zeferino (2003). 20

22 Arbitragem O mecanismo de arbitragem resolve conflitos internos na rede, quando duas ou mais mensagens competem por um mesmo recurso. Alguns dos esquemas de arbitragem mais utilizados em redes de interconexão e adotados em NoCs são resumidos na Tabela 5. Tabela 5. Mecanismos de arbitragem Tipo Descrição Cada canal de entrada possui uma prioridade fixa ao competir pelo canal Prioridades estáticas de saída Prioridades dinâmicas As prioridades variam a cada arbitragem realizada, tipicamente implementada por uma fila circular Deadline A mensagem aguardando por mais tempo o canal de saída é selecionada LRS O canal de entrada menos recente é selecionado O primeiro canal de entrada a solicitar o canal de saída é selecionado pelo FCFS árbitro Multinível Implementa em mais de um nível diferente esquemas de arbitragem Fonte: Zeferino (2003). Chaveamento O mecanismo de chaveamento determina como uma mensagem é transferida da entrada de um roteador para um de seus canais de saída. Os dois tipos principais de técnicas de chaveamento são baseados ou no estabelecimento de um caminho completo entre a fonte e o destino da mensagem (conhecido por chaveamento por circuito) ou na divisão das mensagens em pacotes, os quais reservam seus caminhos dinamicamente na medida em que avançam em direção ao destino (denominado chaveamento por pacotes). Existem diferentes tipos de chaveamento por pacotes: SAF (Store-And-Forward): quando um roteador recebe um pacote, ele é armazenado em uma fila do canal de entrada do roteador, analisado o destinatário e requisitado 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 solicitado; VCT (Virtual Cut-Through): 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 indisponível, o 21

23 restante do pacote (carga útil e terminador) desvia a fila, reduzindo a latência da comunicação. Um pacote só é armazenado na fila se o canal desejado estiver alocado a outro pacote; e Wormhole: um pacote é dividido em flits que avançam pela rede em um modo pipeline. Nas redes baseadas nesta técnica, as filas dos roteadores têm capacidade para armazenar poucos flits, de modo que os flits de um pacote bloqueado são mantidos em diferentes roteadores na rede, caso o tamanho do pacote for maior que o espaço livre no buffer. Como a informação de roteamento é incluída no flit de cabeçalho, os flits de dado devem seguir o flit do cabeçalho através da rede. Memorização Todo roteador baseado no chaveamento por pacotes deve ser capaz de armazenar pacotes bloqueados temporariamente em seu interior. Ou seja, pacotes destinados a canais de saída que já estejam sendo utilizados por outros pacotes e que devem aguardar pela liberação do canal desejado. Isso exige a implementação de algum esquema de memorização para a manutenção dos pacotes bloqueados em filas dentro do roteador. As principais alternativas de mecanismos de memorização são apresentadas na Tabela 6. Métodos de memorização Tipo Memorização de entrada Memorização de saída Memorização centralizada compartilhada Fonte: Adaptado de Zeferino (2003). Descrição O espaço de memória é distribuído sob a forma de partições implementadas através de filas independentes, as quais são associadas aos canais de entrada O espaço de memória é distribuído sob a forma de partições implementadas através de filas independentes, as quais são associadas aos canais de saída Uma fila central é utilizada para armazenar os pacotes bloqueados de todas as portas de entrada e o espaço de endereçamento é dinamicamente distribuído entre os pacotes bloqueados Exemplo de NoC Visando exemplificar como uma NoC pode ser caracterizada, descreve-se, de forma resumida, a rede proposta por Zeferino (2003), denominada SoCIN (System-on-Chip, Interconnection Network), a qual possui topologia direta podendo ser configurada como uma 22

24 grelha 2D ou um toróide 2D. Ela se baseia em controle de fluxo do tipo handshake, roteamento do tipo fonte e determinístico, chaveamento por pacotes do tipo wormhole, arbitragem dinâmica distribuída e memorização de entrada. 2.3 NoCs com QoS Nesta seção é apresentada uma revisão do estado da arte das NoCs com QoS. São descritas as principais NoCs propostas na literatura que apresentam implementações que visam o provimento de QoS em comunicação QNoC Visando desenvolver uma arquitetura de NoC provendo QoS, um grupo de pesquisadores do Israel Institute of Technology desenvolveu a QNoC (Quality of Service Network-on-Chip), a qual é apresentada por Bolotin et al. (2003). Topologia A QNoC utiliza uma topologia de malha (ou grelha) irregular para atender às estruturas típicas de SoCs heterogêneos. Cada módulo do sistema é conectado a um roteador através de uma interface padrão. A técnica de roteamento é do tipo XY, em que o pacote desloca-se horizontalmente até encontrar a coluna de destino para, em seguida, deslocar-se verticalmente até a coluna do roteador solicitado. Níveis de serviço A QNoC busca não apenas substituir barramentos compartilhados, como também outros tipos de fios e interfaces internos dedicados. Foram identificados quatro diferentes tipos de requisitos de comunicação e definidos níveis de serviços para suportá-los: Sinalização, Tempo- Real, Leitura/Escrita e Transferência de Bloco, descritos a seguir: Sinalização: abrange mensagens urgentes e pacotes muito curtos que recebem a maior prioridade na rede para assegurar baixa latência; Tempo-Real: garante largura de banda e latência para aplicações em tempo-real, como transmissão de áudio e vídeo; 23

25 Leitura/Escrita: provê semânticas de barramento e é projetado para suportar pouca memória e acesso aos registradores; e Transferência de Bloco: usado para transferências de mensagens longas e blocos de dados extensos. Chaveamento A QNoC utiliza chaveamento por pacotes do tipo wormhole. Os pacotes carregam informação de roteamento, comando e dados (carga útil). A Figura 4 mostra o formato básico de um pacote. O campo TRA (Target Routing Address) contém o endereço necessário para o roteamento. O campo CMD (Command) identifica o tipo de operação. O campo PL (Payload) corresponde aos dados. TRA CMD PL Figura 4. Formato de pacote da QNoC Fonte: Adaptado de Bolotin et al. (2003). Controle de fluxo O mecanismo de controle de fluxo baseado em créditos combinado com canais virtuais. O pacote é dividido em múltiplos flits transmitidos através de um canal físico. Quatro canais lógicos compartilham um mesmo canal físico, sendo um canal lógico reservado para cada nível (ou classe) de serviço. Memorização Na QNoC, os roteadores possuem até cinco portas de comunicação, sendo quatro para interconexão com roteadores vizinhos e uma porta local para conexão de um módulo, ou núcleo. Os dados são recebidos em forma de flits, e cada flit é armazenado em um buffer de entrada para em seguida ser encaminhado. O roteador então agenda a transmissão de cada flit para a porta de saída apropriada, conforme ilustra a Figura 5. 24

26 Output Port Input Port Routing Output Port Output Port Input Port Input Port Output Port Input Port Figura 5. Fluxo de dados em roteador da QNoC Fonte: Adaptado de Bolotin et al. (2003). Existem buffers separados para cada canal virtual. A informação de roteamento para cada nível de serviço é armazenada na tabela de roteamento CRT (Current Routing Table) até que o último flit do pacote seja recebido, processado e encaminhado. Quando um flit é encaminhado de uma porta de entrada para uma de saída, uma posição no buffer é liberada e um buffer-credit é enviado de volta ao roteador. Arquitetura do roteador Cada porta de saída de um roteador é conectada a uma porta de entrada de um outro roteador. A porta de saída mantém o número de slots de flits disponíveis para cara nível de serviço em um buffer na próxima porta de entrada. Esses números são armazendos na tabela de estado NBS (Next Buffer State). O roteamento de flits é iniciado com a chegada do primeiro flit de pacote, quando o número da porta de saída é armazenado na CRT para o flit pendente em cada porta de entrada e em cada nível de serviço. O número de slots de flits disponíveis nos buffers dos próximos roteadores é armazenado na tabela NBS para cada nível de serviço em cada porta de saída. As prioridades dos níveis de serviço são, em ordem decrescente: Sinalização, Tempo-Real, Leitura/Escrita e 25

27 Transferência de Bloco. O atual estado do agendamento é armazenado no número Currently Serviced Input Port (CSIP) na tabela NBS. A Figura 6 ilustra a arquitetura do roteador. Input Ports Output Ports Signaling CRT CSIP NBS Signaling Real-Time CRT CSIP NBS Real-Time RD/WR CRT CSIP NBS RD/WR Block Transfer CRT CSIP NBS Block Transfer Buffer Credits Signaling Control, Routing CRT Crossbar CSIP NBS Control Signaling Buffer Credits Real-Time CRT CSIP NBS Real-Time RD/WR CRT CSIP NBS RD/WR Block Transfer CRT CSIP NBS Block Transfer Buffer Credits Control, Routing Control Buffer Credits Figura 6. Arquitetura do roteador QNoC Fonte: Adaptado de Bolotin (2003). Esta disciplina de agendamento implica que um flit seja transmitido em uma porta de saída desde que exista espaço em buffer disponível no próximo roteador e que não haja pacote com prioridade maior pendente para a porta de saída selecionada. Análise sobre o provimento de QoS na QNoC A QNoC provê QoS por meio da análise e distribuição das mensagens em seus níveis de serviço. Os níveis de serviços empregados na QNoC estão implementados nas portas de saída e entrada de seus roteadores, e são capazes de conceder prioridades diferentes para os diferentes tipos de tráfego que a rede está submetida. 26

28 2.3.2 ÆTHEREAL Com o intuito de prover uma arquitetura de NoC com QoS, uma equipe do laboratório de pesquisa da Philips em Eindhoven, Holanda, desenvolveu a ÆTHEREAL, apresentada por Rijpkema et al. (2003). Durante o desenvolvimento da ÆTHEREAL foram identificados três aspectos importantes no projeto de uma arquitetura de roteador. São eles: modo de chaveamento, resolução de conteúdo, e controle de fluxo de rede. Além dos aspectos citados, a ÆTHEREAL também aborda controle de fluxo fim-a-fim e controle de congestionamento. A descrição desses aspectos é detalhada nos tópicos que se seguem. Modo de chaveamento O modo de chaveamento especifica como dados e controle são relacionados. São distinguidos chaveamento de circuito e chaveamento de pacotes. No chaveamento de circuito dados e controles são separados. O controle é fornecido à rede para configurar uma conexão. Isso resulta em um circuito sobre qual todo dado subseqüente da conexão é transportado. No chaveamento de pacotes, dados são divididos em pacote e cada pacote é composto de uma parte de controle, o cabeçalho, e a carga. Os roteadores da rede inspecionam, e possivelmente modificam o cabeçalho dos pacotes recebidos para orientar o pacote para a porta de saída apropriada. Resolução de conteúdo Quando um roteador necessita enviar múltiplos itens de dados através de um mesmo canal são necessárias seleções de prioridade de tráfego, visto que apenas um item de dado pode utilizar o canal em um espaço de tempo. A essa seleção é dado o nome de resolução de conteúdo. No chaveamento por pacotes, a resolução de conteúdo ocorre na granularidade de pacotes individuais. Como a chegada de pacotes não pode ser premeditada, é necessário um agendamento dinâmico por meio de armazenamento de informações em filas ordenadas, para assim garantir a resolução de conteúdo. 27

29 Controle de fluxo de rede O controle do fluxo de rede, também chamado modo de roteamento, endereça a quantidade limitada de enfileiramento nos roteadores e a aceitação de dados entre roteadores. No chaveamento por circuitos, a conexão é configurada e não há necessidade de controle de fluxo. No chaveamento por pacotes, os dados devem ser armazenados em cada roteador antes de serem encaminhados. Para assegurar baixa latência, a ÆTHEREAL utiliza roteamento VCT e Wormhole. Arquitetura do roteador A rede ÆTHEREAL utiliza uma arquitetura de roteador mista, combinando um roteador GT (Guaranteed-Throughput, do inglês, vazão garantida) em um roteador BE (Best-Effort, do inglês, melhor esforço). A arquitetura de roteador GT garante transferência de dados com integridade, sem perdas e de forma ordenada, bem como latência e vazão através de um intervalo de tempo finito. A integridade é assegurada na camada de canal de dados. O roteador não apresenta perdas, pois utiliza uma variante de chaveamento de circuitos. Dados são transportados em blocos de tamanho fixo. A arquitetura de roteador BE oferece um desempenho médio melhor que a oferecida pelo GT, variando com as condições de vizinhança, que não são premeditáveis. O roteador BE é dependente do esquema de resolução de conteúdo do roteador, mais precisamente do enfileiramento e agendamento. Ao combinar os roteadores GT e BE, deve-se assegurar que os serviços que demandam garantias não serão afetados pelos serviços de melhor esforço. Para garantir esta questão, os dados de entrada são classificados na unidade de arbitragem, que deve conceder prioridade maior ao tráfego GT. A Figura 7 ilustra a arquitetura do roteador. 28

30 Best Effort Best Effort Program Preempt Program Guaranteed Throughput Guaranteed Throughput Low-Priority Hi-Priority Control Path Arbitration Buffers Data Path Switch (a) (b) Figura 7. Arquitetura do roteador ÆTHEREAL: (a) visão conceitual; e (b) visão de hardware Fonte: Adaptado de Rijpkema et al. (2003). Análise sobre o provimento de QoS na ÆTHEREAL A ÆTHEREAL disponibiliza QoS por meio da classificação dos dados de entrada de seu roteador. A arquitetura do roteador é mista, combinando arquiteturas GT e BE. O tráfego de dados que necessitam de garantias são processados pela arquitetura GT implementada, que possui maior nível de prioridade. 2.4 Aplicações com requisitos de QoS Nesta seção são apresentadas aplicações que possuem requisitos de QoS. Tais aplicações serão brevemente descritas, a fim de obter a lista de requisitos funcionais indispensáveis ao funcionamento das mesmas Comunicação de áudio Uma aplicação com requisitos de QoS é a comunicação de áudio, presente em operações que englobam telefonia e transmissão de voz. O detalhamento da tecnologia empregada nesse sistema de comunicação, definido por Jeszensky (2004, p ), é apresentado nos tópicos que se seguem. 29

31 Teorema da amostragem O teorema da amostragem relata que, dado um sinal, ao se criar repetições do espectro original em determinados intervalos, é possível reconstruir o sinal original a partir das repetições coletadas, bastando passar por um filtro passa-baixas. A recuperabilidade de um sinal a partir de suas amostras é determinada pela sua freqüência de amostragem. A informação deve ser limitada em freqüência e sua amostragem deve ter pelo menos duas vezes o valor da freqüência máxima. Esta relação é usualmente denominada taxa de Nyquist. Sendo assim, todo sinal limitado numa freqüência e amostrado em uma taxa maior ou igual à de Nyquist pode ser completamente recuperado pelas suas amostras, bastando passar o sinal amostrado em um filtro passa-baixas ideal, com freqüência de corte f corte tal que f máxima f corte f amostragem f máxima. TDM Time Division Multiplex Levando em conta o teorema da amostragem, percebe-se que o intervalo de tempo entre as amostras não é utilizado, podendo servir para envio de outros sinais. Com base nisso, o TDM (Time Division Multiplex) é uma técnica para envio de mais de um sinal utilizando um mesmo meio, compartilhado no tempo. Sistemas TDM possuem várias entradas x(t), todas com freqüência limitada em f máxima, seqüencialmente amostradas por um comutador. O comutador completa o ciclo de revolução no tempo T amostragem, extraindo uma amostra de cada entrada. Na saída do comutador têm-se um sinal x s (t) PAM (Pulse Amplitude Modulation), que consiste em amostras das mensagens individuais periodicamente entrelaçadas no tempo. Sistemas FDM (Frequency Division Modulation) e TDM apresentam técnicas duais. Em sistemas TDM, os sinais são separados no tempo e misturados no domínio de freqüência, enquanto em sistemas FDM, os sinais são separados nos domínios das freqüências e misturados no tempo. 30

32 PCM Pulse Code Modulation Os sinais PAM variam continuamente em função da informação, podendo assumir qualquer valor dentro dos limites desta. Se a amostra sofrer interferência de ruídos, não há meios de obter o valor exato da transmissão no receptor. Considerando que a amostra PAM não possa variar continuamente, assumindo apenas valores pré-fixados. Se a separação entre os valores for grande, em comparação com o ruído, no lado receptor, será fácil identificar o sinal originalmente transmitido. Sendo assim, efeitos de ruídos aleatórios podem ser virtualmente eliminados, não se propagando nas retransmissões seguintes, como em sistemas analógicos. As amostras quantificadas serão codificadas para a transmissão: este é o sistema PCM (Pulse Code Modulation) básico. As amostras quantizadas resultam discretas no tempo (pela amostragem) e na amplitude (pela quantização). x(t) x s (t) x sq (t) PCM Amostrador Quantizador Codificador f amostragem 2f máxima q níveis ʋ pulsos µ amplitudes Figura 8. Sistema PCM básico Fonte: Adaptado de Jeszensky (2004). Se houver amostras em número finito (q), cada nível poderá ser representado por um código digital de extensão finita. O codificador gera um sinal digital x sq (t) que representa a amostra quantizada. Seja ʋ o número de pulsos em certo código e µ o número de valores discretos que cada pulso pode assumir, existirão µ ʋ combinações diferentes de ʋ pulsos com µ amplitudes possíveis. Sistemas PCM podem ser invulneráveis a ruídos causados por regeneração e retransmissão ao longo do caminho físico do sinal. Entretanto, o sinal que chega ao receptor é diferente do original, em virtude da quantização introduzida no transmissor. O ruído de quantização é a principal limitação de sistemas codificados. A relação sinal/ruído de quantização melhora com a amplitude do sinal, em vez de ser constante e aceitável para certa gama de amplitudes de sinal de entrada. Para atingir esse objetivo, 31

33 lança-se mão da quantização não-uniforme. Existem três maneiras práticas diferentes, e equivalentes, a serem adotadas: 1. O codificador é capaz de gerar os passos de quantização de modo não uniforme; 2. O codificador usa quantização uniforme com passo suficientemente pequeno, após o que o código de saída é tratado digitalmente para sua posição de passo não-uniforme; e 3. A informação passa por um circuito não-linear, onde sinais baixos são ampliados e sinais altos são atenuados. Codificação digital na comunicação de voz Segundo Colcher (2005), é possível calcular a taxa gerada pela transmissão de informação analógica através de sinais digitais. Para voz, considerando que a banda passante necessária desses sinais tem largura igual a 3100 Hz, a tava de amostragem de Nyquist é, neste caso, 6200 amostras por segundo. Para facilitar a construção de codecs (codificadores/decodificadores), normalmente amostra-se a uma taxa maior. Se a taxa for de 8000 amostras por segundo e a codificação de cada amostra for 8 bits, a taxa gerada será 8000 x 8 = 64 Kbps, que é a taxa definida pelo padrão ITU-T G711 para telefonia digital. Tabela 7. Conversão A/D para alguns sinais de áudio e vídeo Sinais Voz (ITU-T G711) Qualidade CD (estéreo) Vídeo (NTSC - luminância) Banda Freqüência de Codificação Taxa de bits Passante amostragem bits/amostra (b/a) Hz 8000 Hz Log PCM (8 b/a) 64 Kbps 0 21 KHz 44,1 KHz Log PCM (8 b/a por 1,41 Mbps canal) (2x720,6 Kbps) 0 4,2 MHz 10 MHz 8 b/a 80 Mbps Fonte: Adaptado de Colcher (2005) Comunicação de vídeo Outra aplicação com requisitos de QoS é a comunicação multimídia, presente em fluxos de vídeo, videoconferências, etc. A seguir são detalhadas características desse meio de comunicação, conforme apresentado por Pirsch, Demassieux & Gehrke (1995) e Zeferino (1999). 32

34 Compressão de vídeo Com a evolução da tecnologia, aplicações multimídia com recursos audiovisuais estão cada vez mais inseridas nas tarefas do cotidiano. A transmissão de vídeo pode ser exemplificada como uma dessas aplicações, no entanto, a capacidade física não é capaz de prover essa conectividade. Para contornar esse problema, foram desenvolvidas técnicas de codificação para diminuir a taxa de bits necessária por minuto, também chamada de bit rate. Segundo Zeferino (1999), para se ter uma idéia dos requisitos de uma aplicação de vídeo, pode-se imaginar uma seqüência de vídeo em cores, onde cada um dos três componentes de cor é amostrado com uma resolução de 360x288 pixel e precisão de 8-bit. Cada quadro dessa seqüência ocupa aproximadamente 303 Kbytes (3x360x288/1024). Se o vídeo é transferido a uma taxa de 24 quadros/s, sem nenhuma compressão, a taxa de bits necessária é de aproximadamente 57 Mbit/s (303x24x8/1024). Se essa mesma seqüência tem a duração de um minuto, o espaço requerido para armazená-la é de cerca de 427 Mbytes (57x60/8). MPEG Moving Picture Expert Group Visando o provimento de serviços de transmissão de vídeo utilizando os meios físicos atualmente disponíveis, diversas pesquisas foram realizadas para a elaboração de técnicas que compactassem o sinal mantendo sua qualidade em níveis condizentes com sua aplicação. Buscando atender a esses requisitos e na criação de um padrão internacional de codificação de dados foi criado o MPEG (Moving Picture Expert Group), um comitê técnico instituído pela IEC (International Electrotechnical Commission) e pela ISO (International Organization for Standardization) com o objetivo de desenvolver padrões para a representação codificada de vídeo e áudio com taxas de bits de até 1.5 Mbit/s. Os primeiros trabalhos desse comitê resultaram no padrão IS , largamente conhecido por MPEG-1, lançado em Posteriormente, o escopo do grupo foi estendido a fim de desenvolver algoritmos de compressão de vídeo e áudio associados que operassem a taxas de bits de até 10 Mbit/s visando contemplar aplicações não atendidas pelo MPEG-1. O produto desse novo trabalho foi o padrão MPEG-2 (IS 13818), lançado em Neste mesmo ano, o comitê iniciou uma nova padronização, chamada MPEG-4, a qual visa aplicações com baixas taxas (até 64 Kbit/s). 33

35 Vídeo MPEG As técnicas de codificação de vídeo digital MPEG são estatísticas por natureza e baseiam-se na correlação interpixel. É assumido que o valor de um pixel pode ser previsto a partir de pixels próximos dentro do mesmo quadro (codificação intraquadro) ou a partir dos pixels de quadros adjacentes (codificação interquadros) e pertencentes a uma mesma cena. Para isso, MPEG utiliza técnicas de exploração da correlação espacial e temporal. A transformada do coseno discreto (DCT Discrete Cosine Transform) é eficientemente utilizada para realizar a codificação intraquadro, enquanto que técnicas de modulação de código por diferença de pulso (DPCM Differencial Pulse Code Modulation) são aplicadas na codificação interquadros. MPEG obtém uma alta taxa de compressão de dados por meio do uso combinado dessas técnicas (DPCM/DCT). H.323 Segundo Dhesikan (2001), o H.323 é um padrão de sistemas audiovisuais e multimídia do ITU-T (International Communication Union - Telecommunication Standardization Sector) que visa especificar o uso de áudio, vídeo e dados em comunicação multimídia. A comunicação por meio do H.323 emprega cinco tipos de elementos básicos: Terminais: estações multimídia compatíveis com padrões de vídeo, áudio e controles; Gateways: possibilita a comunicação de terminais H.323 com outros padrões; Gatekeeper: centraliza os pedidos de chamada e gerencia a banda empregada pelos participantes; Elementos de borda: possibilitam a comunicação entre diferentes domínios administrativos; e Multi Control Unit: centraliza os pedidos de chamada, possibilitando conexão simultânea de vários participantes. H.264 É um padrão desenvolvido pelos grupos MPEG e VCEG (Video Coding Expert Group), através de um esforço conjunto denominado JVT (Joint Video Team), um novo padrão de codificação de vídeo denominado AVC (Advanced Video Coding). Este padrão foi lançado como a Parte 10 do MPEG-4 e como Recomendação ITU-T H.264, fornecendo capacidade de compressão 34

36 maior de vídeo se comparado com os padrões anteriores (MPEG-4 e H.263). Sua taxa de transmissão é variável, dependente de aspectos como nível, perfil, resolução, etc. (SHAFER, 2003) Discussão Este trabalho visou, sobretudo, avaliar a capacidade de uma NoCs em prover QoS para uma aplicação com requisitos de tempo real. Como ele foi associado a um projeto relacionado com QoS associado à telefonia digital, a aplicação selecionada foi a de transmissão de áudio digital baseada no padrão ITU-T G711 (Tabela 7), em que a taxa de comunicação é de 64 Kbps. 35

37 3. DESENVOLVIMENTO O objetivo geral deste trabalho foi o de disponibilizar uma aplicação com requisitos de qualidade de serviço para sistema integrado baseado em Rede-em-Chip. Essa aplicação foi implementada como uma plataforma experimental baseadas em roteadores ParIS da rede SoCIN e em modelos sintetizáveis de um controlador de CODEC PCM com uma interface para conexão com a rede (wrapper), um gerador de tráfego e um medidor de deadlines perdidos. Neste capítulo é apresentada uma visão geral do projeto dessa plataforma, o levantamento dos requisitos da aplicação proposta e os aspectos relativos à implementação e à validação da sua arquitetura. 3.1 Visão geral A aplicação consiste de um SoC para avaliar o atendimento de requisitos de QoS por uma NoC SoCIN. O SoC tem uma configuração baseada em uma NoC 3x2 com seis roteadores, conforme ilustrado na Figura 9. I/F Áudio Wrapper TG TM TM Wrapper I/F Áudio Figura 9. Arquitetura da aplicação disponibilizada No SoC ilustrado, dois núcleos são wrappers que implementam interfaces para uma placa de telefonia com CODEC G711 (com taxa de transmissão de 64 Kbps) com dois canais que 36

38 permitem a implementação de dois ramais telefônicos e realizam o empacotamento e o desempacotamento de amostras transferidas pela rede, segundo o protocolo da NoC SoCIN. Um núcleo gerador de tráfego (TG Traffic Generator), capaz de injetar fluxos de pacotes na rede a uma taxa de injeção constante, é usado para injetar tráfico de ruído controlado, e perturbar o tráfego gerado pela comunicação entre os terminais telefônicos. Os fluxos gerados pelo TG são encaminhados a um roteador no qual um circuito simplificado é implementado para emular um núcleo com capacidade de consumir imediatamente cada pacote a ele destinado. Além desses, são incluídos núcleos de medição de tráfego (TM Traffic Meter) que são usados para determinar a perda de prazos (deadlines) na entrega dos pacotes e das amostras. Como pode ser observado na Figura 9, dois roteadores não são interconectados a núcleos, servindo apenas para o encaminhamento de pacotes do fluxo injetado pelo wrapper conectado ao terminal do canto inferior direito da rede em direção ao wrapper conectado ao terminal do canto superior esquerdo da rede. O objetivo dessa arquitetura é oferecer uma plataforma para avaliação da capacidade da rede de garantir QoS a fluxos de comunicação com requisitos de prazo de entrega concorrendo com fluxos sem requisitos de QoS (ruído). As imagens ilustradas na Figura 10, a seguir, permitem um melhor entendimento do experimento possível de ser realizado com a plataforma proposta. I/F Áudio I/F Áudio Wrapper TG Wrapper TG TM TM Wrapper Wrapper I/F Áudio I/F Áudio (a) Figura 10. Funcionamento da aplicação: (a) fluxos QoS sem concorrência; (b) fluxo de ruído perturbando um dos fluxos QoS (b) A Figura 10.a ilustra os fluxos de comunicação trocados entre os terminais telefônicos. Conforme já discutido, o wrapper de cada terminal realiza o controle dos CODECs da interface de áudio e o empacotamento e desempacotamentos das amostras de áudio. Cada CODEC realiza

39 amostragens por segundo, sendo que cada amostra possui 8 bits e o intervalo de amostragem é 125 µs (1/8.000). Logo, a largura de banda do fluxo é de 64 Kbps (8.000 amostras/s 8 bits/amostra). O número de amostras a serem agrupadas em um pacote é um parâmetro configurável do wrapper (ex. 16 ou 64 amostras por pacote) e quanto maior o número de amostras, maior é a profundidade necessária aos buffers de transmissão e de recepção do wrapper. O fluxos gerados pelos wrappers possuem requisitos de QoS quanto ao prazo de entrega dos pacotes, os quais, se forem violados, resultarão em falhas no sinal de áudio recebido. Na Figura 10.b, é ilustrada concorrência pelos canais da rede entre os fluxos de áudio e os fluxos de pacotes gerados pelo TG. Essa concorrência pode ser controlada de modo a perturbar o fluxo de áudio com maior ou menor intensidade e avaliar a capacidade da rede de garantir a qualidade da comunicação entre os terminais. Observa-se que apenas um dos fluxos de QoS estará sujeito à concorrência e, portanto, à perda de prazos. Sabendo-se que a largura de banda requerida pela aplicação (64 kbps) não é significativa, a plataforma foi projetada para que se identifique uma freqüência de operação mínima da rede na qual ela consiga garantir a qualidade da comunicação na ausência de fluxos de perturbação (como ilustrado na Figura 10.a). Após, o gerador de tráfego é configurado de modo a injetar tráfego que possa perturbar a comunicação de áudio. Espera-se que uma rede com suporte a QoS (a ser desenvolvida em um outro projeto) consiga diferenciar as duas classes de tráfego ou reservar a banda necessária aos fluxos de áudio, independentemente da taxa de injeção de pacotes dos TGs. Também se espera que uma rede sem suporte de QoS só consiga suportar a qualidade de comunicação necessária até uma certa taxa de injeção pelos TGs, a partir da qual os prazos de entrega de amostras de áudio PCM sejam violados (o que é expresso pela perda de deadlines). 3.2 Análise de requisitos Na primeira fase deste TCC foi efetuado um levantamento de requisitos para a aplicação (plataforma experimental), reproduzidos a seguir: Requisitos funcionais RF1: A aplicação deve injetar fluxos de comunicação com requisitos de QoS na rede que possuam prazos de entrega (deadlines) definidos; 38

40 RF2: A aplicação deve injetar fluxos de comunicação sem requisitos de QoS com controle de taxa de injeção; RF3: A aplicação deve dispor de mecanismos para medição de perdas de prazo; RF4: Os núcleos da aplicação devem ter interface compatível ou adaptada à rede SoCIN. Requisitos não-funcionais: RNF1: A aplicação deve sem implementada em VHDL; e RNF2: A aplicação deverá ter um custo mínimo em área de silício. 3.3 Projeto Arquitetural Nesta seção, são apresentados os projetos dos módulos desenvolvidos durante o TCC, englobando wrapper (com controlador de CODEC PCM), gerador de tráfego, medidor de deadlines perdidos e adaptadores de interface de áudio. Ressalta-se que todos os requisitos da aplicação foram atendidos Wrapper O wrapper pode ser visto como dois circuitos com funcionalidades diferentes integrados em um mesmo núcleo. A primeira funcionalidade é de controle dos CODECs PCM de uma interface telefônica digital, a segunda de adaptação ao protocolo da rede SoCIN (empacotamento e desempacotamento de amostras PCM). Circuito controlador de CODEC PCM A interface de áudio digital utilizada neste trabalho foi disponibilizada pela empresa Intelbras e necessitou de um circuito de controle dos CODECs de áudio PCM. A Figura 11 ilustra um diagrama de blocos da interface, a qual possui dois CODECs PCM ligados a circuitos de interface telefônica e a uma interface digital para um conector ao FPGA. 39

41 Conector para FPGA Interface Digital Codec Codec I/F Telefônica I/F Telefônica Conector RJ11 Conector RJ11 Figura 11. Interface de áudio digital (diagrama de blocos) Fonte: Intelbras. Os CODECs utilizados na placa são do tipo TP3057, da National Semicondutor. A configuração empregada foi de um quadro de sincronismo curto e de um clock único de operação, no valor de 2,048 MHz. Figura 12. Interface de áudio digital Fonte: Intelbras. 40

42 O módulo responsável pelo controle, sinalização e troca de dados entre os CODECs foi desenvolvido com base na especificação da interface de áudio disponibilizada pela Intelbras. Esse módulo é ilustrado na Figura 13 e possui 12 sinais na sua interface, sendo 5 deles de entrada e 7 de saída. As entradas são representadas à esquerda e as saída à direita do bloco. Figura 13. Módulo controlador de CODEC PCM Neste bloco ocorre a sinalização, o controle e a troca de dados dos CODECs. A sinalização é dada pelos pinos o_c2 e o_f0, responsáveis, respectivamente, pelo clock utilizado nos envios e recepções e pela indicação de novo quadro. O controle é dado pelos sinais o_tsx1 (responsável por ativar o CODEC 1) e o_tsx2 (responsável por ativar o CODEC 2). A comunicação é efetuada de duas maneiras: no domínio do TDM, através dos pinos seriais i_dr (entrada) e o_dx (saída), e intra CODECs, por meio de entradas (i_din1 e i_din2) e saídas paralelas (o_dout1 e o_dout2). Conforme representado na Figura 14, o módulo é constituído de quatro sub-módulos. O módulo (a) é responsável pela geração de estímulos e sincronismo dos CODECs. O módulo (b) efetua as multiplexações no tempo (TDM), convertendo sinais seriais em paralelo e vice-versa. No módulo (c), é efetuada a multiplexação dos sinais paralelos de saída dos CODECs. O módulo de comunicação é indicado pelos blocos (d) e (e) representando, respectivamente, a comunicação no CODEC 1 e CODEC 2. 41

43 Figura 14. Módulos que constituem o controlador de CODEC PCM Para uma melhor compreensão do funcionamento do módulo de controle de CODEC PCM, é apresentado na Figura 15 um diagrama de seqüência que ilustra passo-a-passo a comunicação entre os CODECs. 42

44 Frame Contador de Canal Seletor de Canal Telefone 1 Codec 1 Controlador 1 Controlador 2 Codec 2 Telefone 2 N F0 Slot 0 TSX1 Sinal do canal 0 Amostra N do canal 0 Amostra N-1 do canal 31 Sinal recuperado do canal 31 Amostra N do canal 0 Slot 31 TSX2 Sinal do canal 31 Amostra N do canal 31 Amostra N do canal 0 Sinal recuperado do canal 0 Amostra N do canal 31 N+1 F0 Slot 0 TSX1 Sinal do canal 0 Amostra N+1 do canal 0 Amostra N do canal 31 Sinal recuperado do canal 31 Figura 15. Diagrama de seqüencia de comunicação dos CODECS Cada CODEC é associado a um canal no domínio TDM, efetuando suas recepções e transmissões neste intervalo de tempo. As amostras de recepção são consumidas no início do período do canal, enquanto as amostras de envio são transmitidas no final. Circuito de adaptação de interface para a rede O circuito de adaptação da interface de rede consiste de módulos que realizam a interface entre o circuito de controle dos CODECs e a rede SoCIN. O adaptador é dividido em um módulo de saída (wrapper_output) e um módulo de entrada (wrapper_input), conforme ilustra a Figura 16. O adaptador de saída (wrapper_output) é responsável por coletar os dados amostrados pelo CODEC, empacotar um determinado número de amostras e injetar o pacote na rede. Ele é composto nos blocos ilustrados Figura 17: (a) control; e (b) datapath. O primeiro realiza o controle do segundo, o qual é responsável pelo armazenamento de amostras, empacotamento e injeção do pacote na rede. 43

45 (a) (b) Figura 16. Adaptador de interface de áudio: (a) wrapper_output; e (b) wrapper_input Figura 17. Blocos que constituem a saída do circuito adaptador de interface de áudio O adaptador de entrada (wrapper_input) é responsável por distribuir desempacotar as amostras de um pacote recebido e encaminhá-las ao CODEC na sua freqüência de consumo. Assim como o adaptador de entrada, é composto de dois blocos, ilustrados na Figura 18: (a) control ; e (b) datapath. O primeiro realiza o controle do segundo, o qual recebe um pacote, retira as amostras do pacote e as encaminha ao CODEC. 44

46 Figura 18. Blocos que constituem a entrada do circuito adaptador de interface de áudio Ambos os módulos são instanciados duas vezes, uma vez para cada CODEC. O conjunto de parâmetros ajustáveis, idêntico nos dois blocos, é representado na Figura Wrapper Parameters p_n : integer:= 4; -- number of 4-tuple samples -- FIFO Parameters p_fc_type : string := "CB"; -- options: CB or HS p_credit : integer:= 4; -- maximum number of credits p_type_fifo : string := "RI"; -- options: NO (none), SH (shift) and RI (ring) p_width : integer:= 32; -- width of each position p_log2_depth : integer:= 2; -- log2 of the number of positions -- Package Parameters p_x_dest : integer:= 1; -- x-coordinate p_y_dest : integer:= 1; -- y-coordinate p_rib_width : integer:= 8 -- width of the rib field in the header Figura 19. Parâmetros do adaptador da interface de áudio O parâmetro diretamente utilizado no adaptador é o p_n. Nele é estabelecido número de flits do pacote. Como um flit possui 32 bits e as amostras PCM são de 8 bits, em cada flit podem ser agrupadas 4 amostras PCM. Definido-se p_n, define-se o número de amostras por pacote. Neste trabalho foi empregado o número de 16 amostras PCM por pacote (p_n = 4). 45

47 3.3.2 Gerador de Tráfego Esse núcleo é uma versão simplificada do módulo para geração de tráfego desenvolvido por Pereira (2008). É utilizado para gerar tráfego sem requisitos de QoS (ruído) usando uma taxa de injeção constante, com pacotes de tamanho fixo. O seu bloco é ilustrado na Figura 20. Figura 20. Módulo gerador de tráfego O módulo é composto basicamente de uma porta de saída (o_out_data), de sinais de validação (o_out_val) e de retorno (i_out_ret) da interconexão com a NoC. Por ser parametrizável, é possível obter variações de tráfego de acordo com os parâmetros disponíveis no núcleo. Na Figura 21 é apresentada a lista dos parâmetros de configuração do TG. -- TG Parameters p_payload_length : integer:= 100; -- length of the packet payload p_iat : integer:= 150; -- inter-arrival time p_nb_packet : integer:= 0; -- no of packets to be sent (0 = unlimited) p_clock_width : integer:= 32; -- width of clock counter -- Package Parameters p_x_dest : integer:= 1; -- x-coordinate p_y_dest : integer:= 1; -- y-coordinate p_rib_width : integer:= 8; -- width of the rib field in the header p_data_width : integer:= 32; -- width of data channel -- FIFO Parameters p_fc_type : string := "CB"; -- options: CB or HS p_fc_credit : integer:= 4; -- initial number of credits for lout p_fifo_type : string := "RI"; -- options: NO, SH & RI p_fifo_depth : integer:= 4; -- number of positions p_fifo_log2_depth : integer:= 2 -- log2 of the number of positions Figura 21. Parâmetros do gerador de tráfego Fonte: Adaptado de Pereira (2008). No exemplo ilustrado na figura, o TG é configurado para gerar um número ilimitado de pacotes com 100 flits de payload (carga útil ou corpo do pacote) e um intervalo entre chegadas de 46

48 150 ciclos, o que resulta em uma taxa de injeção de cerca de 67% da capacidade da rede: (100+1)/150, onde a unidade adicional no numerador corresponde ao cabeçalho do pacote. Para a geração de ruído, são diretamente utilizados os parâmetros p_payload_length e p_iat, deixando os demais com seus valores de configuração padrão compatível com a NoC. A geração alternada de ruído se dará pela modificação do comprimento da carga útil (p_payload_length) e pelo mudança no intervalo de injeção desses pacotes (p_iat) Medidor de deadlines perdidos O núcleo desenvolvido para medição de tráfego do fluxo de dados com requisitos de QoS (telefonia) contabiliza a perda de deadlines de cada pacote enviado (Figura 22). Ele pode ser descrito como um analisador de amostras de entrada (i_in_data) que apresenta a quantidade de deadlines perdidos, o_missed_deadlines. Os parâmetros presentes no medidor são apresentados na Figura 23 e devem corresponder aos aplicados no gerador de tráfego e na rede. Figura 22. Módulo medidor de tráfego -- TM Parameters p_iat : integer:= 150; -- inter-arrival time p_clock_width : integer:= 32; -- width of clock counter -- Package Parameters p_data_width : integer:= 32; -- width of data channel -- FIFO Parameters p_fc_type : string := "CB" -- options: CB or HS Figura 23. Parâmetros do gerador de tráfego Fonte: Adaptado de Pereira (2008). 47

49 Para a medição de tráfego, tomou-se por perda de deadline a violação do tempo entre chegadas exigido pela aplicação (p_iat). Por exemplo, se o emissor injeta pacotes numa taxa de um pacote a cada 150 ciclos, p_iat = 150. Após receber o primeiro pacote, o medidor de tráfego irá controlar se os pacotes seguintes chegam a cada 150 ciclos. Cada vez que isso não ocorrer, a perda de um deadline é contabilizada. Adicionalmente, um outro contador de perdas de deadline foi implementado. Este, porém, monitora as amostras extraídas do pacote recebido e entregues na taxa de consumo do PCM. Cada vez que o controlador do CODEC tenta consumir uma amostra e o buffer de recepção do wrapper de entrada está vazio, isso representa que um pacote se atrasou e a amostra que deveria estar disponível perdeu o prazo definido. Numa comunicação, isso seria notado por efeitos como atrasos ou falhas na recepção do áudio. Na implementação atual, essa perda de dealine é detectada pelo recebimento de uma amostra com conteúdo inválido (0x00), mas poderia ser feito pela monitoração do estado do buffer (se vazio, deadline perdido). 3.4 Implementação A metodologia adotada neste projeto foi a bottom-up, onde os componentes são construídos e integrados do nível mais baixo para o nível mais alto da hierarquia do projeto. Foi utilizada a linguagem VHDL para descrever os núcleos do projeto como modelos sintetizáveis. Foram efetuados testes individuais de cada bloco antes de sua integração através da simulação lógica dos modelos. A aplicação é disponibilizada com a integração de todos os blocos pertencentes ao sistema. A Figura 24 (apresentada previamente) ilustra a arquitetura disponibilizada neste trabalho. A aplicação é baseada em uma rede 3x2, de topologia anel, contendo: duas interfaces de áudio PCM (I/F Áudio), dois adaptadores de interface de áudio (wrappers), dois medidores de deadlines perdidos (TM) e um gerador de tráfego (TG). 48

50 I/F Áudio Wrapper TG TM TM Wrapper I/F Áudio Figura 24. Núcleos integrados à rede e seus fluxos de comunicação Devido a problemas encontrados na alimentação da interface e na adaptação dos controles dos CODECs, a placa fornecida não foi utilizada, o que se pretende fazer após a solução desses problemas. Para contornar essa limitação, foi implementado um emulador do CODEC que realiza a geração de amostras segundo as características PCM, gerando amostras de 8 bits a cada ciclo (125 μs). A principal restrição da solução é que ela não permite a realização de experimentos práticos planejados para a demonstração do efeito da concorrência entre os fluxos e a degradação da qualidade do áudio quando da ocorrência da perda de deadlines. Resultados da síntese Para o desenvolvimento dos modelos VHDL foi utilizado o ambiente de desenvolvimento ISE 10.1 da Xilinx. Cada modelo foi testado e validado na ferramenta de síntese. A Tabela 8 apresenta uma síntese do custo em Flip-Flops (FF) e Look-Up Tables (LUT) da plataforma ilustrada na Figura 24. Os parâmetros utilizados foram os apresentados nas descrições dos módulos para a síntese em um FPGA Virtex 5, da Xilinx. Foram sintetizadas o emulador do CODEC (codec), o adaptador de interface de áudio (wrapper), o medidor de deadlines perdidos (tm), o gerador de 49

51 tráfego (tg) e o roteador da rede (paris). Observa-se que os módulos de maior custo são o wrapper e o tg. Tabela 8. Visão geral do custo em FPGA de uma XC5VFX30T-3FF665 Componente FFs LUTs Codec Wrapper Tm Tg Paris A operação básica do sistema, considerando dois terminais telefônicos, consiste dos seguintes passos previstos para a realização do experimento prático (quando os problemas com a placa de interface de áudio digital forem solucionados): 1. Dois usuários retiram os terminais do gancho; 2. Os wrappers amostram os sinais de áudio de cada terminal a cada 125 s e os empacotam em pacotes SoCIN, incluindo informações necessárias para identificar o cumprimento do prazo de entrega; 3. Os pacotes SoCIN são trocados entre os terminais pela rede, competindo com o tráfego gerado pelos TGs; e 4. Os pacotes SoCIN são recebidos pelos wrappers que os desempacotam e os entregam às placas de I/F de áudio. Medidores de perdas de prazo contabilizam quando um deadline for perdido. Os TGs poderão ser configurados de modo a perturbar a comunicação entre os terminais telefônicos de modo a avaliar a capacidade da rede de prover QoS a esses fluxos quando estiver operando a uma freqüência de relógio mínima. Isso permitirá identificar melhorias a serem feitas na rede para prover QoS a esses fluxos e avaliar a eficácia dessas melhorias. Porém, até o momento, esse experimento só pode ser simulado em um domínio de tempo reduzido de modo a evidenciar o funcionamento da NoC. 50

52 3.5 Validação por simulação Para validar o sistema, foram efetuados experimentos com diferentes taxas de injeção de ruído. O objetivo é identificar a perturbação atuante no fluxo com requisitos de QoS, tendo como base a perda de deadlines de pacotes. Para a análise, foram injetados 20 pacotes de amostras PCM, fixado o valor do intervalo entre as amostras (p_iat) em 150 ciclos e variado o comprimento da carga útil (p_payload_length). Tal medida é adotada para simplificar a análise do sistema, pois a verificação em tempo real (amostras PCM a cada 125 µs) necessita de grande volume de processamento e tempo de simulação, tornando-a inaplicável. Experimento sem tráfego de ruído No primeiro experimento, o desempenho da rede é avaliado sem injeção de ruído. Na Figura 25, é ilustrado o diagrama de formas de onda de uma simulação. Figura 25. Medição de deadlines perdidos sem tráfego de ruído. Na Figura 25, o primeiro conjunto de sinais mostra as saídas dos medidores de tráfego que contabilizam os deadlines perdidos por pacotes ao chegarem nos CODECs destinos (no exemplo, o_missed_deadlines1 e o_missed_deadlines2 são iguais a 0). O segundo conjunto de sinais ilustra as amostras geradas pelo emulador do CODEC 1 (w_dout_cd1) e os pacotes injetados na rede (w_l01_in_data), cada um com 16 amostras. O terceiro conjunto mostra a chegada desses 51

53 pacotes no seu destino e a entrega das amostras ao CODEC 2 (w_din_cd2). Os dois conjuntos de sinais seguintes ilustram o fluxo de amostras e pacotes do CODEC 2 para o CODEC 1. Por fim, o último conjunto de sinais mostra os pacotes injetados na rede pelo TG. No exemplo ilustrado na figura anterior, conforme esperado, não houve perda de deadlines em nenhum dos nodos, pois nenhum tráfego de ruído foi gerado pelo TG. A Figura 26 mostra uma aproximação de uma região da simulação que confirma a integridade da comunicação. As amostras geradas por cada CODEC são reproduzidas pelo respectivo CODEC destino. Figura 26. Verificação da comunicação entre CODECs sem tráfego de ruído. Experimento com tráfego de ruído injetando pacotes a 33% da capacidade do canal No segundo experimento, o TG injeta pacotes de 50 flits a cada 150 ciclos, o que corresponde a um tráfego de ruído requerendo 33% da largura de banda do canal. A perda de deadlines (30%) pelos pacotes PCM decorrente da concorrência com o tráfego de ruído é ilustrada na Figura 27, onde observa-se a perda de 6 deadlines (o_missed_deadlines2) durante o período da simulação (100µs) no fluxo sujeito à concorrência. Observa-se, também, que não houve perdas (o_missed_deadlines1) no fluxo de comunicação que não está sujeito à concorrência. 52

54 Figura 27. Medição de deadlines perdidos para tráfego de ruído de 33% Devido à concorrência, a comunicação entre os CODECs sofreu interferências no sentido de fluxo sujeito a ruído (do CODEC 1 para o CODEC 2), o que também pode ser notado, na Figura 28, pela presença de uma amostra de valor 0x00 na recepção do CODEC 2. Figura 28. Verificação da comunicação entre CODECs para tráfego de ruído de 33% 53

55 Experimento com tráfego de ruído injetando pacotes a 66% da capacidade do canal No terceiro experimento, é injetado ruído com 66% da capacidade do canal, ou seja, pacotes de 100 flits sendo injetados pelo TG a cada 150 ciclos. O desempenho da rede pode ser analisado na Figura 29. Figura 29. Medição de deadlines perdidos para tráfego de ruído de 66% Percebe-se a perda de 11 deadlines (o_missed_deadlines2) para o mesmo período de simulação (100µs) no fluxo sujeito a ruídos, comprometendo 55% do tráfego com requisitos de QoS. Não ocorreram perdas (o_missed_deadlines1) no fluxo de comunicação sem concorrência. Experimento com tráfego de ruído injetando pacotes a 100% da capacidade do canal No último experimento, o desempenho da rede é avaliado com a máxima injeção de ruído, ou seja, com o TG injetando pacotes de 150 flits a cada 150 ciclos, requerendo o uso de 100% da largura de banda do canal, conforme ilustra a Figura

56 Figura 30. Medição de deadlines perdidos para tráfego de ruído de 100% Nesse experimento, não houve um aumento significativo na perda de deadlines (60%) em relação ao experimento anterior, para o mesmo período da simulação (100µs), o que pode ser provocado pelo fato de que os fluxos concorrentes utilizam taxas de injeção constante e, em algum momento, há um sincronismo entre as chegadas dos pacotes. 3.6 Discussão Neste capítulo, foram apresentados o projeto e a implementação da aplicação proposta para avaliação de suporte a QoS por uma NoC. A aplicação foi desenvolvida como uma plataforma de SoC baseada em um rede SoCIN 3x2 com núcleos que emularam a geração de tráfego PCM (com seu respectivo wrapper) e de tráfego de ruído, além de núcleos medidores de perdas de deadlines. Devido a problemas encontrados na placa de interface de telefonia, a plataforma foi validada apenas por simulação, mas foi possível confirmar a sua aplicabilidade para o objetivo proposto: permitir a avaliação de QoS em uma NoC. Neste TCC, os experimentos foram limitados à avaliação da rede SoCIN, que não oferece garantias de QoS. Mas essa plataforma será aplicada no projeto de uma variação da rede SoCIN que proverá mecanismos de QoS baseados na diferenciação de serviços. 55