USO DE ANÁLISE DE ESCALONABILIDADE PARA ACELERAR
A EXPLORAÇÃO DO ESPAÇO DE PROJETO EM SISTEMAS
BASEADOS EM REDES-EM-CHIP
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.
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.
“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.“
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%.
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, self-blocks, task dependence and buffers size. A series of experiments was performed using a cycle-accurate 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%.
Figura 1. Exemplo de redes com topologia direta: (a) ponto-a-ponto; e (b) malha ... 18
Figura 2. Exemplo de topologias indiretas: (a) árvore gorda; e (b) butterfly ... 19
Figura 3. Estrutura de mensagens, pacotes, flits e phits ... 20
Figura 4. Controle de fluxo baseado em créditos... 22
Figura 5. Exemplo de gráficos: (a) vazão; (b) latência média ... 26
Figura 6. Sistema de coordenadas da Rede SoCIN ... 28
Figura 7. Rede SoCIN: (a) enlace; (b) formato do pacote ... 29
Figura 8. Módulos de cada porta de um roteador interconectados por uma matriz de conexões ... 30
Figura 9. Estrutura interna dos módulos do roteador ParIS: (a) entrada; (b) saída ... 31
Figura 10. SoCIN-Q: (a) módulo de entrada; (b) módulo de saída; (c) formato do pacote ... 33
Figura 11. Exemplo de sistema criado com o simulador BrownPepper ... 34
Figura 12. Exemplo de escalonamento para avaliação do pior tempo de resposta de uma tarefa ... 37
Figura 13. Classificação dos algoritmos de escalonamento de tarefas RT ... 38
Figura 14. Diagrama de um escalonamento RM... 39
Figura 15. Diagramas de escalonamento: (a) FIFO; (b) EDF ... 40
Figura 16. Interferências: (a) direta; (b) indireta ... 45
Figura 17. Diagrama de sequência para tarefas dependentes ... 55
Figura 18. Modificações realizadas: (a) TG original; (b) TG modificado ... 56
Figura 19. Latência básica de 𝜏1: (a) caminho percorrido e (b) linha do tempo ... 58
Figura 20. Enlaces: (a) considerados em (13) e (b) enlaces em comum entre 𝜏𝑖 e 𝜏𝑗 ... 60
Figura 21. Se 𝑣𝑖 > 𝑣𝑗 ≥ 𝑣𝑘: (a) 𝜏𝑗 é bloqueado por 𝜏𝑘; e (b) 𝜏𝑖 envia flits quando acaba os buffers ... 61
Figura 22. Bloqueio indireto: (a) 𝜏𝑘 possui influência com 4 flits; e (b) não gera bloqueio com 5 flits ... 62
Figura 23. Enfileiramento composto por cinco fluxos ... 63
Figura 24. Grafos de precedência: (a) dependência entre 𝜏𝑖 e 𝜏𝑝 e (b) quatro fluxos dependentes .. 63
Figura 25. Diagrama de 𝜏𝑃𝑟𝑒𝑐 e 𝜏𝑖 ... 64
Figura 26. Diagrama de 𝜏𝑖 para 𝐿𝑖𝑀𝑎𝑥 > 𝑝𝑖 ... 65
Figura 27. Bloqueio 𝐵𝑗 composto de 𝜏𝑗 e 𝜏𝑘 ... 66
Figura 28. Fluxograma para a verificação e refinamento dos modelos ... 69
Figura 29. Cenário para o refinamento dos modelos considerando bloqueios diretos ... 70
Figura 30. Cenário para o refinamento dos modelos considerando a preempção de fluxos ... 71
Figura 31. Cenário para o refinamento dos modelos considerando bloqueios indiretos ... 72
Figura 32. Cenário para o refinamento dos modelos considerando a dependência de tarefas ... 74
Figura 33. Cenário para o refinamento dos modelos considerando auto-bloqueios ... 75
Figura 34. Cenário para o Experimento 2 ... 79
Quadro 1. Análise comparativa dos trabalhos selecionados ... 51
Quadro 2. Arquitetura base da rede de referência ... 54
Quadro 3. Atributos do sistema considerados nos modelos sem auto-bloqueio ... 57
Tabela 1. Tarefas periódicas para o escalonamento RM ... 39
Tabela 2. Tarefas para o escalonamento FIFO e EDF ... 40
Tabela 3. Configuração dos fluxos para a análise de bloqueios diretos ... 70
Tabela 4. Resultados obtidos no experimento considerando bloqueios diretos ... 70
Tabela 5. Configuração dos fluxos para a análise de preempções ... 71
Tabela 6. Resultados obtidos no experimento considerando preempções ... 71
Tabela 7. Erro em relação a simulação para as análises ... 72
Tabela 8. Configuração dos fluxos para a análise de bloqueios indiretos ... 72
Tabela 9. Resultados obtidos considerando buffers com 4 flits ... 73
Tabela 10. Resultados obtidos considerando buffers com 64 flits ... 73
Tabela 11. Configuração dos fluxos para a análise da dependência de tarefas ... 74
Tabela 12. Resultados obtidos no experimento considerando a dependência de tarefas ... 74
Tabela 13. Configuração dos fluxos para a análise de auto-bloqueios ... 75
Tabela 14. Resultados obtidos no experimento considerando auto-bloqueios ... 75
Tabela 15. Configuração dos fluxos do Experimento 1 ... 77
Tabela 16. Erro das análises para mapeamentos com destinos únicos ... 77
Tabela 17. Erro das análises para mapeamentos com destinos repetidos ... 78
Tabela 18. Tempo de execução do Experimento 1 ... 78
Tabela 19. Configuração dos fluxos para o Experimento 2 ... 79
Tabela 20. Erro das análises para cada profundidade de buffers ... 80
ACK Acknowledgement
BE Best Effort
bop Begin-of-packet
CPM Cross Point Matrix
DM Deadline-Monotonic
EDF Earliest-Deadline-Firts
eop End-of-packet
FIFO First In, First Out
Flit Flow Control Unit
GS Guaranteed Service
HDL Hardware Description Language
HLP Higher Level Protocol
IC Input Controller
IFC Input Flow Control
IP Intellectual Property
IRS Input Read Switch
MCA Mestrado em Computação Aplicada
MLS Menor Limite Superior
mmc Mínimo múltiplo comum
NoC Network-on-Chip
OC Output Control
ODS Output Data Switch
OFC Output Flow Controller
OWS Output Write Switch
ParIS Parameterizable Interconnect Switch
Phit Physical unit
QoS Quality-of-Service
RIB Routing Information Bits
RM Rate-Monotonic
RT Real-Time
nRT non-Real-Time
RTL Register Transfer Level
SAF Store and Foward
SoC System-on-Chip
SoCIN SoC Interconnection Network
TG Traffic Generator
TM Traffic Metter
UNIVALI Universidade do Vale do Itajaí
VCT Virtual Cut Through
VHDL VHSIC HDL
VHSIC Very High Speed Integrated Circuit
B Bloqueio
e Tempo máximo de execução ou tempo de pior caso
E Enlace
d Deadline
I Interferência
J Job ou instância de uma tarefa
L Latência
p Período
Q Quantidade de pacotes enfileirados
r Tempo de chegada ou tempo de início
R Roteador
s Tempo de memorização, roteamento e arbitragem
S Conjunto de fluxos bloqueantes ou de bloqueios
T Tarefa
U Utilização total
v Numeração do canal virtual
β Conjunto de enlaces
Γ Conjunto de fluxos
1
INTRODUÇÃO ... 12
1.1
PROBLEMA DE PESQUISA... 13
1.1.1
Solução Proposta ... 14
1.1.2
Delimitação de Escopo ... 15
1.2
OBJETIVOS ... 15
1.2.1
Objetivo Geral ... 15
1.2.2
Objetivos Específicos ... 15
1.3
METODOLOGIA ... 15
1.3.1
Metodologia da Pesquisa ... 15
1.3.2
Procedimentos Metodológicos ... 16
1.4
ESTRUTURA DA DISSERTAÇÃO ... 16
2
FUNDAMENTAÇÃO TEÓRICA ... 17
2.1
REDES-EM-CHIP ... 17
2.1.1
Arquitetura de uma Rede-em-Chip ... 18
2.1.2
Métricas de Desempenho ... 25
2.1.3
Qualidade de Serviço ... 26
2.1.4
Rede SoCIN ... 28
2.2
SISTEMAS DE TEMPO REAL ... 34
2.2.1
Tarefas de Tempo Real ... 35
2.2.2
Tempo de Resposta de Pior Caso ... 36
2.2.3
Escalonamento de Tarefas... 37
2.2.4
Análise de Escalonabilidade ... 41
2.3
CONSIDERAÇÕES ... 43
3
TRABALHOS RELACIONADOS ... 44
3.1
ANÁLISE COMPARATIVA... 49
3.2
CONSIDERAÇÕES ... 52
4
ANÁLISE DE ESCALONABILIDADE DA REDE SOCIN-Q ... 53
4.1
MODELO DO SISTEMA ... 53
4.1.1
Arquitetura Base da Rede-em-Chip ... 54
4.1.2
Modificações Realizadas no Simulador Redscarf ... 55
4.2
ANÁLISE DE ESCALONABILIDADE ... 56
4.2.1
Latência Básica ... 58
4.2.2
Bloqueios Diretos ... 59
4.2.3
Bloqueios Indiretos ... 61
4.2.4
Dependência de Tarefas ... 63
4.2.5
Auto-bloqueios ... 65
4.3
CONSIDERAÇÕES ... 67
5.2
EXPERIMENTOS ... 69
5.2.1
Refinamento ... 69
5.2.2
Validação ... 76
5.3
DISCUSSÃO ... 80
6
CONCLUSÕES ... 82
6.1
CONTRIBUIÇÕES DA DISSERTAÇÃO ... 83
6.2
TRABALHOS FUTUROS ... 83
REFERÊNCIAS ... 84
APÊNDICE A –
REVISÃO SISTEMÁTICA ... 88
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 (Systems-on-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
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).
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ácia1 da análise de escalonabilidade é suficiente a ponto de substituir uma
simulação?
1.1.1 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.
1No 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)
1.1.2 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
1.2.1 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.
1.2.2 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
1.3.1 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
de dados gerados pelo ferramental de experimentação, e também como qualitativa uma vez que é necessário interpretar os resultados gerados.
1.3.2 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.
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.
2.1.1 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).
2.1.1.1 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. 20-21). 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. 28-29).
Figura 1. Exemplo de redes com topologia direta: (a) ponto-a-ponto; e (b) malha
Nodo = núcleo + roteador
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).
= Núcleo = Roteador
(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).
2.1.1.2 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.
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. 51-52).
Mensagem Pacote Flit Phit carga útil cabeçalho terminador
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. 450-451).
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.
2.1.1.3 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).
Figura 4. Controle de fluxo baseado em créditos
contador buffer 2 +1 -1 crédito flit Emissor Receptor
2.1.1.4 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).
2.1.1.5 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).
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. 352-355).
2.1.1.6 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. 44-45).
2.1.2 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).
Figura 5. Exemplo de gráficos: (a) vazão; (b) latência média
Fonte: Adaptado de Dally e Towles (2004, p. 453-455).
2.1.3 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).
2.1.3.1 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.
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. 285-286).
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).
2.1.4 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).
0,0 0,1 0,2 0,3 1,0 2,0 3,0 1,1 2,1 3,1 1,2 2,2 3,2 1,3 2,3 3,3 X Y 3 2 1 0 0 1 2 3 x,y N S E W L
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
(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).
Figura 7. Rede SoCIN: (a) enlace; (b) formato do pacote
Fonte: Adaptado de Zeferino, Santo e Susin (2004).
2.1.4.1 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).
HLP RIB.x RIB.y Carga útil
Último flit (terminador) 0 1 0 1 0 0 eop bop n bits m bits ili m ita d o n+2 n+2 val ret bop eop dados n (a) (b)
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
CPM Lin Lout Win Wout Din Din Dout Dout val ret val ret val ret val ret
encaminhado tanto na direção X como na direção Y, adaptativamente (ZEFERINO; SANTO; SUSIN, 2004).
Figura 9. Estrutura interna dos módulos do roteador ParIS: (a) entrada; (b) saída
Fonte: Adaptado de Zeferino, Santo e Susin (2004).
2.1.4.2 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). din wr wok dout rok rd din wr wok dout rok rd output OFC FIFO rok[ ] wok val ret dout OC gnt[ ] idle req[ ] O W S O D S input IFC FIFO IC req[ ] idle[ ] rok wok[ ] val ret din I R S (a) (b)
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.
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).
2.1.4.3 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.
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
x,y = ParIS = TG = TM 0.2 1,2 2,2 2,1 1,1 0,1 2,0 1,0 0,0
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 2.2.4 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).
2.2.1 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
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.
2.2.2 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
o tempo de resposta é 24 – 18 = 6 unidades de tempo. Para este exemplo, o tempo de resposta de pior caso para a tarefa T3 é de 11 unidades de tempo.
Figura 12. Exemplo de escalonamento para avaliação do pior tempo de resposta de uma tarefa
Fonte: Adaptado de Fan (2015, p. 309).
2.2.3 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). 0 2 4 6 8 10 12 14 16 18 20 22 24 J1,1 J2,1 J3,1 J1,2 J1,3 J2,2 J1,3 J3,2 J3,1 T2 (12, 3) T3 (18, 4) T1 (6, 2) Tempo
Figura 13. Classificação dos algoritmos de escalonamento de tarefas RT
Fonte: Adaptado de Kopetz (2011, p. 240).
2.2.3.1 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.
Escalonamento RT Brando Crítico Dinâmico Estático Preemptivo Não-preemptivo Preemptivo Não-preemptivo
