RUBENS VICENTE DE LIZ BOMER USO DE ANÁLISE DE ESCALONABILIDADE PARA ACELERAR A EXPLORAÇÃO DO ESPAÇO DE PROJETO EM SISTEMAS BASEADOS EM REDES-EM-CHIP

Transcrição

1 RUBENS VICENTE DE LIZ BOMER USO DE ANÁLISE DE ESCALONABILIDADE PARA ACELERAR A EXPLORAÇÃO DO ESPAÇO DE PROJETO EM SISTEMAS BASEADOS EM REDES-EM-CHIP Itajaí (SC), fevereiro de 2017

2 UNIVERSIDADE DO VALE DO ITAJAÍ CURSO DE MESTRADO ACADÊMICO EM COMPUTAÇÃO APLICADA USO DE ANÁLISE DE ESCALONABILIDADE PARA ACELERAR A EXPLORAÇÃO DO ESPAÇO DE PROJETO EM SISTEMAS BASEADOS EM REDES-EM-CHIP por Rubens Vicente de Liz Bomer Dissertação apresentada como requisito parcial à obtenção do grau de Mestre em Computação Aplicada. Orientador: Cesar Albenes Zeferino, Dr. Itajaí (SC), fevereiro de 2017

3 FOLHA DE APROVAÇÃO Esta página é reservada para inclusão da folha de assinaturas, a ser disponibilizada pela Secretaria do Curso para coleta da assinatura no ato da defesa.

4 Frequentemente, os melhores momentos na vida são quando a gente não está fazendo nada, só ruminando. Quer dizer, a gente pensa que todo mundo é sem sentido, aí vê que não pode ser tão sem sentido assim se a gente percebe que é sem sentido, e essa consciência da falta de sentido já é quase um pouco de sentido. Sabe como é? Um otimismo pessimista. Charles Bukowski

5 USO DE ANÁLISE DE ESCALONABILIDADE PARA ACELERAR A EXPLORAÇÃO DO ESPAÇO DE PROJETO EM SISTEMAS BASEADOS EM REDES-EM-CHIP Rubens Vicente de Liz Bomer fevereiro / 2017 Orientador: Cesar Albenes Zeferino, Dr. Área de Concentração: Computação Aplicada Linha de Pesquisa: Sistemas Embarcados e Distribuídos Palavras-chave: NoC, SoC, Análise de escalonabilidade. Número de páginas: 126 RESUMO Redes-em-Chip utilizadas em sistemas de tempo real necessitam cumprir os requisitos temporais da aplicação alvo. Uma mensagem crítica enviada de um nodo a outro pela rede deve ser entregue dentro de um prazo específico. A violação desse requisito pode comprometer o funcionamento do sistema inteiro. Entretanto, as comunicações em uma Rede-em-Chip podem sofrer contenções, devido à competição por recursos, atrasos na entrega dos pacotes e possíveis perdas de prazos. Para determinar se a rede consegue atender aos requisitos temporais de uma aplicação de tempo real, é necessário realizar uma série de experimentos considerando cenários de pior caso. Os experimentos de simulações possuem tempo computacional elevado, e uma alternativa é o uso de uma análise de escalonabilidade. Essa abordagem permite prever o comportamento dos fluxos e o cumprimento de prazos em situações de pior caso para um determinado algoritmo de escalonamento. Nesse contexto, o presente trabalho propôs modelos para uma análise de escalonabilidade de modo a acelerar a exploração do espaço de projeto de aplicações de tempo real em sistemas integrados baseados em Rede-em-Chip. Esses modelos avaliam a latência máxima de fluxos de uma rede considerando bloqueios diretos, bloqueios indiretos, auto-bloqueios, dependência entre tarefas e a variação da profundidade dos buffers. Uma série de experimentos foram efetuados utilizando um simulador com precisão de ciclos para o refinamento e a validação dos modelos. Os resultados experimentais demonstraram que a análise baseada nos modelos propostos são quatro ordens de magnitude mais rápidos que a simulação, e o erro médio da estimativa da latência máxima foi menor que 10%.

6 USE OF SCHEDULABILITY ANALYSIS TO ACCELERATE THE DESIGN ESPACE EXPLORATION IN NETWORK-ON-CHIP BASED SYSTEMS Rubens Vicente de Liz Bomer February / 2017 Advisor: Cesar Albenes Zeferino, Ph.D. Area of Concentration: Applied Computer Science Research Line: Embedded and Distributed Systems Keywords: Networks-on-Chip, Systems-on-Chip, Schedulability analysis. Number of pages: 126 ABSTRACT Networks-on-Chip (NoC) used in real-time systems must meet the time requirements of the target application. A critical message sent from one node to another through the network must be delivered in a specific deadline. A violation of these requirements may compromise the entire system operation. However, the competition for NoC resources can delay the delivery of packages, and result in missed deadlines. In order to determine whether a network can meet these time requirements of a real-time application, it is necessary to conduct a series of experiments considering worst-case scenarios. Simulation-based experiments are time consuming, and one alternative is the use of schedulability analysis. This approach allows the behavior of flows to be predicted, as well the meeting of deadlines requirements in worst-case scenarios for a particular scheduling algorithm. In this context, this work proposes models for a schedulability analysis in order accelerate the exploration of design space in real-time applications in NoC-based SoCs. These models evaluate the maximum latency of flows in a network, by taking into account direct blocks, indirect blocks, selfblocks, task dependence and buffers size. A series of experiments was performed using a cycleaccurate simulator to refine and validate the models. The experimental results demonstrated that the analysis based on the proposed models are four orders of magnitude faster than the simulation, and that the average error to estimate the maximum latency is less than 10%.

7 LISTA DE ILUSTRAÇÕES Figura 1. Exemplo de redes com topologia direta: (a) ponto-a-ponto; e (b) malha Figura 2. Exemplo de topologias indiretas: (a) árvore gorda; e (b) butterfly Figura 3. Estrutura de mensagens, pacotes, flits e phits Figura 4. Controle de fluxo baseado em créditos Figura 5. Exemplo de gráficos: (a) vazão; (b) latência média Figura 6. Sistema de coordenadas da Rede SoCIN Figura 7. Rede SoCIN: (a) enlace; (b) formato do pacote Figura 8. Módulos de cada porta de um roteador interconectados por uma matriz de conexões Figura 9. Estrutura interna dos módulos do roteador ParIS: (a) entrada; (b) saída Figura 10. SoCIN-Q: (a) módulo de entrada; (b) módulo de saída; (c) formato do pacote Figura 11. Exemplo de sistema criado com o simulador BrownPepper Figura 12. Exemplo de escalonamento para avaliação do pior tempo de resposta de uma tarefa Figura 13. Classificação dos algoritmos de escalonamento de tarefas RT Figura 14. Diagrama de um escalonamento RM Figura 15. Diagramas de escalonamento: (a) FIFO; (b) EDF Figura 16. Interferências: (a) direta; (b) indireta Figura 17. Diagrama de sequência para tarefas dependentes Figura 18. Modificações realizadas: (a) TG original; (b) TG modificado Figura 19. Latência básica de τ1: (a) caminho percorrido e (b) linha do tempo Figura 20. Enlaces: (a) considerados em (13) e (b) enlaces em comum entre τi e τj Figura 21. Se vi > vj vk: (a) τj é bloqueado por τk; e (b) τi envia flits quando acaba os buffers Figura 22. Bloqueio indireto: (a) τk possui influência com 4 flits; e (b) não gera bloqueio com 5 flits Figura 23. Enfileiramento composto por cinco fluxos Figura 24. Grafos de precedência: (a) dependência entre τi e τp e (b) quatro fluxos dependentes.. 63 Figura 25. Diagrama de τprec e τi Figura 26. Diagrama de τi para LiMax > pi Figura 27. Bloqueio Bj composto de τj e τk Figura 28. Fluxograma para a verificação e refinamento dos modelos Figura 29. Cenário para o refinamento dos modelos considerando bloqueios diretos Figura 30. Cenário para o refinamento dos modelos considerando a preempção de fluxos Figura 31. Cenário para o refinamento dos modelos considerando bloqueios indiretos Figura 32. Cenário para o refinamento dos modelos considerando a dependência de tarefas Figura 33. Cenário para o refinamento dos modelos considerando auto-bloqueios Figura 34. Cenário para o Experimento Quadro 1. Análise comparativa dos trabalhos selecionados Quadro 2. Arquitetura base da rede de referência Quadro 3. Atributos do sistema considerados nos modelos sem auto-bloqueio Quadro 4. Atributos do sistema considerados nos modelos com auto-bloqueio... 57

8 LISTA DE TABELAS Tabela 1. Tarefas periódicas para o escalonamento RM Tabela 2. Tarefas para o escalonamento FIFO e EDF Tabela 3. Configuração dos fluxos para a análise de bloqueios diretos Tabela 4. Resultados obtidos no experimento considerando bloqueios diretos Tabela 5. Configuração dos fluxos para a análise de preempções Tabela 6. Resultados obtidos no experimento considerando preempções Tabela 7. Erro em relação a simulação para as análises Tabela 8. Configuração dos fluxos para a análise de bloqueios indiretos Tabela 9. Resultados obtidos considerando buffers com 4 flits Tabela 10. Resultados obtidos considerando buffers com 64 flits Tabela 11. Configuração dos fluxos para a análise da dependência de tarefas Tabela 12. Resultados obtidos no experimento considerando a dependência de tarefas Tabela 13. Configuração dos fluxos para a análise de auto-bloqueios Tabela 14. Resultados obtidos no experimento considerando auto-bloqueios Tabela 15. Configuração dos fluxos do Experimento Tabela 16. Erro das análises para mapeamentos com destinos únicos Tabela 17. Erro das análises para mapeamentos com destinos repetidos Tabela 18. Tempo de execução do Experimento Tabela 19. Configuração dos fluxos para o Experimento Tabela 20. Erro das análises para cada profundidade de buffers Tabela 21. Tempo de execução do Experimento

9 LISTA DE ABREVIATURAS E SIGLAS ACK BE bop CPM DM EDF eop FIFO Flit GS HDL HLP IC IFC IP IRS MCA MLS mmc NoC OC ODS OFC OWS ParIS Phit QoS RIB RM RT nrt RTL SAF SoC SoCIN TG TM UNIVALI VCT VHDL VHSIC VLSI Acknowledgement Best Effort Begin-of-packet Cross Point Matrix Deadline-Monotonic Earliest-Deadline-Firts End-of-packet First In, First Out Flow Control Unit Guaranteed Service Hardware Description Language Higher Level Protocol Input Controller Input Flow Control Intellectual Property Input Read Switch Mestrado em Computação Aplicada Menor Limite Superior Mínimo múltiplo comum Network-on-Chip Output Control Output Data Switch Output Flow Controller Output Write Switch Parameterizable Interconnect Switch Physical unit Quality-of-Service Routing Information Bits Rate-Monotonic Real-Time non-real-time Register Transfer Level Store and Foward System-on-Chip SoC Interconnection Network Traffic Generator Traffic Metter Universidade do Vale do Itajaí Virtual Cut Through VHSIC HDL Very High Speed Integrated Circuit Very Large Scale Integration

10 LISTA DE SÍMBOLOS B e E d I J L p Q r R s S T U v β Γ τ Bloqueio Tempo máximo de execução ou tempo de pior caso Enlace Deadline Interferência Job ou instância de uma tarefa Latência Período Quantidade de pacotes enfileirados Tempo de chegada ou tempo de início Roteador Tempo de memorização, roteamento e arbitragem Conjunto de fluxos bloqueantes ou de bloqueios Tarefa Utilização total Numeração do canal virtual Conjunto de enlaces Conjunto de fluxos Fluxo

11 SUMÁRIO 1 INTRODUÇÃO PROBLEMA DE PESQUISA Solução Proposta Delimitação de Escopo OBJETIVOS Objetivo Geral Objetivos Específicos METODOLOGIA Metodologia da Pesquisa Procedimentos Metodológicos ESTRUTURA DA DISSERTAÇÃO FUNDAMENTAÇÃO TEÓRICA REDES-EM-CHIP Arquitetura de uma Rede-em-Chip Métricas de Desempenho Qualidade de Serviço Rede SoCIN SISTEMAS DE TEMPO REAL Tarefas de Tempo Real Tempo de Resposta de Pior Caso Escalonamento de Tarefas Análise de Escalonabilidade CONSIDERAÇÕES TRABALHOS RELACIONADOS ANÁLISE COMPARATIVA CONSIDERAÇÕES ANÁLISE DE ESCALONABILIDADE DA REDE SOCIN-Q MODELO DO SISTEMA Arquitetura Base da Rede-em-Chip Modificações Realizadas no Simulador Redscarf ANÁLISE DE ESCALONABILIDADE Latência Básica Bloqueios Diretos Bloqueios Indiretos Dependência de Tarefas Auto-bloqueios CONSIDERAÇÕES... 67

12 5 RESULTADOS FLUXO DE REFINAMENTO E VALIDAÇÃO DOS MODELOS EXPERIMENTOS Refinamento Validação DISCUSSÃO CONCLUSÕES CONTRIBUIÇÕES DA DISSERTAÇÃO TRABALHOS FUTUROS REFERÊNCIAS APÊNDICE A REVISÃO SISTEMÁTICA APÊNDICE B RESULTADOS DOS EXPERIMENTOS... 90

13 12 1 INTRODUÇÃO O advento das tecnologias submicrônicas para fabricação de circuitos viabilizou a integração de sistemas computacionais completos em um único chip, os quais são denominados SoCs (Systemson-Chip). Tais sistemas são constituídos de múltiplos componentes de processamento, memória e periféricos interconectados por uma arquitetura de comunicação. Esses componentes são usualmente referidos pelos termos núcleo (do inglês, core) e IP (Intellectual Property) (GUPTA; ZORIAN, 1997). SoCs com reduzido número de núcleos (poucas dezenas) são usualmente interligados por meio de arquiteturas de comunicação baseadas no barramento, que é um meio físico constituído por canais (fios) de endereço, dado e controle compartilhados pelos núcleos a ele conectados. O barramento tem como principal benefício o fato de ser facilmente reutilizado de um projeto para outro, característica importante para reduzir o tempo do projeto de um novo SoC. No entanto, sua principal limitação reside no fato de suportar uma única comunicação em um dado momento (ou seja, não oferece paralelismo em comunicação) e o seu desempenho diminuir com o aumento do número de núcleos no sistema (GUERRIER; GREINER, 2000). Sistemas com várias dezenas de núcleos requerem que a arquitetura de interconexão suporte múltiplas comunicações simultâneas e seu desempenho aumente com o tamanho do sistema, o que não ocorre com o barramento. Além disso, a arquitetura deve ser reutilizável, como o barramento, para não impactar no tempo de projeto do SoC. Dado esse problema, no início dos anos 2000, pesquisadores de universidades e de indústrias passaram a buscar uma arquitetura de interconexão que atendesse a esses requisitos (GUERRIER; GREINER, 2000; HEMANI et al. 2000; DALLY; TOWLES, 2001; KARIM; DEY, 2001; BENINI; DE MICHELI, 2002). A solução encontrada foi baseada nas arquiteturas de comunicação utilizadas nos computadores paralelos, mais conhecidos como Redes de Interconexão (DUATO; YALAMANCHILI; NI, 2003). Por se tratar de uma rede integrada em um único chip, essa arquitetura foi batizada por Hemani et al. (2000) de Network-on- Chip ou NoCs, termo adotado pela comunidade internacional. Em português, adotam-se os temos Redes-em-Chip e redes intrachip. Como uma plataforma de integração, uma NoC deve ter a capacidade de fornecer diferentes níveis de serviço para várias aplicações na mesma rede, ou seja, garantir a qualidade de serviço ou QoS (Quality-of-Service) (BENINI; DE MICHELI, 2002). Algumas aplicações possuem

14 13 requerimentos de serviço de comunicação muito restritos, o qual depende não apenas do resultado da mesma, como também da sua realização em um limite de tempo, denominado deadline (ou prazo). Essas comunicações críticas são chamadas de serviços de tempo real ou RT (Real-Time) (SHI, 2009 p. 18). Um fluxo de tráfego é uma série de pacotes que atravessa a mesma rota da origem ao destino e requer o mesmo nível de serviço ao longo do caminho. Para fluxos de tráfego de tempo real do tipo hard, é necessário que todos os pacotes gerados sejam entregues dentro de um prazo (ou deadline) pré-estabelecido, mesmo em situações de pior caso. O não cumprimento de prazos em aplicações com deadline hard pode causar efeitos catastróficos (BURNS; WELLINGS, 2009 p. 3). É essencial que os serviços oferecidos apresentem um comportamento previsível para ser possível prover comunicações RT em SoCs. Porém, o comportamento de uma NoC é parcialmente não-determinístico pois ocorrem contenções devido à competição por recursos compartilhados, tais como buffers e canais de comunicação. Consequentemente, isso acarreta em atrasos na entrega dos pacotes. Uma análise exata do congestionamento nessa situação é difícil devido à possibilidade de os pacotes serem bloqueados em diversos roteadores durante o seu deslocamento pela NoC. Por esse motivo, é necessário o uso de mecanismos de arbitragem baseados em prioridades, controle de fluxo com suporte a canais virtuais e a aplicação de uma abordagem analítica para prever o cumprimento dos requisitos temporais de todos os pacotes RT (SHI; BURNS; INDRUSIAK, 2010). 1.1 PROBLEMA DE PESQUISA Para determinar se uma NoC consegue atender aos requisitos temporais de uma aplicação de tempo real, é necessário realizar uma série de experimentos e simulações considerando cenários de pior caso, uma vez que os prazos deste tipo de aplicações sempre devem ser cumpridos. Porém, o espaço de projeto de uma NoC é amplo, pois envolve um conjunto de diferentes parâmetros cuja combinação tem impacto no custo e no desempenho da rede e do sistema. Para avaliar essas métricas, são utilizadas ferramentas de síntese em silício e de simulação as quais possuem um alto custo computacional. Portanto, a exploração do espaço de projeto de uma NoC, é tarefa que demanda tempo elevado para ser executada (PANDE et al., 2005).

15 14 Nesse contexto, este trabalho procurou investigar como prever o comportamento de aplicações de tempo real em uma NoC de modo a definir se uma determinada configuração da rede atende ou não aos requisitos temporais da aplicação a fim de reduzir o tempo para exploração do espaço de projeto. Foi aplicada uma abordagem analítica para verificação da escalonabilidade (cumprimento de prazos) da aplicação, considerando a dependência de tarefas, a profundidade de buffers, a interferência de fluxos com maior prioridade e os bloqueios de pacotes na NoC. Considerando esse objetivo, este trabalho buscou responder às seguintes perguntas de pesquisa: Qual é a aceleração da exploração de projeto obtida com o uso da análise de escalonabilidade em relação ao uso de um modelo de simulação? A acurácia 1 da análise de escalonabilidade é suficiente a ponto de substituir uma simulação? Solução Proposta Para tratar o problema supracitado, deste trabalho, foi proposto o desenvolvimento de modelos analíticos para análise de escalonabilidade de aplicações de tempo real em uma NoC e a comparação com modelos de simulação visando reduzir o tempo para exploração do espaço de projeto. Como hipóteses, assume-se que: H0: A análise de escalonabilidade reduz o tempo para exploração do espaço de projeto com erro de estimativa de até 10% 2 em relação à simulação; H1: A análise de escalonabilidade reduz o tempo para exploração do espaço de projeto, porém com erro de estimativa maior que 10% 1 em relação à simulação. 1 No contexto desta dissertação o termo se refere à proximidade entre o valor obtido pelos modelos (experimental) e o valor obtido por meio de simulação (assumido como verdadeiro) 2 Este valor foi determinado com base nos trabalhos relacionados ao tema desta dissertação

16 Delimitação de Escopo Neste trabalho, foram desenvolvidos modelos de análise de escalonabilidade para aplicações de tempo real em uma NoC, levando em consideração bloqueios diretos, indiretos, auto-bloqueios, dependência de tarefas e a profundidade de buffers. Modelos para estimativas de custo (área de silício e potência) não foram abordados, tendo foco apenas nas métricas de desempenho e no cumprimento de prazos. Também não foi desenvolvido nenhum tipo de abordagem para realizar o mapeamento das tarefas da aplicação na rede, o qual foi feito com o uso de posicionamento aleatório das tarefas. 1.2 OBJETIVOS Objetivo Geral Acelerar a exploração do espaço de projeto de aplicações de tempo real em sistemas integrados baseados em Rede-em-Chip por meio do uso da análise de escalonabilidade Objetivos Específicos 1. Identificar características da NoC e do comportamento dos fluxos de tráfego que influenciam no cumprimento de prazos; e 2. Desenvolver modelos de análise de escalonabilidade que apresentem erro máximo de 10% em relação a modelos de simulação. 1.3 METODOLOGIA Metodologia da Pesquisa Este trabalho busca a solução de um problema com base na formulação de hipóteses, por este motivo adota o método hipotético-dedutivo. Também se caracteriza como uma pesquisa aplicada, pois as hipóteses serão confirmadas ou rejeitadas com base nos experimentos realizados. Quanto à abordagem, esta pesquisa é classificada como quantitativa, pois os resultados serão medidos através

17 16 de dados gerados pelo ferramental de experimentação, e também como qualitativa uma vez que é necessário interpretar os resultados gerados Procedimentos Metodológicos Para o desenvolvimento deste trabalho, foi realizada uma revisão bibliográfica das publicações mais recentes sobre a análise de escalonabilidade em NoCs que tem como objetivo garantir o cumprimento de prazos das tarefas de aplicações de tempo real. Durante a elaboração da fundamentação teórica, foi realizada uma pesquisa na literatura já consolidada na área dos assuntos tratados. Foram adotados como referência artigos publicados em veículos reconhecidos, livros, dissertações de mestrado e teses de doutorado. O desenvolvimento dos modelos para a análise de escalonabilidade, bem como os experimentos para sua validação foram baseados em trabalhos publicados com o mesmo tema. 1.4 ESTRUTURA DA DISSERTAÇÃO Este documento está organizado em cinco capítulos. No capítulo introdutório, foi apresentado o contexto relacionado ao tema de pesquisa proposto e foram discutidos o problema abordado e a solução proposta, incluindo a definição de objetivos e a metodologia adotada nas pesquisas. O Capítulo 2 apresenta a fundamentação teórica sobre os temas abordados nesta pesquisa. Inicialmente são apresentados os conceitos sobre NoCs, seus mecanismos de comunicação, métricas e a arquitetura da rede SoCIN, utilizada como base neste trabalho. Em seguida, é apresentada a fundamentação sobre sistemas de tempo real, escalonamento de tarefas e análise de escalonabilidade. No Capítulo 3, são descritos os trabalhos relacionados. São discutidas as características consideradas na análise de escalonabilidade de redes em chip. Ao final, é apresentada uma análise comparativa entre os trabalhos, o posicionamento desse trabalho e as considerações finais do capítulo. O Capítulo 4 apresenta o modelo do sistema, as modificações necessárias no simulador da rede SoCIN e os modelos desenvolvidos para a análise de escalonabilidade e a forma de validação. O Capítulo 5 apresenta o fluxo para o refinamento e validação dos modelos, os experimentos realizados e os resultados obtidos. O Capítulo 6 apresenta as conclusões e trabalhos futuros.

18 17 2 FUNDAMENTAÇÃO TEÓRICA Este capítulo apresenta a fundamentação teórica sobre redes-em-chip na Seção 2.1. Os conceitos de sistemas de tempo real são apresentados na Seção 2.2, enquanto a Seção 2.3 apresenta as considerações do capítulo. 2.1 REDES-EM-CHIP As arquiteturas de comunicação intrachip baseadas nos conceitos de redes chaveadas foram discutidas inicialmente na década de 90 por Tewksbury, Uppuluri e Hornak (1992). Porém só ganharam maior destaque na literatura a partir do ano 2000 quando foram publicados os primeiros trabalhos com os primeiros resultados experimentais sobre Redes-em-Chip (GUERRIER; GREINER, 2000; LANGEN; BRINKMANN; RUCKERT, 2000). Os sistemas integrados (ou SoCs) necessitam de uma arquitetura que forneça escalabilidade e reusabilidade para suportar a interconexão de dezenas a milhares de núcleos integrados em um mesmo chip. A arquitetura baseada em barramento consegue fornecer reusabilidade, porém não possui escalabilidade. Redes-em-Chip ou Networks-on-Chip (NoCs) aparecem como uma estratégia para realizar a interconexão entre diversos núcleos, mantendo escalabilidade, reusabilidade e paralelismo como necessário nos sistemas integrados (OGRAS; MARCULESCU, 2013, p. 2-3). Uma NoC (Networks-on-Chip) consiste de múltiplos roteadores conectados por intermédio de canais ponto-a-ponto e de modo estruturado. Como exemplos de NoCs apresentadas na literatura temos a rede SPIN (GUERRIER; GREINER, 2000), Spidergon (COPPOLA et al., 2004), HERMES (MORAES et al., 2004) e SoCIN (ZEFERINO; SUSIN, 2003). A arquitetura de uma NoC pode ser caracterizada pela sua topologia e seus mecanismos de comunicação. A topologia define a estrutura da rede, enquanto os mecanismos de comunicação definem a forma pela qual ocorre a transferência das mensagens pela rede. Dentre os mecanismos de comunicação, estão inclusos o chaveamento, o roteamento, o controle de fluxo, a arbitragem e a memorização (DALLY; TOWLES, 2004, p. 13). As subseções a seguir discutem os aspectos referentes à arquitetura de uma NoC e os mecanismos de comunicação.

19 Arquitetura de uma Rede-em-Chip A arquitetura de uma NoC define a sua topologia e organização física. Ela opera de acordo com uma série de protocolos que determinam a implementação de seus mecanismos de comunicação e a forma como mensagens são transmitidas pela rede. A escolha de uma arquitetura é realizada para cumprir objetivos de projeto, tais como desempenho, custo em silício, consumo de energia, escalabilidade e confiabilidade (BENINI; DE MICHELI, 2006, p. 23) Topologia Topologia se refere à estrutura de uma rede e sua organização, ela determina as conexões entre os núcleos, roteadores e enlaces. Pode ser classificada de acordo com a forma de conexão dos núcleos, direta ou indireta, e conforme a sua estrutura, regular ou irregular (TATAS et al., 2014, p ). Suas definições são apresentadas a seguir. Redes Diretas e Indiretas Nas redes com topologia direta, cada nodo possui uma conexão direta ponto-a-ponto com um conjunto de outros nodos denominados nodos vizinhos. Um nodo é a integração de um elemento de processamento ou memória, denominado núcleo, com um roteador. Este roteador é conectado com os roteadores dos nodos vizinhos por meio de canais de comunicação. A Figura 1 apresenta dois exemplos de rede com topologia direta (BENINI; DE MICHELI, 2006, p ). Nodo = núcleo + roteador (a) (b) Figura 1. Exemplo de redes com topologia direta: (a) ponto-a-ponto; e (b) malha

20 19 Na topologia indireta, a conexão entre núcleos é realizada por intermédio de uma série de roteadores. Cada núcleo é conectado a um roteador externo, e os roteadores possuem uma conexão ponto-a-ponto com outros roteadores. Nessa topologia, os núcleos não realizam o chaveamento de pacotes e os roteadores não realizam nenhum processamento, seu único objetivo é fornecer um caminho de comunicação. Alguns exemplos são as redes de topologia árvore gorda e butterfly, ilustradas na Figura 2 (PASRICHA; DUTT, 2008, p. 446). = Roteador = Núcleo (a) (b) Figura 2. Exemplo de topologias indiretas: (a) árvore gorda; e (b) butterfly Redes Regulares e Irregulares Uma rede com topologia regular assume uma distribuição homogênea de roteadores, fazendo com que seu custo e tempo de projeto seja menor. As redes regulares são altamente reutilizáveis e requerem poucas mudanças para serem utilizadas para diferentes aplicações. Porém, o uso de redes regulares não é adequado para algumas aplicações devido ao uso não otimizado de toda a rede de interconexão, resultando em baixo desempenho e alto consumo de energia. Para amenizar tais limitações são utilizadas redes com topologia irregular (TATAS et al., 2014, p. 20). As redes irregulares combinam características das topologias diretas e indiretas, bem como de barramentos compartilhados, de modo a otimizar a rede para uma aplicação específica (PASRICHA; DUTT, 2008, p. 447).

21 Chaveamento A técnica de chaveamento define como e quando um canal de entrada de um roteador é conectado a um canal de saída para permitir a transferência de mensagens pela rede. Os dados são transmitidos por mensagens em forma de pacotes decompostos em flits (flow control units), os quais são formados por phits (physical units). A estrutura de uma mensagem é ilustrada na Figura 3 e suas definições são as seguintes: Mensagem: uma série de pacotes que corresponde a uma transferência de dados entre nodos; Pacote: flits consecutivos para um mesmo destino. Roteadores podem armazenar um pacote inteiro antes de enviá-lo ou transferir os flits separadamente; Flit: é a unidade de sincronização entre roteadores. É a unidade na qual as operações de controle de fluxo são realizadas; e Phit: é a unidade que representa a quantidade informação transferida pelos canais físicos entre os roteadores em um único ciclo de relógio. Mensagem Pacote cabeçalho carga útil terminador Flit Phit Figura 3. Estrutura de mensagens, pacotes, flits e phits Fonte: Adaptado de Pasricha e Dutt (2008, p. 449). Diferentes arquiteturas de rede utilizam phits, flits, pacotes e mensagens de diferentes tamanhos, gerando impacto no custo e desempenho da NoC. Os dois principais modos de chaveamento são por circuito e por pacotes, descritos a seguir (TATAS et al., 2014, p ).

22 21 Chaveamento por Circuito No chaveamento por circuito, um caminho físico entre o nodo origem e o nodo destino é reservado antes da transmissão de dados. O caminho (circuito) reservado é constituído de uma série de canais e roteadores, sendo é mantido até que toda a mensagem tenha sido entregue ao nodo receptor. A vantagem dessa abordagem é a total disponibilidade da largura de banda do canal ao circuito, resultando em baixa latência após o seu estabelecimento. Porém, o chaveamento por circuito não possui boa escalabilidade pois, conforme a NoC aumenta de tamanho, diversos canais são ocupados pela duração da transmissão de dados, mesmo quando não há envio de dados, uma vez que o caminho é reservado antes do envio das mensagens (PASRICHA; DUTT, 2008, p. 449). Chaveamento por pacote Na modo de chaveamento por pacote, ao invés de estabelecer um caminho antes de enviar dados, como é feito no chaveamento por circuito, os pacotes percorrem seu caminho de forma independente até o destino, por diferentes roteadores e com diferentes atrasos. No chaveamento por pacote, o tempo de espera inicial para envio de pacotes é zero, seguido por um atraso variável devido à contenção nos roteadores percorridos pelo pacote. São descritas a seguir as três técnicas mais populares de chaveamento por pacote (PASRICHA; DUTT, 2008, p ). Armazena e repassa ou SAF (Store and Foward): nesta técnica, um pacote é enviado para o roteador seguinte apenas quando este já foi completamente recebido pelo roteador anterior. O tamanho do buffer em cada roteador deve ser o suficiente para armazenar um pacote inteiro; Transpasse virtual ou VCT (Virtual Cut Through): esta técnica envia o primeiro flit de um pacote assim que o espaço necessário para um pacote inteiro se torna disponível no próximo roteador. Os outros flits seguem o primeiro sem tempo de espera, porém, se não houver espaço disponível no buffer receptor, nenhum flit é enviado e o pacote inteiro é armazenado; e Wormhole: o espaço necessário no buffer receptor para o encaminhamento de dados é de apenas um flit, ao invés de um pacote inteiro. Desse modo, partes de um pacote são distribuídos entre dois ou mais roteadores.

23 Controle de Fluxo O controle de fluxo determina quando buffers e canais de um roteador são alocados, sua granularidade e como os recursos são compartilhados entre as mensagens que trafegam pela rede. Uma boa política de controle de fluxo permite o compartilhamento efetivo dos recursos, reduzindo a latência e a congestão dos canais da rede (JERGER; PEH, 2009, p. 59). A seguir são descritas algumas técnicas de controle de fluxo utilizadas em NoCs. No controle de fluxo Handshake, o nodo emissor primeiro informa a necessidade de enviar dados por meio de um sinal de validação e o receptor confirma a disponibilidade de espaço em buffer para receber os dados através de um sinal de reconhecimento ou ACK (acknowledgement). O dado então é consumido pelo receptor no próximo ciclo de relógio (ZEFERINO, 2003, p. 127). A Figura 4 ilustra o controle de fluxo baseado em créditos, no qual o emissor mantém um contador com a quantidade de espaço livre no buffer do receptor. Sempre que um flit for enviado pelo emissor, ocupando um espaço livre no buffer, o contador é decrementado. Se o contador chegar a zero, significa que o buffer está cheio e nenhum flit pode ser enviado até que o receptor possua espaço disponível. Quando o receptor encaminha um flit, liberando espaço no buffer, é enviado um crédito para o emissor, incrementando o contador (DALLY; TOWLES, 2004, p. 245). O controle de fluxo baseado em canais virtuais associa diversos buffers a um mesmo canal físico, permitindo que outros pacotes utilizem o canal (DALLY; TOWLES, 2004, p. 239). Um canal virtual é basicamente uma fila separada no roteador, sendo que múltiplas filas podem ser associadas a uma mesma porta de entrada. Desse modo, quando um pacote é bloqueado, outros pacotes podem trafegar pelo canal físico através dos canais virtuais (JERGER; PEH, 2009, p. 65). contador -1 flit buffer 2 +1 crédito Emissor Receptor Figura 4. Controle de fluxo baseado em créditos

24 Roteamento A técnica de roteamento define o caminho percorrido por uma mensagem do nodo fonte ao nodo destino para uma topologia em particular. O roteamento deve balancear a carga dos canais de comunicação e manter o tamanho das rotas o mais curto possível, reduzindo a quantidade de roteadores percorridos e a latência das mensagens (DALLY; TOWLES, 2004, p. 159). Os algoritmos de roteamento podem ser classificados em dois grupos principais: Determinístico: o caminho percorrido pelo pacote da origem ao destino é fixo; Adaptativo: a escolha do caminho é dinâmica, levando em consideração o estado atual da rede; Em relação à implementação, os algoritmos de roteamento podem ser baseados em uma lógica específica ou através de uma tabela, a qual contém as informações de roteamento para todos os caminhos possíveis. Outra característica relacionada ao cálculo do roteamento é a distinção entre roteamento fonte e distribuído. No roteamento fonte, a rota é estabelecida antes de injetar o pacote na rede, geralmente pela interface de rede, enquanto no roteamento distribuído, a rota é determinada por cada roteador enquanto o pacote trafega pela rede (TATAS et al., 2014, p. 58). O algoritmo de roteamento é geralmente responsável por garantir que redes com chaveamento por pacote estejam livres de deadlock. Um deadlock ocorre quando um ou mais pacotes são bloqueados e permanecem assim por tempo indefinido, aguardando um evento que nunca ocorre, como a liberação de um recurso por outro pacote (PASRICHA; DUTT, 2008, p. 453) Arbitragem A arbitragem é responsável por resolver as múltiplas requisições para um único recurso. Sempre que um recurso, como um buffer, canal ou porta de um roteador é compartilhado por muitos agentes, um árbitro é necessário para assegurar o acesso do recurso por um agente por vez. Além disso, os árbitros atuam em conjunto de alocadores quando é necessário o gerenciamento de múltiplas requisições para múltiplos recursos, como no caso de roteadores com canais virtuais (DALLY; TOWLES, 2004, p. 349).

25 24 Existem várias formas de decidir a alocação de um recurso, entre elas pela atribuição de uma prioridade fixa ou aleatória as requisições. Nos árbitros com prioridade fixa, a maior prioridade é sempre atribuída à mesma requisição, enquanto na abordagem randômica, a prioridade é concedida aleatoriamente, independente do estado das requisições. Uma política de arbitragem que procura definir as prioridades das requisições de forma mais equilibrada é a aplicada pelo árbitro round-robin, na qual é adotada uma fila circular em que a última requisição atendida recebe a menor prioridade no próximo ciclo de arbitragem (DALLY; TOWLES, 2004, p ) Memorização A técnica de memorização define a organização dos buffers e influencia na eficiência com que os pacotes utilizam os canais de comunicação da rede. Os buffers são utilizados para armazenar pacotes ou flits quando estes não podem ser enviados diretamente para os canais de saída (JERGER; PEH, 2009, p. 81). As filas de buffer ocupam maior parte da área de silício e consomem maior quantidade de energia em relação aos outros componentes de um roteador. Os circuitos de um buffer podem ser implementados por meio de registradores (flip-flops) ou de células SRAM (BENINI; DE MICHELI, 2006, p. 64). A memória de um roteador pode ser organizada de forma distribuída nas portas do roteador e também de forma centralizada, compartilhada pela portas. Na abordagem distribuída, a memória é dividida em partições alocadas a cada porta do roteador. As partições são implementadas na forma de buffers independentes. Um exemplo de implementação simples e barata é o buffer FIFO (First-In, First-Out), no qual o espaço de memória é fixo e os elementos na memória são lidos na mesma ordem em que são escritos. Na estratégia de memorização compartilhada, um buffer centralizado é responsável por armazenar os pacotes bloqueados em todos os canais de entrada e distribuir dinamicamente o espaço de endereçamento entre eles. Esta abordagem fornece uma melhor utilização do espaço de memória em relação às estratégias em que o espaço é prévia e estaticamente alocado aos canais de entrada. Um problema pode surgir caso a saída requisitada por um pacote esteja em uso e o mesmo continue a enviar dados, enchendo o buffer e afetando outras comunicações. Esse problema pode ser evitado limitando o espaço alocado por cada canal (ZEFERINO, 2003, p ).

26 Métricas de Desempenho Existem diversas maneiras de medir e apresentar o desempenho de uma NoC. Neste trabalho, são adotadas como métricas a vazão e a latência. Vazão Vazão é a quantidade máxima de informação enviada por unidade de tempo. Pode ser definida também como a taxa pela qual os pacotes são enviados pela rede para um padrão de tráfego em particular. É determinada por meio da razão entre a contagem dos pacotes que chegam ao seu destino e o intervalo de tempo para entregar esses pacotes, medido em mensagens por segundo ou mensagens por ciclos de relógio (DUATO; YALAMANCHILI; NI, 2003, p. 477). A vazão, ou tráfego aceito, deve ser contrastada com a demanda, ou tráfego oferecido, a qual é a taxa com que os pacotes são injetados na rede. Um gráfico de exemplo é apresentado na Figura 5(a), no qual a vazão cresce junto com a demanda até atingir o ponto de saturação. Conforme a demanda continua crescendo além deste ponto, a rede não consegue mais entregar pacotes tão rápido quanto eles são criados (DALLY; TOWLES, 2004, p. 452). Latência A latência é o tempo necessário para um pacote atravessar a rede da sua origem até seu destino. Se for considerada apenas a rede, a latência é o tempo gasto a partir do momento que o cabeçalho de um pacote é injetado no nodo de origem, até o momento em que a última unidade de informação é recebida pelo nodo destino. Se forem consideradas as filas de injeção, o tempo de permanência na fila é adicionada na latência, que geralmente negligenciável, exceto quando a rede está perto do seu ponto de saturação (DUATO; YALAMANCHILI; NI, 2003, p. 476). O gráfico de exemplo da Figura 5(b) apresenta a comparação entre a latência média em ciclos e a demanda (tráfego oferecido). Conforme o tráfego aumenta, a contenção na rede também aumenta, fazendo com que a latência suba, pois os pacotes devem esperar pela liberação de buffers e canais (DALLY; TOWLES, 2004, p. 455).

27 26 Figura 5. Exemplo de gráficos: (a) vazão; (b) latência média Fonte: Adaptado de Dally e Towles (2004, p ) Qualidade de Serviço Qualidade de serviço ou QoS (Quality-of-Service) em NoCs refere-se ao nível de compromisso de entrega de pacotes. Tal compromisso pode ser na forma da integridade de transferências, conclusão de transações ou limites sobre o desempenho. Na maior parte dos casos, QoS refere-se à largura de banda, atrasos e variações no tempo de entrega de pacotes sucessivos e a flutuação da latência (jitter), uma vez que a integridade e conclusão de transferências são geralmente os requisitos básicos para comunicações em sistemas integrados. A integridade de transferências se preocupa em garantir o conteúdo e ordenação dos pacotes, enquanto a conclusão de transações garante que um pacote não seja descartado ou perdido durante o seu deslocamento do nodo de origem até o nodo destino (PASRICHA; DUTT, 2008, p. 459) Classes de Serviço Em algumas aplicações de redes de interconexão, é útil dividir o tráfego da rede em um número de classes para gerenciar de forma eficiente a alocação de recursos para os pacotes. Diferentes classes de pacote podem possuir diferentes requisitos, como não tolerar perda de pacotes ou ser sensível à latência. As classes também podem possuir diferentes níveis de prioridade, variando conforme a importância dos pacotes para o funcionamento do sistema.

28 27 A alocação de recursos baseada em classes permite priorizar os serviços, de modo que as classes mais importantes possuem um nível de prioridade maior. Desse modo, a alocação de recursos pode dar conta das necessidades específicas de cada classe de pacotes. Com serviços priorizados, o pacote de uma determinada classe possui prioridade na alocação de buffers e canais em relação a pacotes de classes inferiores, ou a classe recebe uma fração maior dos recursos disponíveis. Também é possível tornar a alocação de recursos adaptável para que, desse modo, pacotes que pertencem a uma classe que requer baixa latência podem avançar a frente de pacotes que não possuem esse requisito. Conhecer a prioridade e requisitos de cada classe permite alocar recursos de forma mais eficiente do que se todos os pacotes recebessem exatamente o mesmo tratamento (DALLY; TOWLES, 2004, p ). Em NoCs, as abordagens típicas para a implementação de QoS são divididas em duas classes, melhor esforço e serviço garantido, apresentados nas subseções a seguir. Melhor Esforço A classe de serviço melhor esforço (do inglês, Best-Effort ou BE) não realiza a reserva de nenhum recurso e não fornece garantias temporais, podendo sofrer atrasos na entrega de pacotes. Essa abordagem requer poucos recursos, resultando em uma utilização eficiente da rede uma vez que é tipicamente projetada para cenários de caso médio e não para cenários de pior caso. Sua limitação reside na sua imprevisibilidade e, por este motivo, a classe de serviço de melhor esforço é utilizada para transportar dados de aplicações de tempo não real (TATAS et al., 2014, p. 70). Serviço Garantido NoCs com garantia de serviço (do inglês, Guaranteed Service ou GS) tomam medidas em suas arquiteturas para oferecer conexões com desempenho garantido, como a ausência de perda de dados, vazão mínima, e latência máxima. Esse nível é indicado para aplicações de tempo real (discutida adiante na Seção 2.2), que não toleram a perda de pacotes e necessitam de garantias absolutas sobre o cumprimento de prazos. No serviço garantido, é necessária a reserva de recursos para os cenários de pior caso, o que aumenta o custo da rede. Para garantir a vazão de um fluxo, parte da largura de banda é reservada para sua vazão máxima, mesmo em situações que a vazão média é muito menor. Com isso, os recursos da rede são geralmente subutilizados (PETERSON; DAVIE, 2007, p. 506; TATAS et al., 2014, p. 70).

29 Rede SoCIN A rede SoCIN é uma NoC parametrizável desenvolvida por Zeferino (2003) com o objetivo de fornecer soluções de baixo custo para sistemas integrados. Ela é uma rede direta com topologia em malha 2-D e possui como bloco de construção básico o roteador ParIS (Parameterizable Interconnect Switch). Os roteadores podem possuir de duas a quatro portas, chamadas N (North), E (East), S (South) e W (West), para se conectar aos roteadores vizinhos e uma porta L (Local) que se conecta a um núcleo ou subsistema. Os roteadores na rede são identificados por um par de coordenadas (x, y), conforme ilustra a Figura 6 (ZEFERINO; SANTO; SUSIN, 2004). Y 3 0,3 1,3 2,3 3,3 N L 2 0,2 1,2 2,2 3,2 W x,y E S 1 0,1 1,1 2,1 3,1 0 0,0 1,0 2,0 3, X Figura 6. Sistema de coordenadas da Rede SoCIN Fonte: Adaptado de Zeferino, Santo e Susin (2004). Os enlaces da SoCIN são compostos de dois canais opostos unidirecionais ilustrados na Figura 7(a). Cada enlace possui n bits para o envio de dados e 2 bits para o enquadramento de pacotes representados por bop (begin-of-packet) e eop (end-of-packet). Os sinais val e ret são utilizados no controle de fluxo, conforme o algoritmo utilizado. A rede utiliza chaveamento por pacotes do tipo wormhole e cada flit possui n+2 bits, onde n é a largura do canal de dados e os 2 bits adicionais são utilizados para identificar o início (bop) e o fim (eop) de um pacote, ilustrado na Figura 7(b). O primeiro flit de um pacote é o cabeçalho (header), identificado pelo bit bop igual a 1. O cabeçalho é composto de um campo chamado RIB (Routing Information Bits) que contém as coordenadas XY

30 29 (Coluna, Linha) do nodo destino, utilizadas pelo roteador para encaminhar o pacote em direção ao seu destinatário. O campo HLP (Higher Level Protocol) é apenas um espaço reservado para a implementação de protocolos de mais alto nível. Os demais flits são a carga útil (payload) e o terminador (trailer) do pacote, identificado pelo bit eop quando seu valor é igual a 1 (ibidem). n+2 n dados bop eop bop eop 0 1 n bits m bits HLP RIB.x RIB.y n+2 val ret Carga útil Último flit (terminador) ilimitado (a) (b) Figura 7. Rede SoCIN: (a) enlace; (b) formato do pacote Fonte: Adaptado de Zeferino, Santo e Susin (2004) Roteador ParIS O roteador ParIS é um soft-core descrito em VHDL (Very High Speed Integrated Circuit HDL) que permite o uso de diferentes técnicas ou implementações para os mecanismos de comunicação da rede. Conforme citado, o roteador possui 5 portas de comunicação denominadas N, S, E, W e L, esta última utilizada para conectar um núcleo à rede e as demais são utilizadas para a conexão com os roteadores vizinhos. Conforme a posição de um roteador na rede, nem todas as portas são necessária, assim os circuitos de entrada e saída associados com as portas desnecessárias não são sintetizados. Cada porta de comunicação do roteador ParIS possui doi módulos, um de entrada (in) e outro de saída (out). Por exemplo, a porta L (Local) é composta dos módulos chamados Lin (canal de entrada) e Lout (canal de saída). Conforme ilustrado pela Figura 8, os módulos de cada porta são interconectados por uma matriz de conexão, Cross Point Matrix (CPM), que varia conforme o algoritmo de roteamento (ZEFERINO; SANTO; SUSIN, 2004).

31 30 Din Dout val ret L in L out val ret CPM Din val ret W in W out Dout val ret Figura 8. Módulos de cada porta de um roteador interconectados por uma matriz de conexões Fonte: Adaptado de Zeferino, Santo e Susin (2004). Os módulos do roteador ParIS são apresentados com detalhes na Figura 9: (a) módulo de entrada; e (b) módulo de saída. Os blocos IFC (Input Flow Control) e OFC (Output Flow Control) são responsáveis pelo controle de fluxo, sendo que as técnicas disponíveis pelo roteador são handshake e baseado em créditos. A arbitragem é realizada pelo bloco OC (Output Control) e pode utilizar a política de prioridades fixas ou dinâmicas (randômica, rotativa ou round-robin). A memorização é realizada por buffers FIFO e o roteador fornece duas implementações: Deslocamento e Circular. Na técnica de deslocamento, o flit é sempre escrito na primeira posição do FIFO, a qual é conectada à interface de entrada do buffer, e os flits previamente armazenados são deslocados a cada novo flit recebido pelo buffer. Na segunda abordagem, não há deslocamento de flits dentro do registrador e a escrita pode ser realizada em qualquer posição. O roteador ParIS possui chaves que implementam um crossbar distribuído. Elas realizam a interconexão dos sinais de dado e de controle de fluxo interno dos canais de entrada e saída em resposta aos sinais de permissão (grant) emitidos pelos blocos OC. As três chaves são: ODS (Output Data Switch), OWS (Output Write Switch) e IRS (Input Read Switch). Por último o bloco IC (Input Control) executa o algoritmo de roteamento, selecionando um canal de saída para um canal de entrada. O algoritmo de roteamento pode ser escolhido entre XY (determinístico) e West-First (parcialmente adaptativo). No roteamento XY, o pacote deve primeiro se deslocar no eixo X e depois no eixo Y, deste modo os canais de entrada no eixo Y, Nin e Sin, não podem requisitar canais de saída no eixo X, Eout e Wout. O algoritmo West-First também possui restrições, o pacote deve primeiro se deslocar na direção X caso o seu destinatário esteja ao oeste. Caso contrário, ele pode ser

32 31 encaminhado tanto na direção X como na direção Y, adaptativamente (ZEFERINO; SANTO; SUSIN, 2004). input IC req[ ] idle[ ] req[ ] idle gnt[ ] OC output din val ret IFC din wr wok FIFO dout rok rd I R S rok wok[ ] rok[ ] O DS O W S din wr wok FIFO dout rok rd OFC dout val ret wok (a) (b) Figura 9. Estrutura interna dos módulos do roteador ParIS: (a) entrada; (b) saída Fonte: Adaptado de Zeferino, Santo e Susin (2004) SoCIN-Q A rede SoCIN fornece apenas serviços de melhor esforço, ou seja, não existe garantias de largura de banda ou latência. Berejuck e Zeferino (2009) desenvolveram uma nova versão da rede, denominada SoCIN-Q, com qualidade de serviço. Foram adicionadas a SoCIN-Q três técnicas de QoS: chaveamento por circuito, canais virtuais e escalonamento por envelhecimento de pacotes. O chaveamento por circuito foi implementado com o objetivo de minimizar a flutuação da latência (jitter). Nesta abordagem, pacotes de controle são utilizados para alocar ou liberar um circuito. Foi adicionado um novo campo de 2 bits (do bit 17 ao 16), chamado CMD, no cabeçalho do pacote. O campo CMD define o tipo do pacote: dados, alocação de circuito, liberação de circuito e concessão de canal. Para implementar o chaveamento por circuito, foram realizadas pequenas modificações na arquitetura interna do bloco Xin do roteador ParIS. A rede SoCIN-Q utiliza duas classes gerais de tráfego para fornecer diferenciação de serviços: Real-Time (RT) e non-real-time (nrt), e cada classe está dividida em duas subclasses, resultando em quatro classes: RT0, RT1, nrt0 e nrt1. No cabeçalho do pacote, foi adicionado um campo de 2 bits (do bit 19 ao 18), chamado CLS, para a identificação das classes de pacote (BEREJUCK; ZEFERINO, 2009).

33 32 A rede SoCIN-Q possui dois canais virtuais, um para fluxos RT e outro para fluxos nrt. A implementação dos canais virtuais foi realizada por meio da replicação dos módulos Xin e Xout do roteador ParIS. O módulo Xin2VC é composto de dois blocos Xin, enquanto o módulo Xout2VC é composto de dois blocos Xout. Quando um pacote é recebido pelo modulo Xin2VC, ele é encaminhado para o bloco XinRT ou XinnRT, dependendo da sua classe, conforme ilustrado na Figura 10 (a). No módulo de saída, ilustrado na Figura 10 (b), quando existem pacotes em ambos XoutRT e XoutnRT, o primeiro sempre irá preemptar o segundo, pois fluxos RT possuem prioridade sobre fluxos nrt. Para permitir a diferenciação entre fluxos de subclasses de uma determinada classe, é usado um esquema de prioridades fixas que privilegia os fluxos das subclasses 0 (RT0 e nrt0) em detrimento de fluxos das subclasses 1 (RT1 e nrt1, respectivamente). Já quando fluxos da mesma subclasse concorrem pelo mesmo recurso, é usado um nível adicional de arbitragem baseada em um política de prioridades dinâmicas do tipo round-robin. Adicionalmente a rede SoCIN-Q disponibiliza uma técnica de escalonamento por envelhecimento de pacotes. Nessa técnica, o tempo que um pacote permanece na rede é levado em consideração no momento da arbitragem, de forma que os pacotes há mais tempo na rede possuem maior prioridade que novos pacotes de uma mesma classe. Deste modo, é possível reduzir a latência e aumentar a taxa de cumprimento de prazos. Para implementar essa técnica, foi adicionado um campo de 3 bits (do bit 22 ao 20), no cabeçalho do pacote. Este campo é chamado AGE e é atualizado por um circuito stampler, adicionado no XinRT, sempre que um pacote está aguardando pela liberação de um canal de saída. A arbitragem do roteador ParIS foi substituída por um novo árbitro que escalona pacotes baseado nas classes de serviço e no envelhecimento de pacotes para priorizar. A Figura 10 (c) apresenta o novo formato de pacote da rede com os campos adicionados para as técnicas de QoS.

34 33 Figura 10. SoCIN-Q: (a) módulo de entrada; (b) módulo de saída; (c) formato do pacote Fonte: Adaptado de Berejuck e Zeferino (2009) Simulador da Rede SoCIN A primeira versão do simulador da rede SoCIN, denominado BrownPepper, permite a avaliação de desempenho da rede sob diferentes configurações e padrões de tráfego. A NoC é descrita em modelos SystemC no nível de transferência entre registradores (RTL Register-Transfer Level) com precisão de ciclos (BRUCH; PIZZONI; ZEFERINO, 2009). O simulador conta com geradores e medidores de tráfego, desenvolvidos por Zeferino et al. (2007), além do modelo da própria rede. A Figura 11 apresenta um exemplo de sistema criado com o simulador BrownPepper. Cada roteador da rede possui dois módulos acoplados à sua porta local: um gerador de tráfego, representados pelo bloco TG (Traffic Generator), e um medidor de tráfego, representador pelo bloco TM (Traffic Metter). Os geradores de tráfego enviam e recebem pacotes de acordo com o padrão de tráfego estabelecido (BRUCH; PIZZONI; ZEFERINO, 2009). O simulador permite o uso do modelo da SoCIN-Q, bem como atribuir níveis de prioridade (RT0, RT1, nrt0 e nrt1) a cada padrão de tráfego e definir características como deadline, tamanho da mensagem, taxa de injeção etc. A última versão do simulador, implementada por Silva (2014), é denominada RedScarf e, além de possuir todas as funcionalidade do simulador BrownPepper, possui suporte multiplataforma e execuções multithread.

35 34 x,y = ParIS = TG 0.2 1,2 2,2 = TM 0,1 1,1 2,1 0,0 1,0 2,0 Figura 11. Exemplo de sistema criado com o simulador BrownPepper Fonte: Adaptado de Zeferino et al. (2007). 2.2 SISTEMAS DE TEMPO REAL Os sistemas que necessitam responder a uma requisição de serviço dentro de um período restrito de tempo são denominados sistemas de tempo real ou RT (Real-Time). Para um sistema RT, cada requisição de serviço impõe uma tarefa tipicamente associada com características temporais. Essas características são normalmente relacionadas ao período máximo de tempo para a execução da tarefa, o qual é denominado prazo ou deadline. Dependendo da consequência da perda do prazo de uma tarefa, um requisito temporal pode ser classificado como brando (soft) ou crítico (hard) (LI; YAO, 2003, p. 14). Nos requisitos temporais brandos, as consequências de um atraso não são desejadas mas são toleradas. Uma resposta atrasada ainda pode ser útil dentro de um certo nível de tolerância. Um sistema RT soft oferece serviços de melhor esforço, o que pode ocasionalmente perder prazos. A perda de um deadline não é catastrófica para o sistema, porém a utilidade do resultado pode diminuir conforme o atraso, assim como a qualidade de serviço do sistema. As características temporais de um sistema RT soft são geralmente expressas em termos probabilísticos ou estatísticos, como latência média e desvio padrão. Nos requisitos temporais críticos, os atrasos no tempo de resposta são inaceitáveis e geram consequências graves para o sistema Os sistemas RT hard oferecem garantia de serviço, não tolerando a perda de prazos. Desse modo, o funcionamento correto de um sistema de tempo real depende de dois fatores: garantia funcional e garantia temporal. Um sistema com garantia temporal significa que

36 35 o serviço de uma requisição será completado dentro do prazo. Na maior parte dos casos, a garantia temporal é mais importante que a funcional, pois as funcionalidades de um sistema são dependentes do atendimento dos requisitos temporais. Como a violação de prazos é inaceitável, o projetista deve verificar rigorosamente se o sistema RT consegue atender os requisitos temporais críticos. Na literatura, as técnicas para validação de um sistema RT incluem: simulação exaustiva, teste de desempenho combinacional e análise de escalonabilidade. Esta última é descrita adiante na Seção pois é foco deste trabalho. As características de um sistema RT hard são tipicamente expressas por termos determinísticos (e.g. latência máxima, tempo de execução máximo). Os sistemas atuais podem possuir ambos requisitos temporais, crítico e brando. Um sistema que possui apenas tarefas com prazos do tipo brando é considerado um sistema RT soft. Um sistema é RT hard se pelo menos uma tarefa possui requisitos temporais críticos (FAN, 2015, p. 5-6) Tarefas de Tempo Real Um sistema de tempo real pode possuir múltiplas tarefas, cada uma representando uma unidade de concorrência. Uma tarefa pode ser um bloco de instruções ou ações a serem executadas por um processador para um propósito específico. Cada tarefa pode ser executada múltiplas vezes e cada execução é denominada como uma instância de uma tarefa ou job. Desse modo, uma tarefa pode ser tratada como um fluxo de jobs. As tarefas de tempo real executadas múltiplas vezes podem ser classificadas nas seguintes categorias (FAN, 2015, p. 304; CHENG, 2002, p. 42): Tarefas periódicas: são as tarefas em que o intervalo de tempo, período, entre jobs consecutivos é constante (ou muito próximo disso); Tarefas esporádicas: o intervalo de tempo entre jobs consecutivos varia amplamente, sendo que os jobs podem ser emitidos em rajadas. Uma tarefa esporádica é executada em resposta a eventos que podem ocorrer aleatoriamente, tornando difícil caracterizála por meio de simples funções de distribuição de probabilidade; e Tarefas aperiódicas: é um fluxo em que o intervalo de tempo entre jobs consecutivos segue uma função de distribuição de probabilidade conhecida. As tarefas periódicas e esporádicas possuem restrições temporais críticas ou brandas, enquanto as tarefas aperiódicas possuem restrições brandas ou não possuem prazos. Em ordem de

37 36 importância, as tarefas com restrições temporais críticas sempre serão mais prioritárias que as tarefas brandas, sendo as periódicas de maior prioridade que as esporádicas. As tarefas aperiódicas possuem a menor prioridade. Uma tarefa Ti é especificada por uma tupla (pi, ri, ei, di), onde (FAN, 2015, p. 306): pi: é o período, o intervalo de tempo entre jobs consecutivos; ri: tempo de chegada ou tempo de início; ei: tempo máximo de execução; e di: deadline relativo, o prazo máximo em que o job em execução deve ser concluído Tempo de Resposta de Pior Caso O desempenho de um sistema RT é geralmente expresso em termos de tempo de resposta, isto é, o tempo necessário para finalizar a execução de um job a partir do seu tempo de início. O tempo de resposta depende do tempo de execução e de como os jobs são escalonados pelo sistema (FAN, 2015, p. 309). Um exemplo de escalonamento com três tarefas periódicas especificadas por Ti (pi, ei) é mostrado na Figura 12. No exemplo, todas as tarefas iniciam no tempo 0, o qual é denominado como o instante crítico. Cada instância (job) de uma tarefa é representada por Ji,n, onde i identifica a tarefa que gerou a instância e n a sua numeração. Por ordem de prioridade, as tarefas do sistema são: T1 (6, 2), T2 (12, 3) e T3 (18, 4). Todas as instâncias da tarefa T1 (J1,1, J1,2, J1,3 e J1,4) são escalonadas imediatamente quando são iniciadas e seu pior tempo de execução é sempre de 2 unidades de tempo. As instâncias da tarefa T2 (J2,1 e J2,2) são iniciadas a cada 12 unidades de tempo e seu pior tempo de execução é de 3 unidades de tempo. Como são escalonadas sempre após as instâncias da tarefa T1, o pior tempo de resposta para J2, n é de 5 unidades de tempo (e1 + e2). No caso da tarefa T3, a sua primeira instância J3,1 é iniciada no tempo 0, escalonada para ser executado no tempo 5 e interrompida por J1,2 no tempo 6. Sua execução é retomada no tempo 8 e finalizada no tempo 11. Dessa forma, o seu tempo de resposta é de 11 unidades de tempo (iniciou no tempo 0 e terminou no tempo 11). A segunda instância J3,2 é iniciada no tempo 18 (conforme período definido na tupla), escalonada para ser executada no tempo 20 e finalizada no tempo 24. Nesse caso,

38 37 o tempo de resposta é = 6 unidades de tempo. Para este exemplo, o tempo de resposta de pior caso para a tarefa T3 é de 11 unidades de tempo. T 3 (18, 4) T 2 (12, 3) T 1 (6, 2) J 1,1 J J 3,1 2,1 J 3,1 J 1,2 J 1,3 J J 3,2 2,2 J 1, Tempo Figura 12. Exemplo de escalonamento para avaliação do pior tempo de resposta de uma tarefa Fonte: Adaptado de Fan (2015, p. 309) Escalonamento de Tarefas Um sistema RT hard deve executar um conjunto de tarefas concorrentes de modo que todas as tarefas que possuem requisitos temporais críticos cumpram os seus respectivos prazos. Cada tarefa necessita de recursos para progredir e o escalonamento de tarefas se preocupa justamente com a alocação de recursos para satisfazer todos os requisitos temporais. A Figura 6 apresenta as classificações dos algoritmos de escalonamento de tempo real. Um escalonador é denominado estático se suas decisões não são tomadas em tempo de execução, ou seja, são pré-determinadas, e o comportamento do sistema é determinístico. Em um escalonamento dinâmico, as decisões são tomadas em tempo de execução, o que torna essa abordagem flexível e adaptável em um cenário evolutivo. O esforço para realizar o escalonamento pode levar uma quantidade de tempo significativa e o comportamento do sistema é não-determinístico. No escalonamento não-preemptivo, uma tarefa em execução não pode ser interrompida até que a mesma seja concluída e libere os recursos alocados. Este tipo de escalonamento é razoável em um cenário onde muitas tarefas curtas devem ser executadas. Na abordagem preemptiva, a tarefa atualmente em execução pode ser interrompida para dar lugar à requisição de uma tarefa mais urgente (KOPETZ, 2011, p. 240).

39 38 Escalonamento RT Brando Crítico Dinâmico Estático Preemptivo Não-preemptivo Preemptivo Não-preemptivo Figura 13. Classificação dos algoritmos de escalonamento de tarefas RT Fonte: Adaptado de Kopetz (2011, p. 240) Escalonadores de Prioridade Estática Nos algoritmos de escalonamento estático, um conjunto de tarefas é escalonado offline, pois todas as prioridades já estão definidas antes da execução do sistema. O algoritmo deve garantir todos os prazos considerando os recursos, precedências e requisitos de sincronização de todas as tarefas (KOPETZ, 2015, p. 248). Uma estratégia popular de escalonamento é o algoritmo RM (Rate- Monotonic), o qual utiliza o período das tarefas para determinar as prioridades. O escalonamento RM executa a instância disponível da tarefa com o menor período primeiro. Se duas ou mais tarefas possuem o mesmo período, o algoritmo escolhe aleatoriamente uma delas (LIU; LAYLAND, 1973). O resultado do escalonamento das tarefas apresentadas na Tabela 1, utilizando o algoritmo RM, é apresentado na Figura 14 na forma de um diagrama. As setas indicam a chegada de instâncias de uma tarefa Ti. No tempo 0, a única instância disponível para execução é a da tarefa T1. A primeira instância da tarefa T2 chega no tempo 1. Como p1 > p2, T1 é interrompido e T2 inicia a sua execução pois tem período menor. No tempo 2, T2 termina sua execução e chega uma instância de T3. Como p3 > p1, agora T1 possui a maior prioridade e sua execução é retomada. No tempo 3, T1 termina sua execução e, como não existe nenhuma outra instância disponível, T3 inicia sua execução, a qual termina no tempo 5. Neste tempo, as segundas instâncias de T1 e T2 estão disponíveis e T2 inicia a sua execução pois p1 > p2. No tempo 6, T2 é finalizado e T1 inicia sua execução, finalizada no tempo 8. É possível observar que apenas as instâncias da tarefa T2 são escalonadas imediatamente após a sua chegada. Isso ocorre devido a esta tarefa possuir o menor período, ou seja, a maior prioridade.

40 39 Tabela 1. Tarefas periódicas para o escalonamento RM Características Tarefa (Ti) T1 T2 T3 Período (p) Tempo de chegada (r) Tempo de execução (e) Deadline relativo (d) Tarefas T 1 T 2 T Tempo Figura 14. Diagrama de um escalonamento RM Fonte: Adaptado de Cheng (2002, p. 45). Outro escalonador de prioridade fixa é o algoritmo Deadline-Monotonic (DM), o qual atribui a maior prioridade às tarefas com o menor deadline relativo. Caso o período de cada tarefa seja igual ao seu respectivo prazo, então os algoritmos RM e DM são equivalentes (LEUNG; WHITEHEAD, 1982) Escalonadores de Prioridade Dinâmica Nos algoritmos de escalonamento dinâmico, as decisões para escalonar um conjunto de tarefas são tomadas em tempo de execução, ou seja, online. O escalonamento EDF (Earliest-Deadline-First) é um algoritmo online ideal, no qual as tarefas com menor deadline absoluto (Di) possuem a maior prioridade. O deadline absoluto de uma tarefa é a soma do deadline relativo com o seu tempo de chegada. Se mais de uma tarefa possuir o mesmo deadline absoluto, o algoritmo escolhe aleatoriamente entre elas (CHENG, 2002, p. 44). A Figura 15(a) ilustra o resultado de um escalonamento FIFO em que as tarefas, descritas na Tabela 2, são executas pela ordem de chegada, desconsiderando-se os requisitos temporais. Este

41 40 escalonamento é inadequado e, como resultado, a tarefa T3 perde seu prazo depois do tempo 9, e T4 tem seu deadline expirando no tempo 8, antes mesmo de ser executada. Utilizando o algoritmo EDF, é possível produzir um escalonamento adequado para as tarefas da Tabela 2, conforme ilustrado na Figura 15(b). No tempo 0, T1 e T2 estão disponíveis para execução. Como D1 > D2, T2 possui recebe maior a prioridade e é executada. No tempo 2, a tarefa T3 se torna disponível e, como D3 < D2, T2 é interrompido e T3 inicia sua execução. No tempo 5, T3 é interrompido para executar a tarefa T4, pois D4 < D3. No tempo 7, T4 termina sua execução dentro do prazo, e como D3 < D2 < D1, T3 continua sua execução, finalizando no tempo 9, exatamente em seu deadline. Neste momento, T2 possui a maior prioridade e retoma sua execução, vindo a terminar no tempo 10. Após, a tarefa T1 é iniciada e, então, finalizada no tempo 14. Tabela 2. Tarefas para o escalonamento FIFO e EDF Características Tarefa (Ti) T1 T2 T3 T4 Tempo de chegada (r) Tempo de execução (e) Deadline relativo (d) Deadline absoluto (D) T 1 T 2 T 3 T (a) Tempo T 2 T 3 T 4 T3 T 2 Tempo (b) T 1 Figura 15. Diagramas de escalonamento: (a) FIFO; (b) EDF Fonte: Adaptado de Cheng (2002, p ).

42 Análise de Escalonabilidade A análise de escalonabilidade é uma técnica que permite determinar se um conjunto específico de tarefas pode ser escalonado de modo cada tarefa seja concluída dentro do seu prazo utilizando um algoritmo de escalonamento (CHENG, 2002, p. 41). Um teste de escalonabilidade pode ser classificado como necessário ou suficiente. Em um teste necessário, um conjunto de tarefas é definitivamente não escalonável se o resultado for negativo. Se o resultado for positivo, ainda existe a possibilidade do conjunto não ser escalonável. No teste suficiente, um resultado positivo indica que um conjunto de tarefas é definitivamente escalonável. Um conjunto de tarefas escalonáveis pode obter um resultado negativo em um teste suficiente (KOPETZ, 2011, p ). As subseções a seguir apresentam testes de escalonabilidade adotados em conjunto dos algoritmos RM, DM e EDF. Teste Baseado na Utilização Para um conjunto de tarefas periódicas, preemptivas e independentes, cujo o deadline de cada tarefa é o respectivo tempo de início de uma nova instância, isto é, se di = pi, um teste de escalonabilidade suficiente, mas não necessário, determina que a soma do fator de utilização de n tarefas (1), deve ser menor ou igual ao menor limite superior de utilização do processador (2), ou seja, U UMLS. Esse teste é valido para escalonamentos utilizando o algoritmo RM (LIU; LAYLAND, 1973). Utilizando o algoritmo EDF, o teste de escalonabilidade é mais simples. O valor do limite superior UMLS é igual à quantidade de processadores, sendo 1 no caso de um sistema monoprocessado (CHENG, 2002, p. 52). n U = e i p i i=1 (1) U MLS = n(2 1 n 1) (2) Com o algoritmo DM, é necessário substituir pi por di em (1). Neste caso, o teste continua válido se di pi. Entretanto, o teste baseado na utilização é muito pessimista, pois a carga de trabalho sobre o processador é superestimada (BUTAZZO, 2011, p. 104).

43 42 Teste Baseado na Interferência O teste baseado na interferência é classificado como necessário e é menos pessimista que o teste baseado na utilização para o algoritmo DM. São assumidas as seguintes condições: O cenário de pior caso ocorre quando todas as tarefas são iniciadas simultaneamente; Para cada tarefa Ti, a soma do seu tempo de processamento e do tempo de interferência imposto pelas tarefas de maior prioridade deve ser menor ou igual a di. A interferência I1 de uma tarefa Ti é calculada pelo somatório do tempo de execução de todas as tarefas de maior prioridade iniciadas antes de di, conforme (3) (AUDSLEY et al., 1992). i 1 I i = d i c p j j j=1 (3) Teste Baseado no Tempo de Resposta Audsley et al. (1993) propuseram um método eficiente para avaliação da interferência exata sobre tarefas periódicas e criaram um teste de escalonabilidade suficiente e necessário para escalonamentos estáticos, o qual é chamado análise de tempo de resposta. De acordo com este método, o tempo de resposta Ri mais longo de uma tarefa periódica Ti é calculado, no cenário de pior caso, como a soma do tempo de execução da interferência Ii das tarefas com maior prioridade. Para cada tarefa Ti, começando pela tarefa de maior prioridade, é calculado o tempo de resposta Ri e a interferência Ii, conforme (4) e (5). Se Ri for menor que di, a tarefa é escalonável. R i = c i + I i (4) i 1 I i = R i c p j j j=1 (5)

44 CONSIDERAÇÕES Este capítulo apresentou a base teórica necessária para o entendimento do contexto em que o presente trabalho está inserido. A seção inicial discutiu as motivações para o desenvolvimento de NoCs. Em seguida, foram apresentados os mecanismos de comunicação que fazem parte de uma Rede-em-Chip, as métricas para a avaliação de desempenho, conceitos de qualidade de serviço. Foram apresentadas as arquiteturas da rede SoCIN e SoCIN-Q, utilizada como NoC de referência neste trabalho. Após isso, o capítulo abordou conceitos sobre sistemas de tempo real. Foram apresentadas técnicas de escalonamento estático e dinâmico e a análise de escalonabilidade necessária para garantir o cumprimento de prazos. No capítulo a seguir, são apresentados os trabalhos que aplicaram a análise de escalonabilidade em redes-em-chip. Os conceitos apresentados sobre NoCs e sistemas de tempo real, auxiliaram na identificação das características consideradas na análise de escalonabilidade dos trabalhos analisados. Os testes de escalonabilidade apresentados foram utilizados como base para o desenvolvimentos dos modelos desta dissertação.

45 44 3 TRABALHOS RELACIONADOS Este capítulo apresenta alguns dos trabalhos mais recentes sobre a predição do desempenho de pior caso utilizando a análise de escalonabilidade em redes-em-chip, os quais são descritos a seguir quanto às técnicas propostas e os resultados alcançados. Os artigos descritos foram selecionados conforme seu ano de publicação, considerando apenas o período de 2010 a 2017, e sua relevância. Os detalhes da revisão sistemática utilizada é apresentada no Apêndice A e uma análise comparativa dos trabalhos é apresentada na seção final deste capítulo. No trabalho realizado por Shi, Burns e Indrusiak (2010), da Universidade de York Reino Unido, é apresentada uma análise de escalonabilidade para comunicações de tempo real em redesem-chip com chaveamento do tipo wormhole, arbitragem baseada em níveis de prioridades e roteamento determinístico. Tal abordagem avalia os diversos relacionamentos e atributos entre tráfegos e gera uma estimativa da latência da transmissão de pacotes para um dado fluxo baseado nas interferências de tarefas de maior prioridade, direta ou indiretamente, e de auto-bloqueios. Segundo os autores, uma interferência direta (Figura 16.a) é quando um fluxo de tráfego possui enlaces físicos em comum com outro fluxo. A interferência indireta (Figura 16.b) por sua vez é gerada por dois fluxos que não compartilham nenhum enlace, porém com um ou mais fluxos de interferência em comum entre os dois. Os auto-bloqueios ocorrem quando um pacote precisa esperar a transmissão do pacote anterior do mesmo fluxo, gerando um bloqueio. Para validar a análise, foi comparado os seus resultados de latência máxima com os obtidos por meio de um modelo de simulação, em nível de flits, da NoC de referência sob a carga de comunicação de uma aplicação realista. A aplicação escolhida foi o controle de um veículo autônomo, pois este possui grandes volumes de dados e troca de mensagens de controle. As tarefas dessa aplicação foram mapeadas em 16 processadores conectados por uma rede 4 4. Os resultados demonstraram proximidade com as simulações, tornando a análise propícia para uma avaliação do impacto da latência das comunicações durante o desenvolvimento da aplicação na fases iniciais do projeto.

46 45 J 3 J 2 J 1 J 2 J (a) (b) Figura 16. Interferências: (a) direta; (b) indireta Fonte: Adaptado de Shi, Burns e Indrusiak (2010). Diemer et al. (2011), da Universidade Técnica de Braunschweig Alemanha, também apresentam uma análise de escalonabilidade para comunicações de tempo real em redes-em-chip com chaveamento do tipo wormhole, porém utilizando um esquema de arbitragem round-robin com múltiplos estágios. A abordagem proposta considera os padrões de tráfego como eventos de chegada, em nível de flits, e os caracteriza por meio de funções arbitrárias de pior caso que determinam o número máximo e mínimo de flits injetados na rede em um determinado intervalo de tempo. Os autores também assumiram que buffers de canais virtuais são alocados estaticamente para os fluxos que demandam qualidade de serviço, e são sempre de tamanho suficiente, de modo que um fluxo não pode ser impedido de ser injetado na rede por falta de buffers. Para validar a abordagem foi implementado um modelo do roteador em SystemC com um ciclo de tempo de flit, 4 ciclos de atraso por pacote e 5 ciclos para gerar ou consumir um pacote. A simulação foi gerada para uma rede em malha 3x3 com 3 fluxos injetando pacotes periodicamente. Os resultados de latência estimados ficaram com um erro máximo de 32% acima do pior caso. No trabalho de Imai e Yoneda (2012), da Universidade de Hirosaki Japão, são propostos modelos analíticos para estimar o desempenho de pior caso de uma NoC. Os autores optaram por utilizar a topologia de malha 2D, com arbitragem round-robin e dois algoritmos de roteamento, um determinístico (XY) e um adaptativo (negative-first). Outra consideração foi a de não utilizar canais virtuais e fixar a quantidade de buffers em 3 para gerar situações de pior caso. Durante a elaboração dos modelos analíticos foram considerados os conflitos (interferências diretas) que variam conforme o algoritmo de roteamento, pois limitam a quantidade máxima de bloqueios conforme a direção do fluxo de tráfego, e também a posição dos roteadores na rede, pois roteadores de borda possuem menos conexões por exemplo. Os modelos foram aplicados em redes variando seu tamanho (máximo 6 6), 500 MHz de frequência de relógio e pacotes com tamanho fixo de 8 flits. A latência máxima foi estimada para um fluxo gerado no nodo (1,1) cujo o destino é o nodo no extremo oposto da rede,

47 46 nodo (6,6) no caso de uma rede 6 6. Os resultados demonstraram que o algoritmo de roteamento XY é melhor que o algoritmo adaptativo em relação a latência máxima teórica, e que os modelos propostos podem ser aplicados tanto para redes-em-chip síncronas quanto assíncronas. Kashif et al. (2012), da Universidade de Waterloo Canadá, propõem uma técnica de análise do tempo de resposta de pior caso utilizando um modelo de comunicação em pipeline. São apresentadas duas análises, uma exponencial e outra polinomial. Os modelos consideram interferências diretas e indiretas no fluxo, e também é assumido que sempre existe buffers o suficiente para armazenar os dados. Para a avaliação dos modelos, a NoC de referência foi a mesma utilizada por Shi, Burns e Indrusiak (2010), foram utilizados benchmarks sintéticos e instanciadas duas redes de tamanho 4 4 e 8 8 com 10 aplicações por experimento. A quantidade de tarefas por aplicação variou de 3 a 10, o mapeamento das aplicações foi aleatório e as rotas foram selecionadas por um algoritmo de caminho mais curto (shortest path). Para cada configuração, 100 testes aleatórios foram executados. Os resultados demonstraram que a técnica proposta fornece maior escalonabilidade em relação aos trabalhos previamente comparados pelos autores. Ding e Zhang (2014), da Universidade Comunitária da Virginia Estados Unidos da América, apresentam uma análise estática para estimar a latência de comunicação de pior caso de uma NoC com topologia malha 2D. Essa abordagem utiliza um grafo com pesos para encontrar o fluxo de tráfego responsável pela pior latência de comunicação da rede, ou seja, o fluxo de pior caso. A latência de pior caso para esse fluxo é calculada delimitando o pior tempo de espera de cada roteador em seu caminho para o padrão de tráfego de pior caso, considerando apenas interferências diretas e assumindo buffers de tamanho suficiente para armazenar o número máximo de pacotes em cada canal de entrada. Com base nesta análise, os autores propõem um escalonamento de prioridades baseadas em saltos (hop) para reduzir a latência de pior caso. A validação da análise foi realizada utilizando um simulador em SystemC para uma NoC de tamanhos 2 2 até com roteamento XY e controle de fluxo store-and-foward. O tamanho dos pacotes foi fixado em 5 bytes, a largura de banda em 5 bytes/ciclo e o os buffers foram definidos com o tamanho total do número máximo de pacotes em um canal de entrada da rede. Cada núcleo da rede foi configurado para enviar tráfego por todos os enlaces do roteador simultaneamente, e cada núcleo inicia a transmissão de dados em tempos diferentes. Os resultados experimentais demonstraram que a análise estática consegue estimar de forma segura e precisa a latência de pior caso. A escalonabilidade com prioridade baseada em saltos reduziu a latência de pior caso em 50% em comparação com a escalonabilidade por FIFO.

48 47 Indrusiak (2014), da Universidade de York, propõe métodos analíticos para avaliar quando sistemas embarcados baseados em NoCs conseguem atender a todos os requisitos temporais de uma aplicação de tempo real. São apresentados testes de escalonabilidade baseados na Análise de Tempo de Resposta (Response Time Analysis - RTA) e na análise de escalonabilidade dos fluxos de tráfego de NoCs. Os modelos desenvolvidos consideraram a latência fim-a-fim de cada tarefa, isto é, o tempo para o núcleo de processamento executar a tarefa, adicionado ao tempo necessário para a NoC transferir todos os dados produzidos para uma próxima tarefa (latência de comunicação), considerado bloqueios diretos, indiretos e dependências entre tarefas. A validação dos testes desenvolvidos foi realizada em uma NoC com topologia malha 2D, roteamento XY, controle de fluxo baseado em créditos, 8 canais virtuais com 3 flits de profundidade por porta, e arbitragem com prioridades fixas. O benchmark de aplicação escolhido foi o mesmo apresentados no trabalho de Shi, Burns e Indrusiak (2010). Também foi realizado um experimento utilizando os modelos propostos como função de aptidão para o mapeamento de tarefas. Os resultados demonstraram que os modelos, em conjunto de simulações, fornecem um entendimento detalhado do sobrecusto necessários para garantir o desempenho nos cenários de pior caso em relação aos casos médios. Além disso o desempenho dos testes de escalonabilidade, quando usados como função de aptidão, demonstraram melhoras significativas em relação as funções baseadas em simulação. Em Nikolić e Petters (2014), Instituto Superior de Engenharia do Porto Portugal, os autores propõem uma primeira tentativa em considerar a política de arbitragem com base no conceito de EDF em roteadores de uma NoC com chaveamento do tipo wormhole e apresentam uma análise de contenção para calcular a latência de pior caso de fluxos individuais, considerando bloqueios diretos e indiretos. Os autores comparam a arbitragem proposta com trabalhos da literatura que utilizaram arbitragens de prioridades fixas, por meio de uma análise em relação ao tamanho dos fluxos de tráfego. Foi utilizada um rede em malha 2-D com tamanho 8 8, operando a 2GHz, roteamento XY e com canais virtuais. A configuração de tráfego utilizada assumiu uma distribuição uniforme para gerar aleatoriamente o tamanho e o tempo entre pacotes. Os experimentos demonstraram que a arbitragem EDF obteve melhores resultados em casos onde os fluxos atravessavam distâncias de apenas um salto e sua aplicação depende dos parâmetros do conjunto de fluxos. Nestes casos, o algoritmo EDF é superior a todos os árbitros de prioridade fixa, além de permitir a utilização dos recursos do sistema de modo mais eficiente.

49 48 No trabalho de Abdallah et al. (2015), Universidade de Toulouse França, são apresentadas três propriedades para identificar situações de pior caso e reduzir o pessimismo da análise de escalonabilidade de uma NoC. A primeira propriedade determina o cenário de pior caso quando computado o atraso máximo de bloqueio que um fluxo pode sofrer utilizando arbitragem do tipo round-robin. A segunda propriedade determina que o atraso máximo de bloqueio que um fluxo pode sofrer devido a um desbloqueio é delimitado pelo número de flits do fluxo desbloqueado, eliminando a necessidade de esperar até que este chegue ao seu destino. A terceira propriedade permite checar quando um fluxo indireto influencia no atraso de transmissão do fluxo analisado, considerando a profundidade dos buffers. Essas propriedades foram usadas em um algoritmo, apresentado pelos autores, para melhorar a estimativa da latência de pior caso. Para a validação do algoritmo foi utilizado a rede SpaceWire (PARKES; ARMBRUSTER, 2005), apenas um canal virtual, buffers com apenas 1 flit de profundidade e uma aplicação implementando a transformada rápida de Fourier. Os resultados comprovaram que é possível diminuir o pessimismo da latência de pior caso calculada utilizando o método proposto. Liu, Behnam e Nolte (2015), Universidade de Mälardalen Suécia, apresentam uma análise estocástica do tempo de resposta para uma rede em chip com chaveamento do tipo wormhole, considerando bloqueios diretos e indiretos. A análise proposta calcula a distribuição de probabilidades do tempo de resposta para cara fluxo da rede. Esta distribuição calculada pode ser utilizada para obter os limites superiores em relação a diferentes probabilidades, tempo de resposta médio, ou perdas de prazos. Os autores afirmam que esta abordagem pode fornecer resultados mais informativos comparado com uma análise determinística de tempo de resposta. A avaliação da análise foi realizada por meio de uma série de simulações para uma rede 4 4, roteamento XY, com fluxos gerados aleatoriamente. As simulações buscaram investigar o quanto pessimista é a abordagem. De acordo com os resultados o pessimismo aumenta conforme a quantidade de fluxos e com a redução do número de canais virtuais na rede. Os experimentos também demonstraram que o tempo de processamento da análise é aceitável. Rambo e Ernst (2015), da Universidade Técnica de Braunschweig, apresentam uma análise de pior caso para comunicações em NoCs de melhor esforço utilizando a arbitragem SLIP de dois estágios e roteamento estático, baseado no trabalho proposto por Diemer et al. (2011). A análise fornece a latência limite de pior caso para fluxos individuais e também para fluxos que compartilham os mesmos canais virtuais e caminhos. Também foram considerados os bloqueios diretos e indiretos,

50 49 porém não foi considerado auto-bloqueios, ou seja, a capacidade dos buffers nunca é excedida. A análise proposta foi validada e comparada com simulações e duas outras análises da literatura. Foi utilizado um framework em Python para implementar os modelos e os experimentos foram conduzidos utilizando um simulador em C++, para uma rede 3 3 com apenas 4 fluxos. Os resultados demonstraram que a análise proposta é mais precisa que a abordagem apresentada por Diemer et al. (2011). Em Liu et al. (2016), Universidade de Mälardalen Suécia, são apresentadas propriedades para reduzir o pessimismo da análise de escalonabilidade considerando redes-em-chip com chaveamento do tipo wormhole, arbitragem baseada em níveis de prioridades e roteamento XY. As propriedades da análise proposta avaliam o tempo de resposta dos fluxos apenas em trechos de seus respectivos caminhos em que ocorrem bloqueios diretos e indiretos. Para avaliar a redução do pessimismo, em relação a análise de escalonabilidade sem as propriedades, foram gerados experimentos utilizando o mesmo benchmark apresentado no trabalho de Shi, Burns e Indrusiak (2010) para uma rede 4 4. Também foram efetuados experimentos adicionais para uma rede com configurações de fluxos aleatórios, de modo à avaliar a análise proposta em relação à variação da latência, escalonabilidade da rede e tempo de execução. De acordo com os resultados, a redução média do pessimismo variou de 16% à 4,9% em 70% dos fluxos testados. Porém o tempo de execução aumentou em 1,18 segundos quando a rede possui mais de 140 fluxos. 3.1 ANÁLISE COMPARATIVA Esta seção apresenta uma análise comparativa dos trabalhos descritos anteriormente e posiciona esta dissertação em relação aos mesmos. No Quadro 1, as diferentes abordagens para a estimativa do desempenho de pior caso em redes-em-chip são comparadas com relação ao algoritmos de roteamento e de arbitragem, a consideração da profundidade de buffers nos modelos, os tipos de interferência e o método de validação utilizado. O quadro também apresenta as características das soluções propostas neste trabalho. Todos os trabalhos foizeram uso de roteamento determinístico, pois os roteamentos nãodeterminísticos possuem um número maior de piores casos possíveis, o que dificulta a sua predição. As técnicas utilizadas para arbitragem ficaram divididas entre estática e dinâmica. Para a abordagem estática, foram utilizadas a arbitragem FIFO e de prioridades fixas. No caso da arbitragem dinâmica, Ding e Zhang (2014) utilizaram arbitragem baseada em saltos e Nikolić e Petters (2014) utilizaram

51 50 arbitragem EDF. Os demais trabalhos utilizaram árbitros round-robin. A profundidade dos buffers foi considerada apenas nos modelos de Imai e Yoneda (2012) e Abdallah et al. (2015), porém este último trabalho considerou apenas buffers de 1 flit de profundidade. Em relação aos tipos de interferência considerados nas abordagens, todos os autores assumiram a ocorrência de bloqueios diretos e 9 dos 11 trabalhos também considerou bloqueios indiretos. Apenas Shi, Burns e Indrusiak (2010) assumiram a ocorrência de interferências devido a auto-bloqueios. Kashif et al. (2013), Indrusiak (2014) e Rambo e Ernst (2015) foram os únicos a considerarem dependências entre tarefas. Todas as validações foram realizadas com o uso de simuladores, porém o método de avaliação variou entre fluxos gerados aleatoriamente, cenários específicos em uma NoC e benchmarks de aplicações de tempo real. Com base nos estudos realizados, este trabalho propõe a análise de escalonabilidade de uma NoC com roteamento determinístico e arbitragem dinâmica, considerando bloqueio direto, bloqueio indireto, auto-bloqueio e dependência entre tarefas. A profundidade dos buffers também é levada em consideração nos modelos. Portanto, o seu diferencial em relação aos demais está no fato de considerar o impacto da profundidade de buffers e os quatro tipos de interferência simultaneamente, o que não foi feito por nenhum dos trabalhos analisados.

52 51 Quadro 1. Análise comparativa dos trabalhos selecionados Roteamento Arbitragem Buffers Interferências Validação Trabalhos Determinístico Nãodeterminístico Estática Dinâmica Sim Não Bloqueio Direto Bloqueio Indireto Auto-bloqueio Dependência de Tarefas Benchmarks Fluxos Aleatórios Cenários Específicos Shi, Burns e Indrusiak (2010) Diemer et al. (2011) Imai e Yoneda (2012) Kashif et al. (2013) Ding e Zhang (2014) Indrusiak (2014) Nikolić e Petters (2014) Abdallah et al. (2015) Liu, Behnam e Nolte (2015) Rambo e Ernst (2015) Liu et al. (2016) Esta dissertação X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X

53 CONSIDERAÇÕES O estudo realizado permitiu identificar a tendência dos trabalhos analisados em optar por abordagens estáticas de roteamento, uma vez que um sistema de tempo real deve possuir um comportamento previsível para garantir a disponibilidade de recursos, o que também facilita a análise do sistema. Outra característica observada foi a consideração de tarefas com prazo para entrega das mensagens sempre menor ou igual ao seu período de criação, o que simplifica o modelo, mas impede a avaliação de interferências por auto-bloqueio. Além disso a influência da profundidade dos buffers foi pouco explorada nos modelos. Em relação ao algoritmo de roteamento, os trabalhos ficaram divididos entre as abordagens estáticas e dinâmicas. A dependência de tarefas também foi uma característica pouco explorada, devido ao aumento da complexidade das análises nestes casos. O capítulo a seguir detalha a solução proposta nesta dissertação.

54 53 4 ANÁLISE DE ESCALONABILIDADE DA REDE SOCIN-Q Este trabalho tem por objetivo a redução do tempo de exploração do espaço de projeto de aplicações RT em sistemas integrados baseado em NoCs por meio do uso da análise de escalonabilidade. Para a realização da análise proposta foi definida como NoC de referência deste trabalho a rede SoCIN-Q, descrita na Seção Também foi utilizado o simulador da rede, apresentado na Seção , para o refinamento e validação dos modelos desenvolvidos. Porém, o simulador não permite a avaliação de tarefas com fluxos dependentes, sendo essa uma das características consideradas neste trabalho. Por esse motivo foram necessárias modificações nos módulos de geração de fluxo. Para a análise de escalonabilidade, foram considerados bloqueios diretos e indiretos, buffers finitos, dependência entre tarefas e auto-bloqueios. Para cada uma dessas características, foram desenvolvidos modelos para determinar a latência máxima dos fluxos e garantir o cumprimento de prazos. Para o refinamento e validação dos modelos, foram definidos cenários específicos e fluxos gerados aleatoriamente. As simulações foram executadas no simulador RedScarf com as modificações necessárias para comparar os resultados de latência máxima de cada fluxo e o tempo de execução. Este capítulo apresenta detalhes sobre a análise de escalonabilidade desenvolvida. Inicialmente, são descritos o modelo do sistema, a arquitetura base da rede SoCIN-Q utilizado no desenvolvimento da solução e as modificações realizadas no simulador RedScarf para este trabalho. Após, são apresentadas as premissas e atributos considerados no desenvolvimento dos modelos de análise de escalonabilidade. Por fim, o capítulo descreve os modelos para cada tipo de interferência considerada neste trabalho. 4.1 MODELO DO SISTEMA A solução proposta para resolver o problema de pesquisa desta dissertação consistiu no desenvolvimento de modelos de análise de escalonabilidade para aplicações de tempo real em NoCs. Para tal foram adotadas as seguintes premissas:

55 54 1. Os modelos de simulação de referência para o refinamento dos modelos analíticos são os disponíveis no simulador RedScarf, adotado pelo laboratório de pesquisa ao qual este trabalho está relacionado e permite a avaliação de desempenho de NoCs com precisão de ciclos; 2. A NoC de referência para o desenvolvimento deste trabalho foi a SoCIN-Q, pois permite a diferenciação de fluxos por meio de canais virtuais; 3. O modelo do sistema considerou fluxos independentes periódicos e dependentes esporádicos, com prazo menor ou igual ao seu respectivo período. Posteriormente foram considerados fluxos com prazo maior que o período e auto-bloqueios. No que tange as tarefas dependentes, assim como nos trabalhos analisados, não serão consideradas dependências cíclicas e dependências múltiplas; e 4. A análise de escalonabilidade considerou a contenção de fluxos de tarefas na rede (bloqueios direto, indireto e auto-bloqueio), buffers finitos e a dependência de tarefas Arquitetura Base da Rede-em-Chip A arquitetura da rede SoCIN-Q que foi utilizada como base neste trabalho é apresentada no Quadro 2. Optou-se por utilizar a topologia malha 2D e o roteamento XY, por serem abordagens determinísticas, permitindo a previsibilidade do comportamento dos pacotes na rede. O chaveamento da rede é por pacotes do tipo wormhole e o controle de fluxo baseado em créditos, técnicas mais comumente adotadas em NoCs. A técnica de arbitragem utilizada é a round-robin, disponível na rede SoCIN-Q. Foram utilizados dois canais virtuais para classes de serviço e a profundidade dos buffers variando de 4 a 1024 flits para avaliar seu impacto na simulação e na análise de escalonabilidade. Quadro 2. Arquitetura base da rede de referência Mecanismo Configuração Topologia Malha 2D Chaveamento Wormhole Controle de fluxo Baseado em créditos Roteamento XY Arbitragem Round-robin Número de canais virtuais 2 Profundidade de buffers 4 a 1024 flits

56 Modificações Realizadas no Simulador Redscarf Para implementar o modelo de sistema visando a simulação, foi necessário realizar alterações no módulo de geração de fluxos do RedScarf, pois a versão original não considera a dependência entre tarefas. Uma tarefa dependente só pode iniciar a transmissão de mensagens pela rede após receber e processar os dados de um pacote enviado pela tarefa precedente, da qual ela depende. Por exemplo, no diagrama de sequência ilustrado na Figura 17, a tarefa Ti executa um comando de recebimento bloqueante e aguarda a chegada de um pacote emitido pela tarefa Tj. Após o recebimento do pacote esperado, Ti é executado com os dados do pacote e envia o resultado do processamento para uma terceira tarefa Tk, a qual, por sua vez, é dependente de Ti. T i T j T k Receive(T j ) Receive(T i ) Send(T i ) Send(T k ) Figura 17. Diagrama de sequência para tarefas dependentes O gerador de tráfego do RedScarf é composto de uma thread de geração de fluxos e de uma interface com a NoC. Essa interface possui um canal de saída e um canal de entrada conectados à rede. Os pacotes gerados pela thread são armazenados em um buffer e posteriormente enviados pela porta de saída. Os pacotes recebidos pela porta de entrada são consumidos automaticamente, conforme ilustra a Figura 18 (a). Entretanto, para representar a dependência de tarefas, foi necessária a implementação de um buffer que permite que a thread de geração de fluxo receba os pacotes da porta de entrada e verifique a dependência de outra tarefa (Figura 18.b).

57 56 Buffer Thread Buffer Thread Saída Entrada Saída Entrada (a) (b) Figura 18. Modificações realizadas: (a) TG original; (b) TG modificado 4.2 ANÁLISE DE ESCALONABILIDADE Os modelos desenvolvidos neste trabalhos consideraram um sistema RT composto de um conjunto Γ de n fluxos de tráfego, Γ = {τ 1, τ 2,..., τ n }. Cada fluxo τ i é caracterizado por uma tupla {L max i, p i, d i, e i, v i, τ Prec } indicando, respectivamente, a latência máxima, o período (i.e. tempo entre mensagens), o deadline, o tempo de utilização do roteador e a numeração do canal virtual (0 é a prioridade mais alta). O último atributo é utilizado apenas no modelo considerando a dependência de tarefas e representa o fluxo precedente de τ i. Também foi considerado, neste trabalho, que o tempo de execução dos dados de um fluxo, em seu nodo de origem, já está incluso no valor do período. A análise considerou fluxos periódicos independentes e fluxos esporádicos dependentes. Foi assumido que o prazo para entrega dos pacotes de um fluxo de comunicação é menor ou igual ao seu respectivo período, ou seja, d i p i para todo τ i Γ. O tempo de encaminhamento dos pacotes nos roteadores foi calculado considerando o tempo de memorização, roteamento e arbitragem. Também foi analisada a influência de bloqueios diretos, indiretos e auto-bloqueios. O Quadro 3 apresenta os atributos e as características considerados para modelagem com interferências direta e indireta. O Quadro 4 identifica as particularidades para a modelagem considerando o auto-bloqueio. A principal diferença está no deadline, cuja a restrição é removida, permitindo a existência de fluxos com prazo maior que seu período. Como consequência, é possível a existência de mais de um pacote de um mesmo fluxo na rede em determinado instante de tempo. Nessa situação, pacotes de um mesmo fluxo podem gerar bloqueios entre si.

58 57 Quadro 3. Atributos do sistema considerados nos modelos sem auto-bloqueio Atributo Valores Tarefas (Periodicidade) Independentes (periódicas) e dependentes (esporádicas) Tempo de utilização do roteador Tempo de memorização, arbitragem e roteamento Deadline relativo Menor ou igual ao período Interferências Bloqueio direto e indireto Buffers Finitos Quadro 4. Atributos do sistema considerados nos modelos com auto-bloqueio Atributo Valores Tarefas (Periodicidade) Independentes (periódicas) e dependentes (esporádicas) Tempo de utilização do roteador Tempo de memorização, arbitragem e roteamento Deadline relativo Sem restrição Interferências Bloqueio direto, indireto e auto-bloqueio Buffers Finitos Para representar a rede, foi utilizado um grafo direto em que cada roteador R é um vértice e os enlaces E são as arestas. Uma aresta E x,y é equivalente ao enlace do roteador R x para o roteador R y, ou seja, E x,y = {R x R y }. Neste trabalho. foi considerado que cada nodo conectado à rede gera apenas um fluxo e, deste modo, o número máximo de fluxos mapeados na rede é igual à quantidade de roteadores. O caminho percorrido β i por cada um destes fluxos τ i é denotado por um conjunto de enlaces, β i = {E a,b, E c,d,, E x,y }. Durante sua transmissão pela rede, um fluxo τ i compete por recursos com os demais fluxos. Esses conflitos são resolvidos conforme a prioridade do canal virtual utilizada por cada um e da arbitragem round-robin. Esse tipo de arbitragem possui um comportamento não-determinístico e, por esse motivo, foram consideradas as seguintes premissas para determinar o cenário de pior caso de um fluxo τ i em um roteador R k : 1. A porta do roteador em que se encontra o fluxo τ i recebe sempre a menor prioridade; 2. Todo fluxo τ j com v j v i chega ao mesmo tempo que τ i em R k ; e 3. Os demais fluxos que competem com τ i chegam imediatamente após a liberação da porta de saída de R k.

59 Latência Básica A latência básica ou latência mínima ocorre quando um fluxo não sofre nenhuma contenção ao atravessar a NoC. A Figura 19 (a) ilustra o exemplo de um fluxo τ 1 com origem no roteador R 1 e destino no roteador R 3. Em cada roteador percorrido pelo cabeçalho do pacote de τ 1 são necessários dois ciclos para memorização e roteamento no módulo de entrada (input) e um ciclo para arbitragem no modulo de saída (output). Também é necessário um ciclo adicional para o cabeçalho ser consumido pela porta Local do roteador destino. Os demais flits que compõem a carga útil do pacote percorrem a rede em um pipeline. Na Figura 19 (b), é ilustrada a linha do tempo do fluxo τ 1 em cada roteador, em que o primeiro flit é o cabeçalho e os demais são a carga útil (numerados de 1 a 4). τ1 Roteador Ciclo adicional R1 R2 R3 R Memorização Input Roteamento VC0 VC Output Arbitragem R 2 R Tempo (ciclos) (a) (b) Figura 19. Latência básica de τ 1 : (a) caminho percorrido e (b) linha do tempo A latência mínima L Min i de um fluxo τ i é determinada pelo número de roteadores percorridos, a quantidade de flits do pacote e o tempo de memorização, arbitragem e roteamento. A quantidade de roteadores é determinada adicionando 1 à quantidade de enlaces no caminho β Size i. Para cada roteador percorrido pelo cabeçalho do pacote de τ i, é computado o tempo de execução (memorização, roteamento e arbitragem) s, além do ciclo adicional para o cabeçalho ser consumido pela porta Local do roteador destino. Os flits de carga útil, payload i, atravessam os roteadores como um pipeline e por este motivo levam apenas 1 ciclo cada. L i Min = s (β i Size + 1) payload i (11)

60 Bloqueios Diretos Um bloqueio direto ocorre quando um fluxo τ i e um fluxo τ j possuem enlaces em comum em seus caminhos, ou seja, β i β j. Se a condição v i v j é verdadeira, então τ j possui a prioridade e τ i deve aguardar a sua transmissão pelo enlace. Todo fluxo τ j que cumpre essas condições pertence D ao conjunto de interferências diretas S i de τ i, S D i = {τ j β i β j e v i v j τ j Γ}. Um fluxo τ j pertencente ao S i D gera bloqueio por tempo suficiente para a memorização, roteamento e arbitragem do cabeçalho e o transporte da carga útil do pacote. Esse valor é denotado por e j = s + payload j. Considerando apenas bloqueios diretos e assumindo que τ j utiliza o mesmo canal virtual que τ i, tal que v i = v j, a latência máxima é o somatório do tempo de utilização do roteador de cada fluxo bloqueante adicionado a sua própria latência mínima, conforme expresso por (12). L i Max = L i Min + e j τ j S i D (12) Se o fluxo τ j bloqueante utilizar um canal virtual com maior prioridade, v i > v j, a transmissão do fluxo τ i é preemptada. Em sistemas monoprocessados a preempção pode ocorrer múltiplas vezes, dependendo da periodicidade e do tempo máximo de execução das tarefas, conforme o teste baseado em tempo de resposta apresentado na Seção Em Shi, Burns e Indrusiak (2010) e Indrusiak (2014) é apresentada uma versão adaptada deste teste para NoCs, conforme (13) e (14), onde o número de interferências I j geradas por τ j é determinado por seu período e a latência máxima de τ i. Essa abordagem é muito pessimista pois considera a latência ocorrida durante toda a transmissão do pacote, conforme ilustrado na Figura 20 (a). Para reduzir o pessimismo do modelo, nesta dissertação foi considerado apenas o tempo necessário para a travessia do pacote de τ i por enlaces em comum com τ j, ilustrado na Figura 20 (b). I j = L Max i (13) p j L i Max = L i Min + I j e j τ j S i D (14)

61 60 R7 R8 R9 R7 R8 R9 R4 R5 R6 R4 R5 R6 R1 R2 R3 R1 R2 R3 τi τi τj τj (a) (b) Figura 20. Enlaces: (a) considerados em (13) e (b) enlaces em comum entre τ i e τ j Em (15), é definida a quantidade de interferências I j geradas por um fluxo τ j considerando o tempo necessário para todo o pacote de τ i ser transportado pelos enlaces em comum. Esse tempo de transporte inclui o atraso gerado por um pacote de τ j pois, na situação de pior caso, este fluxo já está bloqueando τ i. A função Common_edges(τ i, τ j ) determina a quantidade de enlaces em comum entre os dois fluxos. A latência máxima é determinada por (16) considerando fluxos pertencentes ao mesmo canal virtual de τ i e fluxos de canais virtuais diferentes. Nesse último caso são descontados dois ciclos de latência pois, como τ i não utiliza o mesmo canal virtual que τ j, só é necessário aguardar o tempo de memorização do pacote. I j = Common_edges(τ i, τ j ) e i + e j p j (15) L Max i = L Min i + e k + I j e j 2 τ k S i D se v i =v k τ j SD (16) i se v i >v j

62 Bloqueios Indiretos Um bloqueio indireto ocorre quando um fluxo τ i e um fluxo τ k não possuem enlaces em comum em seus caminhos, ou seja, β i β k =, porém possuem enlaces em comum com um fluxo τ j, β i β j e β k β j. Se a condição v i = v j v k é verdadeira, então τ k interfere indiretamente em τ i, que deve aguardar a sua transmissão pelo enlace além da transmissão de τ j. I Todo fluxo τ k que cumpre essas condições pertence ao conjunto de interferências indiretas S i de τ i, S I i = {τ k e τ j β i β k =, β i β j, β k β j e v i = v j τ k τ k Γ e τ j S D i }. Na Figura 21 (a), é ilustrada uma situação em que v i > v j v k e τ j é bloqueado por τ k. O fluxo τ i não sofre a interferência indireta de τ k pois o controle de fluxo baseado em créditos da rede SoCIN-Q permite ao canal virtual 1 da porta W de R 3 enviar flits quando os buffers do canal virtual 0 estão esgotados (Figura 21.b), por este motivo o bloqueio indireto ocorreria apenas quando v i = v j. τk τk τj τj τi τi R1 R2 R3 R4 R5 R1 R2 R3 R4 R5 Eout2vc Win2vc Eout2vc Eout2vc Win2vc Eout2vc τj τj τi τk Lout2vc τi τk Lout2vc (a) (b) Figura 21. Se v i > v j v k : (a) τ j é bloqueado por τ k ; e (b) τ i envia flits quando acaba os buffers A Figura 22 (a) ilustra uma situação em que ocorre um bloqueio indireto entre τ k em τ i, assumindo que o pacote de τ j possui 5 flits (incluindo o cabeçalho), v i = v j v k e roteadores com 4 flits de profundidade de buffer. Quando τ j sofre um bloqueio pelo fluxo τ k ele bloqueia as portas W dos roteadores R 3 e R 4 e impede a passagem de τ i. Na Figura 22 (b), a profundidade dos buffers é incrementada para 5 flits, de modo que o pacote de τ j ocupa apenas o buffer da porta W de R 4, possibilitando a τ i utilizar a porta W de R 3. O fluxo τ k ainda bloqueia τ j porém não possui nenhuma influência em τ i.

63 62 τk τk τj τj τi τi R1 R2 R3 R4 R5 R1 R2 R3 R4 R5 Win2vc Win2vc Win2vc Win2vc (a) (b) Figura 22. Bloqueio indireto: (a) τ k possui influência com 4 flits; e (b) não gera bloqueio com 5 flits A influência de um bloqueio indireto gerado por um fluxo τ k em τ i é afetada diretamente pela profundidade dos buffers da rede e o tamanho do pacote de τ j. Em (17), é determinada a quantidade de flits de τ j responsáveis por permitir a interferência indireta. Esse valor é determinado pela diferença entre o tamanho do pacote de τ j, payload j + 1, e a quantidade total de flits disponíveis no caminho entre o último roteador em comum de τ i e τ j, R Last i,j, e o roteador bloqueado por τ k, R Block j,k. O número de saltos (função hops) define a quantidade de roteadores. Se Influence j > 0, então τ k S i I. A latência gerada pelos bloqueios indiretos é computada por (18) do mesmo modo que os bloqueios diretos em (16). Influence j = payload j + 1 hops(r Last i,j, R Block j,k ) FIFO depth (17) L Indirect i = e j + I k e k 2 τ j S i I se v i =v j τ k SI (18) i se v i >v k Os bloqueios indiretos podem ocorrer em situações com mais de três fluxos, em que o bloqueio indireto se estende formando um enfileiramento de fluxos. A Figura 23 ilustra o enfileiramento de cinco fluxos. Assumindo que todos os fluxos utilizam o mesmo canal virtual, o bloqueio direto gerado por τ 5 em τ 4 influência indiretamente os fluxos τ 1, τ 2 e τ 3. A detecção dos bloqueios indiretos neste tipo de cenário é efetuada pela verificação da condição v i = v j v k de forma recursiva à partir do primeiro fluxo do enfileiramento. A influência dos bloqueios indiretos também é verificada recursivamente.