universidade federal de pernambuco centro de informática ... · duas questões são críticas em...
TRANSCRIPT
Universidade Federal de Pernambuco
Centro de Informática
Pós-graduação em Ciência da Computação
UMA ESTRATÉGIA PARA REDUÇÃO DE
CONGESTIONAMENTO EM SISTEMAS
MULTIPROCESSADORES BASEADOS EM
NOC
Camila Ascendina Nunes Kamei
DISSERTAÇÃO DE MESTRADO
Recife
2015
Camila Ascendina Nunes Kamei
UMA ESTRATÉGIA PARA REDUÇÃO DE
CONGESTIONAMENTO EM SISTEMAS
MULTIPROCESSADORES BASEADOS EM NOC
Trabalho apresentado ao Programa de Pós-graduação em Ciên-
cia da Computação do Centro de Informática da Universidade
Federal de Pernambuco como requisito parcial para obtenção
do grau de Mestre em Ciência da Computação.
Orientador: Prof a. Dr a. Edna Natividade da Silva Barros
Coorientador: Prof. Dr. André Aziz Camilo de Araújo
(UFRPE)
Recife
2015
Catalogação na fonte
Bibliotecária Joana D’Arc Leão Salvador CRB4-572
K15e Kamei, Camila Ascendina Nunes.
Estratégia para redução de congestionamento em sistemas multiprocessadores baseados em NOC / Camila Ascendina Nunes Kamei. – Recife: O Autor, 2015.
113 f.: fig., tab., graf. Orientadora: Edna Natividade da Silva Barros. Dissertação (Mestrado) – Universidade Federal de Pernambuco. CIN,
Ciência da Computação, 2015. Inclui referências.
1. Ciência da computação. 2. Sistemas embarcados (Computadores). 3. Multiprocessadores. I. Barros, Edna Natividade da Silva (Orientador). II. Titulo.
004 CDD (22. ed.) UFPE-MEI 2015-117
Dissertação de Mestrado apresentada por Camila Ascendina Nunes Kamei à Pós-
Graduação em Ciência da Computação Centro de Informática da Universidade Federal de
Pernambuco, sob o título “Estratégia para Redução de Congestionamento em
Sistemas Multiprocessadores Baseados em NoC” orientada pela Profa. Edna
Natividade da Silva Barros e aprovada pela Banca Examinadora formada pelos
professores:
______________________________________________
Prof. Manoel Eusebio de Lima
Centro de Informática/UFPE
______________________________________________
Prof. Elmar Uwe Kurt Melcher
Departamento de Sistemas e Computação / UFCG
_______________________________________________
Profa. Edna Natividade da Silva Barros
Centro de Informática / UFPE
Visto e permitida a impressão.
Recife, 7 de agosto de 2015.
___________________________________________________
Profa. Edna Natividade da Silva Barros Coordenadora da Pós-Graduação em Ciência da Computação do
Centro de Informática da Universidade Federal de Pernambuco.
AGRADECIMENTOS
Primeiramente gostaria de agradecer a Deus e Nossa Senhora que me permitiram chegar
até aqui e que me deram forças para vencer as atribulações durante o período de desen-
volvimento do projeto. Sem essa fé nada disso teria sido possível. Agradecer aos meus
pais (Nilton e Joana Nunes) por terem se esforçado arduamente na minha "lapidação"e
por me fornecerem bases tão fortes para trilhar os meus sonhos. Aos meus irmãos (Nilton
Filho, Pouline e Renato Ferro) e a minha sobrinha (Maria Eduarda Ascendina) por terem
me apoiado e me mostrado que as vezes as soluções para os nossos problemas se apresen-
tam depois de um momento de distração. Ao meu amado esposo (João Pedro Kamei) que
segurou minha mão nas horas de dúvidas, enxugou minhas lágrimas nos momentos de
desesperança e deu total suporte para as minhas pesquisas. A todos os meus familiares
por sonharem este sonho comigo. Tenham certeza que meu amor por vocês é imenso!
Um agradecimento especial a minha orientadora (Edna Barros) que sempre me forneceu
aqueles "puxões de orelha"especiais e que me incentivou a continuar perseguindo meu
sonho fornecendo os ensinamentos, conselhos e materiais necessários. Um super agrade-
cimento ao meu co-orientador (André Aziz) que foi muito além de orientador, foi meu
amigo, muitas vezes até co-piloto! Ajudando-me a entender o como fazer, como codi�car
e como executar o meu projeto.
Toda esta caminhada teria sido muito menos �orida se não fosse meus amigos (Amanda
Barros, Cataliny Andreza, Vanessa Larize, Vanessa Oliveira, Andre Olivino, Max San-
tana, Maria Cireno, Maryanne Brasilino, Angelo Brito, Cecil Acetti, Erika Albuquerque,
Iara Cavalcanti, Marcus Duarte, Ladson Gomes, José Nilton) e tantos outros que me
guiaram e incentivaram.
A todos os funcionários do CIn que embarcaram comigo neste projeto, escutando e au-
xiliando nos meus problemas de infra-estrutura (Suilan Dias, Roberto Marianno, Carlos
Mendes, Hilda Moura, Inácia Bezerra, Edilene Arruda), ou me ajudando com toda docu-
mentação necessária para continuar os trabalhos (Maria Lilian Pinheiro, Maria do Socorro
Chaves, Daniel Bandeira Teles, Joelma Souza de Menezes).
Agradeço também ao CNPq que �nanciou esta ideia e tornou meu sonho muito mais real.
Infelizmente não é possível citar todas as pessoas especiais que estão sempre ao meu lado,
mas tenham certeza que não esqueço de cada um e que tenho uma gratidão imensa por
cada atitude, palavra de incentivo, cada gesto, cada coisa linda que vocês �zeram por
mim. Muitíssimo obrigada pelo carinho, atenção e amor! Espero que gostem do nosso
trabalho!
RESUMO
Duas questões são críticas em sistemas com paralelismo de memória em rede NoC base-
ados em MPSoC, a ordem de entrega da mensagem e o congestionamento da rede. Os
congestionamentos são frequentes em NoC quando as demandas de pacotes excedem a
capacidade dos recursos da rede e a ordem das mensagens precisam ser mantidas para que
a informação de coerência de cache tenha signi�cado para as memórias. Assim, métodos
de controle de congestionamento são necessários para estes sistemas e devem lidar com o
congestionamento da rede, enquanto mantém a ordem das transações.
Este trabalho propõe uma técnica de roteamento baseada no algoritmo de roteamento
Odd-Even associado ao conceito de congestionamento local e global da rede para a esco-
lha do melhor caminho de encaminhamento dos pacotes de comunicação. Desta forma se
objetiva a redução dos gargalos de comunicação da rede para os sistemas NoC baseado
em MPSoC. Nos experimentos realizados para 16 núcleos, a técnica proposta alcançou a
redução de 13,35% da energia consumida, 25% de redução de latência de envio de pacotes
em comparação o algoritmo XY e 23% de redução de latência de envio de pacotes em
comparação o algoritmo Odd-Even sem modi�cação.
Palavras-chave: NoC - Network-on-Chip. Congestionamento em NoC. Algoritmo
Adaptativo.
ABSTRACT
Two issues are critical in systems with memory parallelism network NoC-based MPSoC,
the delivery order of messages and network congestion. The congestions are frequent in
NoC when the packages demands exceed the capacity of the network resources and the
order of the messages need to be maintained so that the cache coherency information is
meaningful to the memories. Thus, congestion control methods are needed to deal with
network congestion while they keep the order of the transactions.
This paper proposes the use of the routing algorithm Odd-Even associated with the con-
cept of local and global network congestion to choose the best routing path of communi-
cation packages. In this way it aims to reduce the network communication bottlenecks
for NoC systems based on MPSoC. In experiments conducted for 16 cores, the proposed
technique has achieved the reduction of 13.35 % of energy consumption, 25% of latency
compared with the XY algorithm and 23% of latency compared with the Odd-Even al-
gorithm without the modi�cation.
Keywords: NoC - Network-on-Chip. Congestion on NoC. Adaptative Algorithm.
LISTA DE FIGURAS
2.1 Estrutura de um Multiprocessado com Memória Compartilhada Centralizada 25
2.2 Estrutura de Multiprocessado com Memória Distribuída . . . . . . . . . 25
2.3 Arquitetura NoC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.4 Estrutura Interna de um Roteador . . . . . . . . . . . . . . . . . . . . . 30
2.5 Partes que compõe um pacote . . . . . . . . . . . . . . . . . . . . . . . . 32
2.6 Rede Malha 2D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.7 Rede Toroide 2D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.8 Rede Hipercubo 3D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.9 Rede Árvore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.10 Rede Estrela . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.11 Algoritmo XY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.12 Algoritmo NL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.13 Algoritmo NF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.14 Algoritmo WF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.15 Plataforma In�nity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
2.16 Estrutura do Pacote SoCINfp . . . . . . . . . . . . . . . . . . . . . . . . 46
2.17 Estrutura do Enlace SoCINfp . . . . . . . . . . . . . . . . . . . . . . . . 46
2.18 Estrutura Interna do Roteador ParIS . . . . . . . . . . . . . . . . . . . . 48
2.19 Organização da Interface de Rede . . . . . . . . . . . . . . . . . . . . . . 51
2.20 Partes Constituintes da Mensagem . . . . . . . . . . . . . . . . . . . . . 53
3.1 Probabilidade de Passagem de Pacotes pelos Nós . . . . . . . . . . . . . 56
3.2 Distribuição dos Agentes . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.3 Circuito de Detecção de Congestionamento . . . . . . . . . . . . . . . . . 58
3.4 Atraso Médio de Comunicação para Tráfego Uniforme . . . . . . . . . . . 59
3.5 Atraso Médio de Comunicação para Tráfego com Hotspot . . . . . . . . . 60
3.6 Média de Latência do Pacote . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.7 Diferentes níveis de Congestionamento em Roteadores e Regiões . . . . . 62
3.8 NoC utilizada pelo CARS . . . . . . . . . . . . . . . . . . . . . . . . . . 64
3.9 Avaliação de Desempenho pelo CARS: a)No tráfego uniforme e b) No trá-
fego não uniforme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
3.10 Interface Master . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
3.11 Interface Slave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
3.12 Distribuição do Tráfego a)sem b)com aplicação da ideia do BGC . . . . . 69
3.13 Diferentes Níveis de Congestionamento em Roteadores e Quadrantes . . . 70
3.14 Escalonador Adaptativo com TIQ na Interface Slave . . . . . . . . . . . . 72
3.15 Layout de rede 6 X 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
3.16 Avaliação de desempenho: a)No tráfego uniforme e b) No tráfego não
uniforme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
3.17 Ganho de Desempenho em Cada Componente do BGC . . . . . . . . . . 75
3.18 Tamanho do Bu�er do Pacote . . . . . . . . . . . . . . . . . . . . . . . . 76
4.1 Roteadores Vizinhos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
4.2 Fluxo da Execução do Algoritmo Odd-Even Modi�cado . . . . . . . . . . 80
4.3 Plataforma In�nity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
4.4 Núcleo In�nity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
4.5 Interface de Rede In�nity Modi�cada . . . . . . . . . . . . . . . . . . . . 83
4.6 Novo Formato Pacote NoC . . . . . . . . . . . . . . . . . . . . . . . . . . 84
4.7 Sinais Utilizados para Cálculo do Congestionamento Local . . . . . . . . 85
4.8 Algoritmo OE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
5.1 Aplicação PIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
5.2 Estrutura de Teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
5.3 Roteadores Utilizados na Geração do Trafego Não-uniforme . . . . . . . . 105
LISTA DE TABELAS
2.1 Tabela comparativa de vantagens e desvantagens de sistemas com NoC. . 26
2.2 Serviços carregados por um pacote . . . . . . . . . . . . . . . . . . . . . 52
3.1 Mapeamento dos Valores de Congestionamento local e dos vizinhos da
porta de entrada em dois bits . . . . . . . . . . . . . . . . . . . . . . . . 71
3.2 Comparação entre as Abordagens Relacionadas . . . . . . . . . . . . . . 77
4.1 Exemplo de Quadro de Congestionamento . . . . . . . . . . . . . . . . . 87
5.1 Parâmetros utilizados na Rede . . . . . . . . . . . . . . . . . . . . . . . . 95
5.2 Latência Obtida com a Aplicação PIP . . . . . . . . . . . . . . . . . . . 99
5.3 Divisão dos Experimentos . . . . . . . . . . . . . . . . . . . . . . . . . . 101
5.4 Melhorias apresentadas com a utilização da estratégia em relação ao Algo-
ritmo XY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
LISTA DE GRÁFICOS
5.1 Energia Consumida pelo Algoritmo de Roteamento XY para a Aplicação
PIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
5.2 Energia Consumida pelo Algoritmo de Roteamento OE para a Aplicação
PIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
5.3 Comparação da Energia Consumida pelo Algoritmo XY e Algoritmo OE 98
5.4 Desempenho do Algoritmo XY - Tráfego Uniforme . . . . . . . . . . . . . 102
5.5 Desempenho do Algoritmo Odd-Even sem Modi�cação - Tráfego Uniforme 102
5.6 Desempenho do Algoritmo Odd-Even Modi�cado - Tráfego Uniforme . . 103
5.7 Comparação Latência Algoritmos - Tráfego Uniforme . . . . . . . . . . . 104
5.8 Desempenho do Algoritmo XY - Tráfego Não-Uniforme (Roteador 3) . . 105
5.9 Desempenho do Algoritmo Odd-Even sem Modi�cação - Tráfego Não-
Uniforme (Roteador 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
5.10 Desempenho do Algoritmo OE Modi�cado - Tráfego Não-Uniforme (Rote-
ador 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
5.11 Desempenho do Algoritmo XY - Tráfego Não-Uniforme (Roteador 10) . . 107
5.12 Desempenho do Algoritmo Odd-Even sem Modi�cação - Tráfego Não-
Uniforme (Roteador 10) . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
5.13 Desempenho do Algoritmo OE - Tráfego Não-Uniforme (Roteador 10) . . 108
LISTA DE ALGORITMOS
1 Algoritmo Odd-Even . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
2 Algoritmo de Atualização da Tabela de Congestionamento . 92
LISTA DE ACRÔNIMOS
NoC Network-on-Chip (Redes Intrachip)
SoC System-on-Chip (Sistema em um chip)
LSI Large Scale Integration (Integração em grande escala)
VLSI Very Large Scale Integration (Muita Integração em grande escala)
ULSI Ultra Large Scale Integration (Ultra Integração em grande escala)
MPSoCs Multiprocessor System-on-Chip (Multiprocessadores em sistemas em um chip)
PE Processing Elements (Elementos de Processamento)
I/O Input/output (Entrada e saída)
OSI Open Systems Interconection (Interconexão Aberta de Sistemas)
IP Intellectual Property (Propriedade Intelectual)
TLM Transaction-Level Modeling (Modelagem em nível de transação)
RTL Register Transfer Level (Nível de transferência em registrador)
Flit Flow Control Unit (Unidade de Controle de Fluxo)
Phit Physical Channel Unit (Unidade do Canal Físico)
SoCINfp System-on-Chip Interconnection Network fully parameterizable (Rede de In-
terconexão no Chip totalmente parametrizável)
PIC Peripheral Interface Controller (Controlador de Interface Periférica)
LAPIC Local Advanced PICs (Controlador de Interface Periférica local avançada)
SUMÁRIO
Capítulo 1�Introdução 20
Capítulo 2�Conceitos Básicos 23
2.1 Arquitetura dos Multiprocessadores . . . . . . . . . . . . . . . . . . . . . 23
2.2 Network on Chip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.2.1 Arquitetura de uma NoC . . . . . . . . . . . . . . . . . . . . . . . 27
2.2.1.1 Interface de Rede . . . . . . . . . . . . . . . . . . . . . . 28
2.2.1.2 Roteadores . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.2.1.3 Enlace . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.2.1.4 Mensagens e Pacotes . . . . . . . . . . . . . . . . . . . . 31
2.3 Características Gerais de uma NoC . . . . . . . . . . . . . . . . . . . . . 32
2.3.1 Topologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.3.2 Roteamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.3.2.1 Algoritmo XY . . . . . . . . . . . . . . . . . . . . . . . 35
2.3.2.2 Algoritmo NL . . . . . . . . . . . . . . . . . . . . . . . . 35
2.3.2.3 Algoritmo NF . . . . . . . . . . . . . . . . . . . . . . . . 37
2.3.2.4 Algoritmo WF . . . . . . . . . . . . . . . . . . . . . . . 38
2.3.3 Chaveamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.3.4 Controle de Fluxo . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.3.5 Arbitragem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.3.6 Memorização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.4 Plataforma MPSoC In�nity SoCIN . . . . . . . . . . . . . . . . . . . . . 42
2.4.1 Descrição da Plataforma In�nity . . . . . . . . . . . . . . . . . . . 42
2.4.2 Núcleo In�nity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
2.4.3 NoC SoCIN fp . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
2.4.3.1 Roteador ParIS . . . . . . . . . . . . . . . . . . . . . . . 47
2.4.4 Núcleo de Processamento In�nity e SoCINfp . . . . . . . . . . . . 49
2.4.4.1 Interface de Rede (NIC) . . . . . . . . . . . . . . . . . . 50
2.4.4.2 Modelo de Mensagem . . . . . . . . . . . . . . . . . . . 51
2.4.4.3 Formato de Mensagem . . . . . . . . . . . . . . . . . . . 53
2.5 Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Capítulo 3�Trabalhos Relacionados 55
3.1 CATRA - Congestion Aware Trapezoid-based Routing Algorithm for on-
Chip Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.1.1 Probabilidades de Passagem de Pacotes pelos Nós . . . . . . . . . 55
3.1.2 Estratégia de Propagação de Congestionamento . . . . . . . . . . 56
3.1.3 Métricas de Congestionamento . . . . . . . . . . . . . . . . . . . . 57
3.1.3.1 Calculando Congestionamento de Nós Vizinhos . . . . . 57
3.1.3.2 Calculando Congestionamento de Nós Distantes . . . . . 58
3.1.4 Resultados Experimentais . . . . . . . . . . . . . . . . . . . . . . 58
3.1.4.1 Análise de Desempenho - Tráfego Uniforme . . . . . . . 58
3.1.4.2 Análise de Desempenho - Tráfego com Hotspot . . . . . 59
3.1.4.3 Análise de Desempenho - Aplicação de Tráfego . . . . . 60
3.2 CARS: Congestion-Aware Request Scheduler for Network Interfaces in
NoC-based Manycore Systems . . . . . . . . . . . . . . . . . . . . . . . . 61
3.2.1 Implementação do CARS . . . . . . . . . . . . . . . . . . . . . . . 62
3.2.2 Resultados Experimentais . . . . . . . . . . . . . . . . . . . . . . 63
3.2.3 Con�guração do Sistema . . . . . . . . . . . . . . . . . . . . . . . 64
3.2.4 Avaliação de Desempenho . . . . . . . . . . . . . . . . . . . . . . 65
3.3 A Systematic Reordering Mechanism for On-chip Networks using E�cient
Congestion-aware Method . . . . . . . . . . . . . . . . . . . . . . . . . . 66
3.3.1 Interface de Rede . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
3.3.2 Método de Balanceamento Global de Congestionamento . . . . . 68
3.3.2.1 Usando a Informação de Congestionamento nos Roteado-
res Imediatos . . . . . . . . . . . . . . . . . . . . . . . . 68
3.3.2.2 Usando a Informação de Congestionamento nas Interfaces
Slaves . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
3.3.2.3 Implementação do BGC - Seleção de Saída Adaptativa . 70
3.3.2.4 Implementação do BGC - Seleção de Entrada Adaptativa 71
3.3.2.5 Implementação do BGC - Escalonador de Pedidos Adap-
tativo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
3.3.3 Resultados Experimentais . . . . . . . . . . . . . . . . . . . . . . 73
3.3.3.1 Con�guração do Sistema . . . . . . . . . . . . . . . . . . 73
3.3.3.2 Avaliação de Desempenho . . . . . . . . . . . . . . . . . 74
3.4 Comparação das Abordagens . . . . . . . . . . . . . . . . . . . . . . . . . 76
3.5 Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Capítulo 4�Uma Estratégia de Roteamento Adaptativa Baseada em Conges-
tionamento 78
4.1 Visão Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
4.2 Detalhes da Implementação . . . . . . . . . . . . . . . . . . . . . . . . . 80
4.3 Algoritmo de Roteamento Odd-Even . . . . . . . . . . . . . . . . . . . . 88
4.4 Algoritmo de Atualização da Tabela de Regiões . . . . . . . . . . . . . . 91
4.4.1 Cálculo Congestionamento - Critério de Escolha . . . . . . . . . . 91
4.5 Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Capítulo 5�Experimentos e Resultados 94
5.1 Con�guração da Plataforma In�nity . . . . . . . . . . . . . . . . . . . . . 94
5.2 Métricas Avaliadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
5.2.1 Energia Consumida . . . . . . . . . . . . . . . . . . . . . . . . . . 94
5.2.2 Latência . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
5.3 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
5.3.1 Picture in Picture . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
5.3.2 Gerador de Tráfego Uniforme e Não-Uniforme . . . . . . . . . . . 99
Capítulo 6�Conclusão 109
Referências 111
20
CAPÍTULO 1
INTRODUÇÃO
Em 1965, Gordon Moore, co-fundador da Intel, previu que o número de transistores in-
tegrados por die, que corresponde a um pedaço de material semicondutor derivado de
um wafer de silício, iria dobrar a cada ano. E nos anos subseqüentes esta estimativa
continuou, mas com o tempo um pouco maior, aproximadamente a cada 18 meses. Essa
veio a ser a de�nição da lei de Moore[1].
Como efeito desta maior integração ao longo do tempo, foi possível aumentar o desem-
penho dos processadores de duas formas: freqüência de clock e quantidade de instruções
por ciclo (IPC). Um maior desempenho foi obtido com o aumento da freqüência de clock,
pois com este crescimento, o processamento dos dados pode ser realizado em um tempo
menor. Isto só foi possível por causa do avanço da tecnologia utilizada na produção dos
componentes e da redução do caminho crítico. Já com relação ao IPC, houve um pro-
gresso no número do IPC devido ao crescimento do número de transistores por chip e
pelo avanço na tecnologia da arquitetura de computadores. Isto também permitiu que a
execução de uma aplicação ocorresse em um tempo menor. Mas no ano 2004 [2], já eram
observados limites ao progresso do desempenho de processadores, pois esta maior inte-
gração dos circuitos que proporcionou um maior desempenho, também foi o responsável
pela redução do tamanho do transistor, resultando assim em uma maior dissipação de
calor com a utilização de clocks com alta freqüência, pois o switches destes transistores
eram mais rápidos e liberavam maior calor. Desta forma, a industria de processadores
cancelou projetos que utilizavam processadores únicos, como por exemplo, a Intel que
cancelou o projeto do Pentium que teria 4GHz de freqüência de clock [2].
Uma das alternativas para continuar o progresso do desempenho dos processadores foi o
projeto de vários núcleos de processamento em um único chip (MultiProcessor System-
INTRODUÇÃO 21
on-Chip (MPSoC))[3]. Este maior número de processadores em um chip possibilitou um
aumento da capacidade de processamento. As atividades que antes eram executadas por
um único processador, nesta arquitetura são agora executadas paralelamente por um con-
junto de processadores. Este paralelismo do processamento também exigiu uma maior
velocidade na comunicação e assim, os modelos baseados em barramento, se tornaram
um gargalo para este tipo de sistema. Para mitigar este problema, foram criadas as rede
em chip (Network-on-Chip (NoC))[4].
Estas redes de comunicação possibilitam que a comunicação entre os processadores seja
concorrente, diferentemente do barramento, onde somente um componente pode acessá-lo
por vez, e assim a comunicação pode ser mais e�ciente. A estrutura física que compõe a
NoC são: roteadores e canais de comunicação. Devido ao paralelismo da comunicação,
foram adicionados os roteadores à rede para garantir que as mensagens sejam armaze-
nada sem perdas e que a informação seja encaminhada ao seu destino através dos canais
ponto-a-ponto[5]. Os roteadores possibilitaram a comunicação paralela, pois vários pro-
cessadores podem se comunicar simultaneamente. Mas, este mesmo paralelismo pode
gerar sobrecarga na rede e assim a comunicação pode ser prejudicada. Uma forma de
evitar estes congestionamentos da rede é utilizar algoritmos de roteamento e�cientes[6].
Os algoritmos de roteamento são responsáveis por fazer a escolha da porta para a qual o
roteador deverá encaminhar os pacotes. Existem duas categorias principais de algoritmos
de roteamento: determinísticos e adaptativos. Os algoritmos determinísticos fornecem
sempre o mesmo caminho entre um par origem e destino [6]. Como, por exemplo, o
algoritmo XY. Já os algoritmos adaptativos de roteamento se adaptam ao estado da rede
para selecionar rotas entre caminhos alternativos para o destino [6], como o algoritmo
Odd-Even [7]. A grande vantagem do algoritmo determinístico é que os pacotes que tra-
fegam na rede não saem de ordem e o caminho escolhido é o menor, mas estes algoritmos
são mais propensos a gerar congestionamentos. Os algoritmos adaptativos, por sua vez,
podem realizar a entrega da informação ao destino com os pacotes fora da ordem, por-
que o caminho escolhido para cada pacote depende do estado da rede e eventualmente
podem ser escolhidos caminhos que não sejam o menor, mas estes algoritmos são mais
INTRODUÇÃO 22
rápidos na entrega do pacote ao seu destino, pois para a escolha do caminho é levado em
consideração o tráfego na rede.
Neste cenário, foram realizados vários trabalhos com o intuito de reduzir a sobrecarga
na rede causada por algoritmos determinísticos e assim dar maior �uidez a comunica-
ção, como podem ser vistos nos trabalhos [4] [8] [6] [9]. Com este mesmo intuito foi
desenvolvido o presente trabalho, onde é proposto a utilização do algoritmo adaptativo
Odd-even (OE) e, como métrica para a escolha do melhor caminho no roteador, é pro-
posto a utilização da análise do congestionamento da rede baseada no estado do bu�er
de entrada de cada uma das portas do roteador e do caminho percorrido pelo pacote na
rede. Para validar este trabalho foi utilizada a plataforma In�nity que é constituída por:
processadores, memórias e uma rede em chip (NoC). Os processadores utilizados nesta
plataforma foram SparcV8 os quais são conectados a uma hierarquia de memória e a uma
interface de rede, para fazer a tradução dos sinais do processador para a rede. Finalmente
a interface de rede foi conectada a NoC SoCINfp que é constituída por roteadores ParIS
(Parametrizable Interconection Switch for Network-on-Chip) [10].
O presente trabalho conseguiu reduzir a latência de entrega do pacote em até 25% quando
comparado com a implementação do algoritmo XY e de até 23% quando comparado com a
implementação do algoritmo Odd-Even sem a análise de congestionamento, também apre-
sentou uma redução de 13,35% da energia consumida durante o processamento. Para isto,
no entanto foi necessário a adição de um bu�er de reordenação dos pacotes e a adição de
numeração em cada um destes enviados para a rede, dado que a utilização de algoritmos
adaptativos podem desordená-los. Este trabalho está estruturado da seguinte forma: no
Capítulo 2 são explicados alguns conceitos básicos que são fundamentais para o enten-
dimento geral do trabalho. Em seguida, o Capítulo 3 apresenta técnicas relacionadas à
técnica proposta. No Capítulo 4, a abordagem proposta neste trabalho e sua formalização
são apresentadas e no Capítulo 5, são apresentados os resultados e experimentos reali-
zados para validação da proposta. O Capítulo 6 conclui o trabalho e propõe trabalhos
futuros.
23
CAPÍTULO 2
CONCEITOS BÁSICOS
Neste capítulo serão explanados conceitos técnicos para o entendimento geral do traba-
lho. Desta forma, nas próximas seções serão analisados: Plataforma MPSoC, Plataforma
baseada em NoC e a Plataforma MPSoC In�nity que foram utilizados no desenvolvimento
do projeto.
2.1 ARQUITETURA DOS MULTIPROCESSADORES
Em 1966, Flynn propôs um modelo simples para categorizar todos os processadores. Para
isto, ele observou o paralelismo no �uxo de instrução e dados exigido no componente mais
restrito do multiprocessado e enquadrou os computadores em quatro categorias [11]:
1. Fluxo de instrução único, �uxo de dados únicos - SISD - esta é a categoria
do uniprocessador, ou seja, que tem somente uma unidade de processamento central;
2. Fluxo de instrução único, �uxos de dados Múltiplos - SIM - a mesma
instrução é executada em múltiplos processadores que usam diferentes �uxos de
dados. Existe somente um processador de controle e uma memória de instrução,
mas cada processador tem uma memória de dados. Um exemplo desta categoria
são os processadores com arquitetura vetorial;
3. Fluxo de instrução múltiplos, �uxos de dados único - MISD - não existem
computadores comerciais deste tipo;
4. Fluxo de instrução múltiplos, �uxos de dados múltiplos - MIMD - cada
processador obtém suas próprias instruções e opera sobre seus próprios dados.
2.1 ARQUITETURA DOS MULTIPROCESSADORES 24
O sistema multiprocessado estão classi�cados na categoria 4, os MIMD. Estes siste-
mas estão divididos em duas classes, dependendo do número de processadores envolvidos,
que por sua vez, exigem uma organização de memória e estratégia de interconexão.
A primeira classe pode ser chamada de arquiteturas centralizadas de memórias com-
partilhadas, o qual possui no máximo, algumas dezenas de processadores[11]. Como a
quantidade de processadores é pequena, eles podem compartilhar uma mesma memória.
Como existe uma única memória principal que possui relacionamento simétrico com todos
os processadores e um tempo de acesso uniforme a partir de qualquer processador, estes
multiprocessadores são conhecidos por multiprocessadores simétricos (memória compar-
tilhada) (SMPs). Este estilo de arquitetura as vezes é denominado de acesso uniforme
à memória (UMA), pois os processadores sofrem a mesma latência a partir da memória,
mesmo que ela esteja divida em bancos.
A segunda classe é formada pelos processadores com memória distribuída �sicamente.
Com o objetivo de dar maior suporte à grande quantidade de processadores, a memória
precisa ser distribuída entre estes, obtendo-se assim maior largura de banda da memó-
ria sem grandes perdas com latência no tráfego do dado[11]. Este tipo de arquitetura
tem duas grandes vantagens; ser a forma mais econômica de escalar a largura da banda
de memória, desde que a maior parte dos acessos sejam na memória local e, permitir a
redução da latência para o acesso a memória local. A desvantagem desta classe é que
a comunicação entre os processadores se torna mais complexa e é necessário um esforço
maior no software para se tirar proveito da largura de banda. Como pode ser visto nos
parágrafos acima, cada arquitetura possui um sistema de memória, na primeira classe do
MIMD a memória é compartilhada simétrica conhecida como memória de acesso uniforme
Uniform Memory Acess - UMAs, como pode ser visualizado na imagem 2.1.
Observe na imagem 2.1 que a distância entre um processador e a memória é simétrico
e assim o acesso a memória tem a mesma latência para todos os processadores do sistema.
Já na segunda classe as memórias estão distribuídas em cada processador e seu acesso
ocorre de forma diferente do anterior, pois as memórias separadas �sicamente podem ser
endereçadas como um espaço logicamente compartilhado. Isto signi�ca dizer que uma
2.1 ARQUITETURA DOS MULTIPROCESSADORES 25
Figura 2.1 Estrutura de um Multiprocessado com Memória Compartilhada Centralizada
referência de memória pode ser realizada por qualquer processador a qualquer lugar da
memória, desde que o processador tenha permissão para acessá-la. Estes são os multipro-
cessadores com memória compartilhada distribuída (DSM). Os multiprocessadores DSM
também são conhecidos como os de acesso de memória não uniforme NUMAs (Nonuni-
form Memory Acess), pois o tempo de acesso depende do local de uma palavra de dados
na memória [11]. Esta arquitetura pode ser visualizado na �gura 2.2.
Figura 2.2 Estrutura de Multiprocessado com Memória Distribuída
Pode-se visualizar na imagem que cada processador possui sua hierarquia de memória,
diferentemente do modelo anterior onde existia uma única memória. Outra diferença se
encontra na forma em que os multiprocessadores são interconectados entre si. Observe
que no modelo SMP os processadores são interconectados através de um barramento, o
que não acontece no sistema CMP, desde que eles utilizam uma rede de interconexão,
e isto favorece a escalabilidade do sistema. Mas esta mesma distribuição que permitiu
2.2 NETWORK ON CHIP 26
grandes avanços, também proporcionou um aumento da latência de acesso aos dados que
não estão na memória local, pois agora, depende do processador em que se encontra o
dado na memória.
2.2 NETWORK ON CHIP
NoC é uma rede que permite a comunicação simultânea entre processadores conectados
com maior escalabidade que o barramento, pois aumentando o número de componentes do
sistema, a comunicação não é degradada. A comunicação ocorre ponto-a-ponto e permite
que dois ou mais processadores enviem informações para a rede simultaneamente. Bjer-
regaard [12] faz um comparativo de algumas vantagens e desvantagens entre a utilização
de NoC ou barramento. Essas informações podem ser visualizadas na Tabela 2.1.
Tabela 2.1 Tabela comparativa de vantagens e desvantagens de sistemas com NoC.Barramento NoC
− Cada unidade de processamento ane-xada ao barramento adiciona capacitânciaprejudicando o desempenho elétrico
+ Aumento do número de processadoresnão prejudica tanto o desempenho indivi-dual de cada processador
− Temporização do barramento é maiscomplexa
+ Utilização das vias podem ocorrer aomesmo tempo
− A arbitragem se torna um gargalo à me-dida que cresce o número de processadores
+ Decisões de roteamento podem ser dis-tribuídas
− Para cada tamanho de rede o barra-mento tem que mudar
+ O mesmo roteador por ser utilizadopara qualquer tamanho de rede
− Testar o barramento é mais lento e com-plexo
+ Mais rápido e fácil de testar
− Largura de banda é limitada e divididaentre as unidades anexadas
+ Largura de Banda aumenta com tama-nho da rede
+ Uma vez que o árbitro tenha garantidocontrole, a latência é conhecida e pequena
− Congestionamento interno pode aumen-tar a latência da comunicação
+ Compatível com a maioria dos multi-processadores
− Em geral, os multiprocessadores preci-sam de adaptação e sincronização
+ Os conceitos são simples e já bem di-fundidos
− Reeducação para novos paradigmas deprogramação com comunicação explícitaentre processos concorrentes
Observando a tabela é possível notar que quanto ao número de processadores conecta-
2.2 NETWORK ON CHIP 27
dos, a NoC permite aumentar o número de processadores sem que haja uma degradação
do desempenho individual, e o mesmo roteador pode ser utilizado para qualquer quanti-
dade de processadores. Por outro lado, uma arquitetura com barramento, a inclusão de
um novo processador provoca o aumento da capacitância elétrica degradando o desem-
penho elétrico do sistema, sem contar que, aumentando-se o número de processadores,
o barramento deverá ser modi�cado para comportar este novos processadores. Quanto
ao �uxo da mensagem, o barramento possui uma temporização mais complexa, já que
ele tem que coordenar toda a comunicação de todos os processadores, e a arbitragem vai
aumentando a complexidade quanto maior forem o número de processadores conectados
a ele. Já a NoC, que possui os roteadores para fazer o roteamento da mensagem, a arbi-
tragem é distribuída e a utilização das vias podem ocorrer simultaneamente. Quanto a
largura de banda, a NoC, ao aumentar o tamanho da rede, também aumenta a largura de
banda, embora não seja na mesma proporção. No barramento, a largura de banda é única
e é dividida entre os processadores. Quanto a latência, para o barramento depois que o
árbitro garantiu o controle, a latência da comunicação é pequena, enquanto que na NoC o
congestionamento interno pode aumentar a latência da comunicação. A compatibilidade
do barramento é maior, já que são simples e bem difundidos, enquanto que para uma
NoC, é necessário uma adaptação e sincronização do componente que será adicionado à
rede e, como a rede é distribuída e concorrente, é necessário também, uma reeducação
para os novos paradigmas de programação. Observe que para sistemas com muita co-
municação e com vários componentes, a NoC é a melhor opção e a integração desta com
MPSoC é bem simples, pois será necessário adicionar somente a rede e uma interface
de rede que realize a tradução dos sinais do processador para o formato de pacotes que
possam trafegar na rede.
2.2.1 Arquitetura de uma NoC
O sistema de camadas de rede OSI pode ser facilmente adaptado para a NoC. Assim, a
arquitetura da NoC está dividida em quatro camadas, como pode ser observado na �gura
2.3.
2.2 NETWORK ON CHIP 28
Figura 2.3 Arquitetura NoC 1
Analisando a NoC, observa-se que esta foi subdivida nas camadas: sistema, interface
de rede, rede, enlace e física. A camada do sistema engloba as aplicações e arquitetura.
Nesta camada os detalhes da implementação da rede não são visíveis. A camada de
interface de rede interliga a camada de sistema à camada de rede. Já a camada de
rede consiste em roteadores. A camada de enlace lida com a sincronização, codi�cação e
con�abilidade [12]. Finalmente a camada física é consiste na conexão entre roteadores.
Cada um dos componentes destas camadas será apresentado com mais detalhes a seguir.
2.2.1.1 Interface de Rede
A interface de rede tem como objetivo servir de interface entre o processador e a rede
e tornar os serviços de comunicação transparentes para o processo. A interface de rede
possui duas formas de comunicação: o back-end e o front-end. O front-end é responsá-
vel pelas funções de comunicação com core, tanto para envio quanto para recepção de
mensagens. Este encapsulamento permite a reutilização de multiprocessadores, pois mu-
dando o multiprocessado basta modi�car somente esta camada. Já a camada back-end
é responsável pelos serviços de comunicação de alto nível da camada de transporte, tais
como: transferências de dados con�áveis, seqüenciais e orientadas à Quality of service
(QoS) [13].
2.2 NETWORK ON CHIP 29
2.2.1.2 Roteadores
Os roteadores são responsáveis por transmitir os dados pela NoC e possuem mecanismos
de comunicação necessários para esta transferência [13]. A maior parte dos roteadores de
alto desempenho implementa uma rede de interconexão (crossbar) para oferecer conec-
tividade sem bloqueio dentro do roteador, permitindo assim conexões simultâneas entre
múltiplos pares de portas de entrada-saída. Podem ser utilizados bu�ers para pacotes
bloqueados, utilizando-se FIFOS ou �las circulares. Estas �las podem ser colocadas em
portas de entrada (roteadores com bu�er de entrada), portas de saída (roteador com
bu�er de saída), centralmente dentro do roteador (roteador com bu�er central) ou em
ambas as portas de entrada e saída (roteador com bu�er de entrada-saída) [11]. A �gura
2.4 apresenta a estrutura interna de um roteador, onde é possível visualizar os bu�ers de
entrada e saída, é um roteador com bu�er de entrada e saída.
O roteamento pode ser implementado utilizando uma máquina de estado �nito (Finity
State Machine - FSM ) ou tabela de encaminhamento dentro da unidade de controle de
roteamento do roteador. No primeiro caso, a informação e roteamento dada no cabeçalho
do pacote é processada pela FSM que determina a porta de saída permitida no roteador
(ou portas, se o roteamento for adaptativo), de acordo com o algoritmo de roteamento
utilizado. Quando o roteamento é implementado utilizando as tabelas de encaminha-
mento, a informação de roteamento que está no cabeçalho do pacote é utilizada como
um endereço para acessar uma entrada da tabela de encaminhamento, que contém as
portas de saída permitidas no roteador, baseado no algoritmo de roteamento. As tabelas
de encaminhamento precisam ser pré-carregadas nos roteadores no começo da operação
da rede. Esta unidade de controle de roteamento normalmente é implementada como um
recurso centralizado, embora possa ser replicada em cada porta de entrada, de modo a
não se tornar um gargalo. Observe na �gura 2.4 que o bloco inferior é a parte do roteador
que realiza o roteamento por máquina de estado ou tabela de encaminhamento, o controle
de roteamento e arbitragem e ela é centralizada [11].
A arbitragem é necessária quando dois ou mais pacotes solicitam simultaneamente a
2Fonte: Hennessy e Patterson [11]
2.2 NETWORK ON CHIP 30
Figura 2.4 Estrutura Interna de um Roteador 2
mesma porta de saída. Esta arbitragem pode ser desenvolvida de duas formas: centrali-
zada ou distribuída. No primeiro caso, todas as solicitações e informações de status são
transmitidas para a unidade central de arbitragem do roteador, já no segundo caso, o
árbitro é distribuído pelo roteador, normalmente entre as portas de entrada e/ou saída.
A unidade de arbitragem pode ser visualizada na �gura 2.4 juntamente com o controle
de roteamento [11].
A arquitetura interna do roteador da imagem 2.4 funciona da seguinte maneira: quando
um pacote começa a chegar em uma porta de entrada do roteador, o controlador de link
decodi�ca o sinal que chega e gera uma seqüencia de bits, possivelmente retirando a seri-
alização dos dados para adaptá-los à largura do caminho de dados interno se for diferente
da largura do link externo. As informações são retiradas do cabeçalho do pacote ou dos
sinais de controle do link para determinar a �la à qual o pacote pertence no bu�er. À
medida que o pacote estiver sendo recebido e colocado no bu�er (ou depois que o pacote
inteiro estiver no bu�er, dependendo da técnica de comutação de pacotes), o cabeçalho
é enviado à unidade de roteamento. Essa unidade fornece uma solicitação para uma ou
mais portas de saída à unidade de arbitragem. A Arbitragem, por sua vez, solicita a porta
de saída e, caso a porta esteja livre e com espaço em bu�er, os recursos são alocados e o
pacote será transferido pelo crossbar interno até o bu�er de saída correspondente e en-
lace, se o enlace (link) estiver livre e não existir nenhum pacote na frente. O controlador
do enlace é responsável por impedir o estouro da �la de saída no roteador vizinho, que
2.2 NETWORK ON CHIP 31
corresponde ao roteador que está conectado ao roteador em questão, no outro extremo
do enlace [11].
2.2.1.3 Enlace
O enlace corresponde a ligação entre roteadores ou entre roteadores ao multiprocessado.
Geralmente, os enlaces são full-duplex, ou seja, os dados podem ser transmitidos simul-
taneamente em ambos os sentidos, desta forma a transmissão é bidirecional. Como pode
ser observado no tópico anterior, o enlace é responsável pelo transporte e regulação do
tráfego de uma mensagem [13].
2.2.1.4 Mensagens e Pacotes
A comunicação entre os processadores de uma NoC se dá através do envio de mensagens,
desta forma os terminais da rede se comunicam enviando e recebendo mensagens. Mas
para que a mensagem possa trafegar na rede é necessário que ela seja dividida em pacotes
menores, pois o tamanho da mensagem é superior a largura de banda do enlace, dado que
a mensagem tem tamanho variado. Desta forma, cada pacote que compõe uma mensagem
é composto das seguintes partes:
� Header (cabeçalho) - possui as informações para rotear a mensagem através da rede;
� Payload (carga útil) - possui os dados da mensagem e tem tamanho variável.
� Trailer (terminador) - indica o término da mensagem e pode ter informações para
detecção de erros.
Na �gura 2.5 pode ser visualizada a estrutura de um pacote.
Observe que o payload pode variar de tamanho dependendo da implementação do
projeto. O trailer é a última parte do pacote, mas ela também transporta parte da
mensagem (carga útil). Desta forma, o trailer é a última parte do payload [10].
2.3 CARACTERÍSTICAS GERAIS DE UMA NOC 32
Figura 2.5 Partes que compõe um pacote
2.3 CARACTERÍSTICAS GERAIS DE UMA NOC
Uma NoC pode ser descrita por uma ou várias de suas características, entre as quais
destaca-se a topologia, estratégia utilizada para roteamento, �uxo de controle, rotea-
mento, arbitragem ou memorização [5]. Cada uma destas características serão detalhadas
a seguir.
2.3.1 Topologia
Desde que o sistema de interconexão da NoC substituiu o sistema tradicional de barra-
mento, várias topologias têm sido propostas. Muitas delas adaptadas às necessidades dos
sistemas embarcados para sistemas multiprocessadores em paralelo [14]. Topologia cor-
responde à forma pela qual os roteadores estão interconectados. Esta pode ser dividida
em duas classes principais: as redes diretas e as redes indiretas. Nas redes diretas, cada
roteador tem uma ligação direta ponto a ponto com um determinado número de vizinhos
e as mensagens trocadas entre dois elementos não vizinhos precisam passar por um ou
mais elementos intermediários, mas esta comunicação só envolve os roteadores da rede.
As redes deste tipo mais utilizadas são: do tipo malha 2D, toroide 2D e hipercubo 3D
[13]. As �guras 2.6, 2.7, 2.8 ilustram estas topologias:
3Fonte: Hennessy e Patterson [11]4Fonte: Hennessy e Patterson [11]5Fonte: Hennessy e Patterson [11]
2.3 CARACTERÍSTICAS GERAIS DE UMA NOC 33
Figura 2.6 Rede Malha 2D 3
Figura 2.7 Rede Toroide 2D 4
Figura 2.8 Rede Hipercubo 3D 5
2.3 CARACTERÍSTICAS GERAIS DE UMA NOC 34
Na topologia malha 2D, todos os nós de cada dimensão formam um array linear. Na
topologia toroide 2D, todos os nós de cada dimensão formam um anel. Já a topologia
hipercubo 3D é um caso especial da rede malha 2D, onde somente dois nós são interco-
nectados ao longo de cada dimensão [15]. Nas redes indiretas, os roteadores não estão
acoplados as unidades de processamento, cada roteador possui um conjunto de portas
bidirecionais para ligações com outros roteadores e somente alguns roteadores possuem
conexão com as unidades de processamento. As redes mais utilizadas são: estrela e árvore
[13]. As �guras 2.9 e 2.10 apresentam estas topologias.
Figura 2.9 Rede Árvore 6
Figura 2.10 Rede Estrela 7
6Fonte: Hennessy e Patterson [11]7Fonte: Hennessy e Patterson [11]
2.3 CARACTERÍSTICAS GERAIS DE UMA NOC 35
2.3.2 Roteamento
O algoritmo de roteamento de�ne qual o caminho da rede, ou caminhos, são permiti-
dos para cada pacote. De qualquer forma, alguns caminhos providos pela topologia de
rede podem não ser permitidos pelo algoritmo de roteamento para garantir que todos
os pacotes sejam entregues, evitando assim deadlocks e livelocks [15]. Os algoritmos de
roteamento mais utilizados são: XY, NL (North Last), NF (Negative First), WF(West
First) e OE (Odd-Even). O algoritmo XY é um algoritmo determinístico, já os algoritmos
NF, NL, WF e OE são algoritmos parcialmente adaptativos. Todo algoritmo de rotea-
mento tem como objetivo o tráfego de uma mensagem de um ponto de origem, que será
chamado de nó fonte (Source), até um ponto destino, que será chamado de nó destino
(Target). Este pontos serão representados pelas notações (XS,YS) e (XT ,YT ) na análise
dos algoritmos que será realizada a seguir.
2.3.2.1 Algoritmo XY
O algoritmo XY é determinístico, ou seja, dada uma certa entrada do algoritmo, ele
produzirá sempre a mesma saída. O funcionamento é dado da seguinte forma: os �its
de um pacote são primeiramente roteados na direção X até que cheguem à coordenada
XT , em seguida são roteados na direção Y até que cheguem à coordenada YT [16], como
apresenta a �gura 2.11.
Caso alguma porta esteja em uso por outro pacote, os �its permanecem bloqueados
na porta até que o caminho seja liberado. Observe que se vários �its precisarem passar
pelo mesmo caminho, haverá congestionamento da rede.
2.3.2.2 Algoritmo NL
O algoritmo North-last é um algoritmo parcialmente adaptativo, pois ele, para algumas
direções do roteamento, observa se existe congestionamentos na rede. O funcionamento
do algoritmo pode ser descrito da seguinte forma: Caso YT ≥ YS, os pacotes são rote-
8Fonte: Carara [16]
2.3 CARACTERÍSTICAS GERAIS DE UMA NOC 36
Figura 2.11 Algoritmo XY8
ados deterministicamente como no algoritmo XY. Este comportamento é representado
na �gura 2.12 nos casos 1 e 4. Caso YT < YS os pacotes podem ser roteados de forma
adaptativa nas direções leste, oeste ou sul, como apresenta a �gura 2.12 nos casos 2 e 3
[16].
Figura 2.12 Algoritmo NL 9
Nesta �gura, os traços que estão posicionados ao lado do roteador representam os
congestionamentos da rede. Observe que neste caso para os pacotes que possuem a
coordenada Y de destino com um valor menor que a coordenada Y da origem (YT < YS),
9Fonte: Carara [16]
2.3 CARACTERÍSTICAS GERAIS DE UMA NOC 37
os pacotes são roteados de forma adaptativa e assim consideram os congestionamentos da
rede, mas para os demais casos ainda enfrentam a sobrecarga da rede devido a utilização
do algoritmo XY.
2.3.2.3 Algoritmo NF
Este algoritmo também é parcialmente adaptativo, pelo mesmo motivo do algoritmo
anterior. O funcionamento deste algoritmo pode ser descrito da seguinte forma: pri-
meiramente os pacotes são roteados nas direções negativas, isto é, para as direções sul
e oeste[16]. Caso (XT ≤ XS e YT ≥ YS) ou (XT ≥ XS e YT ≤ YS), então os pacotes
são roteados deterministicamente, como mostra a �gura 2.13 nos casos 1 (endereço fonte
(3,4) e destino (0,7)) e 3 (endereço fonte (3,7) e destino (6,5)). Todos os demais casos
permitem que o roteamento seja adaptativo, como apresenta a �gura 2.13 para os casos
2 e 4. Observe que os traços que estão posicionados ao lado dos roteadores na imagem
representam os congestionamentos da rede.
Figura 2.13 Algoritmo NF 10
Note que para alguns casos deste algoritmo a forma de roteamento é correspondente
ao algoritmo XY, desta forma a sobrecarga de rede não é evitada.
10Fonte: Carara [16]
2.3 CARACTERÍSTICAS GERAIS DE UMA NOC 38
2.3.2.4 Algoritmo WF
O algoritmo West-First também é um representante dos algoritmos parcialmente adap-
tativos, pelo mesmo motivo dos algoritmos anteriores. Seu funcionamento pode ser ana-
lisado da seguinte forma: Caso XT ≤ XS, os pacotes são roteados deterministicamente,
fazendo uso dos algoritmos XY, como apresenta a �gura 2.14 nos casos 1 e 2. Caso
XT > XS, os pacotes podem ser roteados de forma adaptativa nas direções leste, norte e
sul, como mostra a �gura 2.14 nos casos 3 e 4 [16].
Figura 2.14 Algoritmo WF 11
Observe que os traços ao lado do roteador na imagem representam os congestiona-
mentos da rede. Note que ainda é feito o uso do algoritmo XY em vários casos, por isto
não é possível evitar totalmente a sobrecarga da rede.
2.3.3 Chaveamento
Chaveamento é o mecanismo utilizado para determinar como uma mensagem é trans-
ferida da entrada de um roteador para uma de suas saídas. Este pode ser classi�cado
de duas formas: chaveamento por circuito ou chaveamento por pacote. O chaveamento
por circuito é baseado no estabelecimento de um caminho completo entre a origem e
11Fonte: Carara [16]
2.3 CARACTERÍSTICAS GERAIS DE UMA NOC 39
o destino, por onde a mensagem será enviada. Esse caminho é liberado depois que o
terminador da mensagem passa pelo caminho. Assim este tipo de chaveamento por ser
dedicado reduz o tempo de entrega da informação. Mas, caso o caminho esteja ocupado,
este tipo de chaveamento não permite que a mensagem seja enviada, propiciando o surgi-
mento de congestionamentos. Outra desvantagem deste tipo de chaveamento é que caso
uma das partes envolvidas na comunicação tenha problemas, há a quebra da conexão.
Já no chaveamento por pacote, nenhum caminho é reservado, em vez disso, os pacotes
são encaminhados para os roteadores, usando as informações contidas no pacote, como
cabeçalho que pode ter bits de veri�cação da integridade, payload e terminador, onde
pode ser realizada a veri�cação cíclica de redundância. Mas, os roteadores que utilizam
este tipo de chaveamento armazenam os pacotes antes de os enviarem para o próximo
roteador. Por não exigir um estabelecimento de um circuito dedicado, este tipo de chave-
amento possui menores custos e também não há o problema de quebra de conexão. Mas,
por dividir a mensagem em partes menores e não ter que estabelecer uma comunicação
previamente, os pacotes poderão seguir caminhos distintos, e desta forma podem não
chegar em ordem. São exemplos deste tipo de chaveamento: Store-and-Foward (SAF),
Virtual-Cut-Through (VCT) e Wormhole [13]. No método Store-and-foward (SAF), um
roteador recebe um pacote, armazena-o em seu bu�er, identi�ca o destino da mensagem,
escolhe uma porta de saída com base em algum algoritmo de roteamento e repassa o
pacote adiante para um roteador destino. Como este chaveamento armazena o pacote
e posteriormente repassa ao destino, este chaveamento �cou conhecido como armazena-
e-repassa (store-and-foward). Devido ao fato de somente alocar os recursos necessários
para avançar de nó para nó na rede, este método causa uma sobrecarga adicional à co-
municação, pois cada um dos pacotes deve transportar um cabeçalho de endereçamento
e os roteadores tem um overhead para efetuar o roteamento individual de cada pacote.
Outra desvantagem é o aumento da latência da comunicação de acordo com o tamanho do
pacote, pois o pacote só é repassado após ter sido completamente recebido. Além disto,
são necessários bu�ers em todos os roteadores para manter os pacotes inteiros, o que
aumenta o custo da rede [17]. O chaveamento Virtual-cut-through (VCT) foi proposto
2.3 CARACTERÍSTICAS GERAIS DE UMA NOC 40
como um aperfeiçoamento do método store-and-foward. Sua vantagem em relação ao mé-
todo anterior é que ele só armazena o pacote inteiro no roteador quando o canal a que se
destina o pacote está ocupado. Isto reduz a latência da comunicação quando o canal não
está ocupado, pois, neste caso, o pacote é imediatamente repassado, não sendo necessário
seu armazenamento. Na técnica anterior, mesmo quando o canal está disponível o pacote
deve ser armazenado inteiramente para, só então, ser transmitido. A desvantagem do
VCT é a necessidade de se introduzir bu�ers para armazenar todo o pacote, quando o ca-
nal está ocupado. No pior caso, quando a rede está muito carregada, o VCT se comporta
como o chaveamento store-and-foward [17]. O chaveamento Wormhole é uma variação do
chaveamento Virtual-cut-through e possui como objetivo reduzir a quantidade de bu�ers
necessários para manter os pacotes bloqueados na rede. Neste método o pacote é dividido
em unidades menores, os �its. Um �it (�ow control unit) corresponde a menor unidade
sobre o qual o controle de �uxo é realizado. Estes são transmitidos entre os roteadores
intermediários até o destino. Este chaveamento pode ser visto como um pipeline, onde
os �its de cabeçalho, que contém as informações sobre o destino, se movem pela rede
seguidos pelos �its de dados (payload). Quando os �its de cabeçalho são bloqueados,
os �its de payload do pacote ocupam as �las dos roteadores intermediários. Um pacote
deve atravessar completamente um canal antes de liberá-lo para outro pacote. Essa é uma
das principais desvantagens desse método, pois a probabilidade de ocorrer um deadlock é
maior. No entanto, essa limitação pode ser contornada com o uso de canais virtuais, onde
múltiplos canais lógicos compartilham um único canal físico. A vantagem deste método
é que a latência não depende diretamente da distância, como os métodos anteriores, mas
basicamente do tráfego entre as chaves de origem e destino. Outra vantagem é a redução
de �las nos roteadores intermediários, que não precisam armazenar o pacote inteiro, o
que favorece a construção de roteadores pequenos e rápidos. A desvantagem do método é
a contenção de recursos causado pelo bloqueio do pacote, onde os canais �cam alocados
para uma mensagem até que o último �it passe [17].
2.3 CARACTERÍSTICAS GERAIS DE UMA NOC 41
2.3.4 Controle de Fluxo
Este mecanismo é responsável por decidir o que deve ser realizado com um determinado
pacote no caso de um recurso requisitado já está sendo utilizado (colisão de recurso)[18].
Esta alocação é necessária para evitar a perda indesejada de dados enviados de um emissor
a um receptor, já que a NoC não descarta pacotes (rede lossless). Este controle é realizado
no nível de enlace, e para cada porta do roteador deve existir um bu�er para o arma-
zenamento do dado que será transmitido. As técnicas básicas de controle de �uxo são:
handshake, slack bu�er, baseado em crédito e canais virtuais [13]. O protocolo handshake
utiliza sinais que avisam a intenção do emissor enviar dados na rede e sinalizam a dis-
ponibilidade de recursos na rede para a recepção e transmissão destes dados. O controle
de �uxo baseado em Slack-bu�ers é baseado em um sinal de controle no nível do bu�er,
que avisa quando este se encontra cheio ou vazio. Esta sinalização é utilizada para avisar
ao emissor a possibilidade de enviar dados na rede ou não. No controle de �uxo baseado
em canais virtuais os bu�ers de entrada associados aos canais físicos dos roteadores são
chaveados formando �las de profundidade menor alocadas independentemente umas das
outras. Estas �las são denominadas canais virtuais e servem para solucionar problemas
de colisão de recursos no caso do chaveamento por pacote wormhole. O controle de �uxo
baseado em créditos realiza o controle da seguinte forma: primeiro o receptor envia a
informação de créditos relativos ao espaço para recepção de dados disponíveis no bu�er;
depois o emissor envia toda a informação, dentro dos limites impostos pela informação
de créditos obtida; �nalmente a informação de crédito é decrementada com a recepção
da mensagem [18].
2.3.5 Arbitragem
O algoritmo de arbitragem determina quando um caminho requisitado pela rede estará
disponível para os pacotes. Árbitros aumentam os recursos livres para as requisições de
pacotes na rede. Quando nem todas as requisições podem ser servidas ao mesmo tempo,
os árbitros dos roteadores resolvem os con�itos concedendo portas de saída a pacotes de
2.4 PLATAFORMA MPSOC INFINITY SOCIN 42
forma justa de tal forma que starvation de requisição de recursos pelos pacotes sejam
prevenidos [15].
2.3.6 Memorização
O mecanismo de memorização deve estar disponível em todos os roteadores que possuem
a técnica de chaveamento por pacote, porque eles devem ser capazes de guardar as men-
sagens destinadas a uma saída que, por algum motivo, em um determinado tempo, está
sendo utilizada por outra mensagem e que, então, deve aguardar pela liberação da saída
para evitar a perda da informação recebida [13]. A memorização pode ser realizada de
forma centralizada e compartilhada, na entrada ou na saída. Um bu�er central é utili-
zado para armazenar os pacotes bloqueados de todas as portas de entrada do roteador.
No caso de memorização na entrada, são utilizados bu�ers independentes entre si nas
portas de entrada do roteador. No caso de uma memorização na saída, os espaços de
memorização são divididos entre as portas de saída.
2.4 PLATAFORMA MPSOC INFINITY SOCIN
A plataforma escolhida para o desenvolvimento deste projeto foi um plataforma híbrida
formada pelo núcleo de processamento da plataforma In�nity conectada à NoC SoCInfp.
Para o entendimento deste projeto é fundamental entender o ambiente onde as modi�ca-
ções foram aplicadas. A seguir estes conceitos são apresentados com detalhes.
2.4.1 Descrição da Plataforma In�nity
A plataforma In�nity é uma plataforma MPSoC baseada em NoC desenvolvida em Sys-
temC e que simula o comportamento de um sistema embarcado distribuído, cujos elemen-
tos estão implementados no nível de Transaction-level modeling (TLM), tanto a unidade
de processamento, o multiprocessado, quanto a rede, a NoC. O nome In�nity vem da
ideia de que esta plataforma deve dar suporte a um número in�nito de núcleos, ou seja, a
2.4 PLATAFORMA MPSOC INFINITY SOCIN 43
plataforma deve ser con�gurável e escalável. Desta forma, as soluções de interconexão, de
coerência de dados e etc., foram desenvolvidos pensando na escalabilidade do ambiente
[19]. A �gura 4.3 apresenta a estrutura da plataforma In�nity.
Figura 2.15 Plataforma In�nity 12
Pela �gura é possível veri�car que a plataforma é composta por: núcleos de proces-
samento, na imagem ela está representada pelos cores; um controlador avançado pro-
gramável de interrupção (APIC - sigla em inglês); periféricos (DMA, Timer e UART) e
pela NoC. O núcleo de processamento é formado pelo processador SparcV8, barramento
de interrupção do processador e de periféricos, sistema de hierarquia de memória e um
banco de memória. O processador SparcV8 (processador Scalable Processor Architecture)
foi modi�cado nas instruções de LOAD e STORE. Esta modi�cação foi necessária para
que o processador desse suporte a acessos a memória com tempo de acesso não uniforme
(NUMA). O barramento exclusivo de interrupções garante uma maior escalabilidade ao
sistema com o tempo de resposta por interrupção conhecido. Cada núcleo de processa-
mento possui um barramento de periféricos conectado diretamente ao processador, onde
todos os periféricos (TIMER e UART) estão conectados e mapeados em memória. O
sistema de hierarquia de memória tem como única restrição a de ter pelo menos um nível
de cache para a análise de coerência dos dados. A coerência é realizada com a utilização
de diretórios, sendo um para cada banco de memória. Os diretórios armazenam o estado
12Fonte: Aziz [19]
2.4 PLATAFORMA MPSOC INFINITY SOCIN 44
e a localização dos dados por ele gerenciados. Por �m, cada núcleo possui seu banco de
memória que, em conjunto com os outros bancos, formam a memória do sistema, for-
mando um endereço global para os bancos. A cache L2 e a memória são compartilhadas
por todos os núcleos através da NoC[19]. Como o objetivo da plataforma é escalabilidade,
a forma de comunicação entre os núcleos de processamento é realizado através de uma
NoC. Esta rede possui arquitetura mesh. Além disso, cada roteador é conectado a um
núcleo de processamento para o qual os dados são destinados. O algoritmo de roteamento
utilizado aqui é o algoritmo XY e o chaveamento é realizado por pacote (wormhole).
2.4.2 Núcleo In�nity
O elemento de processamento da plataforma é representado pelo núcleo In�nity, o qual é
um processador de Reduced Instruction-Set Computer (RISC) de 32 bits, com arquitetura
aberta, desenvolvida pela Sun Microsystem. A plataforma possui várias ferramentas
disponíveis, como, por exemplo, o compilador C (GNU Compiler Collection (GCC)), que
facilita a compilação das aplicações para este processador [13]. Este núcleo tem como
principais características:
1. Arquitetura de comunicação independente entre os núcleos. Em outras palavras,
ele dá suporte a todas as arquiteturas de NoC ou barramentos;
2. As interrupções são independentes por núcleo, isto é possível, por causa da exis-
tência de um barramento exclusivo para interrupção, com gerenciamento das inter-
rupções emitidas pelos núcleos. Cada núcleo possui um controlador de interrupções
local o Local Advanced PIC (LAPIC), com 16 registradores de prioridade e regis-
trador de máscara, ligado ao I/O Advanced PIC. Com esta con�guração, é possível
ter a habilitação de uma interrupção individual para cada controlador;
3. Suporte a periféricos, dado por meio de um barramento de periféricos conectado
diretamente ao núcleo, e um controlador de interrupções de E/S Advanced PIC
como o controlador central de interrupções;
2.4 PLATAFORMA MPSOC INFINITY SOCIN 45
4. Suporte a sistemas operacionais, com região crítica (lock) por hardware e gerenci-
amento de memória;
5. Novas instruções de Load e Store para suportar o acesso não uniforme à memória.
6. Modelo de coerência de cache baseado em diretório; este modelo foi desenvolvido
com base no modelo descrito por [11].
2.4.3 NoC SoCIN fp
Esta é uma rede escalável baseada em uma arquitetura parametrizável de roteador, para
ser utilizada na síntese de sistemas que utilizam NoCs. A rede SoCINfp (SoC Intercon-
nection Network fully parameterizable) é uma rede baseada nas topologias ortogonais 2D
(por exemplo, grelha e tori). O roteador que a constitui possui 5 portas e utiliza o cha-
veamento por pacote wormhole. Os pacotes são transferidos sem perdas e os algoritmos
de roteamento são limitados à aqueles que podem ser usados em redes com topologia
ortogonal 2D. As mensagens são enviadas por meio de pacotes que são divididos em �its.
Na rede SoCINfp o tamanho do pacote, em bits, que trafega na rede é do tamanho de
um phit (physical channel unit). Cada componente da rede é acessada através de um
par de coordenadas (xid,yid), onde id representa a identi�cação do pacote. Quando um
pacote é enviado para um núcleo de processamento que está acoplado a uma porta do
roteador, o remetente tem que incluir no cabeçalho do pacote as coordenadas do núcleo de
processamento a que a mensagem se destina (xdest,ydest), onde dest representa o destino
do pacote. Esta informação é utilizada em cada roteador durante o caminho do pacote,
que compara o destino com sua própria coordenada para veri�car se o pacote chegou ao
destino. O formato do pacote é apresentado na �gura 2.16.
Observe que o pacote pode ter um número ilimitado de �its, cada um com n + 2
bits: n para dados e 2 para o frame do pacote. Este frame indicará qual o tipo de �it
(cabeçalho, payload ou terminador) dependo do valor de bop (begin-of-package) e eop
(end-of-package). O cabeçalho corresponde ao �it que tem o bop = 1 e o eop = 0, já o
13Fonte: Zeferino [5]
2.4 PLATAFORMA MPSOC INFINITY SOCIN 46
Figura 2.16 Estrutura do Pacote SoCINfp 13
payload possui bop = 0 e eop = 0 e �nalmente, o terminador possui bop = 0 e eop =
1. O cabeçalho é composto por dois campos básicos: RIB (Routing Information Bit) e
HLP (Higher Level Protocol). O campo RIB carrega as coordenadas do roteador destino
e HLP é reservado para a implementação do protocolo da rede e não é processado nos
roteadores. Depois do cabeçalho vem o payload que possui tamanho ilimitado e o último
�it do payload corresponde ao terminador [5]. O enlace utilizado no SoCINfp é composto
por dois canais ponto-a-ponto simplex, cada uma com n bits de dados e 2 bits de frame,
os quais compõem o canal da unidade física. Os sinais val e ret são usados para o controle
de �uxo de dados entre os roteadores. A �gura 2.17 apresenta os sinais do enlace.
Figura 2.17 Estrutura do Enlace SoCINfp 14
O sinal ret tem seu signi�cado variado dependendo do tipo de controle de �uxo empre-
gado. Caso seja controle �uxo handshake, o sinal de ret indica um reconhecimento para
um dado válido que está sendo enviado no canal. Para a abordagem baseada em crédito,
ele signi�ca que uma posição do bu�er de entrada foi liberado do receptor e um crédito
14Fonte: Zeferino [5]
2.4 PLATAFORMA MPSOC INFINITY SOCIN 47
está retornando para o remetente. O remetente só pode enviar um �it quando o bu�er do
receptor não estiver cheio. Ele monitora o estado do bu�er utilizando um contador que é
inicializado com o número de créditos equivalente a profundidade do bu�er do receptor.
O contador é decrementado quando um �it é enviado e incrementado quando o crédito
retorna. Se o contador de crédito é igual a 0, isto signi�ca que o bu�er do receptor está
cheio [5]. A rede SoCINfp é formada por um conjunto de roteadores do tipo ParIS (Para-
meterizable Interconnect Switch for Networks-on-Chip)descrito em detalhes no próximo
item.
2.4.3.1 Roteador ParIS
ParIS é um soft-core roteador baseado em uma biblioteca de blocos parametrizáveis pré-
desenhados. Ele possui 5 portas de comunicação (norte, sul, leste, oeste e local) compa-
tíveis com o enlace do SoCINfp e nomeado de N,S,E, W e L. A primeira porta (local) é
reservada para a conexão com o núcleo de processamento ou subsistema da rede, as de-
mais portas servem para conexão entre os roteadores. ParIS é internamente estruturado
de forma distribuída, e cada porta de comunicação tem dois módulos: canal de entrada
e canal de saída. Por exemplo, a porta local é composta pelos módulos chamados de Lin
(canal de entrada) e Lout (canal de saída) [5]. A �gura 2.18 apresenta a estrutura interna
do roteador.
Pela imagem é possível observar que o roteador ParIS é dividido nos seguintes módulos
de entrada: IFC, FIFO, IC e IRS. E nos módulos de saída: OC, ODS, OWS, FIFO e
OFC [5]. Eles serão detalhados a seguir:
� IFC (Input Flow Controller) - é um controlador de �uxo e regula o tráfego dos �its
que chegam nos canais de entrada;
� OFC (Output Flow Controller) - é um controlador de �uxo e regula o tráfego dos
�its que saem dos canais de saída;
� FIFO - é um bu�er que é usado para armazenar os �its dos pacotes bloqueados
15Fonte: Zeferino [5]
2.4 PLATAFORMA MPSOC INFINITY SOCIN 48
Figura 2.18 Estrutura Interna do Roteador ParIS 15
2.4 PLATAFORMA MPSOC INFINITY SOCIN 49
temporariamente dentro do roteador e que esperam ser encaminhados. O uso de
FIFO nas portas de entrada e saída é facultativo;
� IC (Input Controller) - este módulo seleciona um canal de saída para um canal
de entrada executando as seguintes etapas: análise do cabeçalho do pacote que
está no topo do bu�er de entrada; posteriormente ocorre a escolha do algoritmo de
roteamento, emitindo uma requisição (req) para a seleção do canal de saída.
� OC (Output Controller) - este módulo seleciona uma canal de entrada para um
canal de saída executando as seguintes etapas: fazer com que a arbitragem receba a
requisição do módulo IC e emitir um sinal com o objetivo de comandar o roteador,
o qual conecta o canal de entrada selecionado para o canal de saída e limpa o sinal
de idle;
� ODS (Output Data Switch) - este switch conecta a porta de saída de dados do
bu�er do canal de entrada selecionado para a porta de entrada do bu�er de saída
associado.
� OWS(Output Write Switch) - conecta o sinal de rok do bu�er do canal de entrada
selecionado com o sinal de comando wr do bu�er de saída associado;
� IRS(Input Read Switch) - conecta o sinal de wok do bu�er do canal de saída sele-
cionado com o sinal de comando rd do bu�er de entrada associado.
Observe ainda que o roteador ParIS possui um módulo CPM (Crosspoint Matrix )
que corresponde a um crossbar que é responsável por fazer a ligação entre os canais de
entrada e saída de forma que todos os canais de entrada tenham uma conexão com todos
os canais de saída.
2.4.4 Núcleo de Processamento In�nity e SoCINfp
A plataforma In�nity foi desenvolvida em TLM (Transaction Level Modeling) e desta
forma a obtenção de dados relativos ao consumo de potência que utiliza os ciclos de clock
2.4 PLATAFORMA MPSOC INFINITY SOCIN 50
que o sistema �cou ativo não é preciso neste nível de abstração. Assim foi realizada a
conexão do núcleo de processamento da plataforma in�nity com a NoC SoCINfp, desen-
volvido em RTL(Register Transfer Level) [13]. Com esta conexão foi necessário adicionar
uma interface de rede para realizar a tradução dos sinais de TLM para RTL, para que a
rede fosse capaz de encaminhar os pacotes. Como a plataforma in�nity realiza o proces-
samento de dados e compartilha informações com os outros núcleos de processamento,
o pacote foi modi�cado para que contivesse a informação do processamento nos �its de
payload [13]. Estas modi�cações serão apresentadas a seguir.
2.4.4.1 Interface de Rede (NIC)
A interface de rede da plataforma In�nity faz a comunicação entre os núcleos da plata-
forma e os roteadores da rede SoCIn, mas como foi citado nos tópicos anteriores, estas
camadas foram desenvolvidas em níveis de abstração diferentes. Desta forma a comu-
nicação na interface de rede foi dividida em dois submódulos: front-end(nível TLM) e
back-end (nível RTL). O front-end tem como �nalidade iniciar transações emitindo requi-
sições que, posteriormente, podem ser separadas em transações de serviços e transações
de dados. Observe que este protocolo é baseado em transações, assim, esta camada pode
ser vista como uma implementação da camada de sessão do modelo de referência OSI,
a qual representa a interface do usuário com a rede, determinando quando uma sessão é
aberta, o tempo necessário e quando deverá ser fechada. Já o banck-end é responsável
por manter o �uxo sob controle da chegada dos dados provenientes de um núcleo da
plataforma[13]. Resumidamente, pode-se a�rmar que a interface de rede da plataforma
In�nity é responsável por enviar mensagens do controlador da cache para a NoC, e de
receber os pacotes da NoC e montar a mensagem antes de enviar para o controlador de
cache. As threads CacheIN e DirectoryIN têm como �nalidade segmentar as mensagens
oriundas da cache ou do diretório que possuem o tamanho de 136 bits, e que são enviadas
pelo controlador de cache, em pacotes menores com o tamanho de 34 bits, para que seja
possível trafegar estas mensagem pela rede que possui um enlace com 34 bits de largura.
Para garantir o controle de �uxo foi desenvolvido a thread Tra�c Merger. Esta thread
2.4 PLATAFORMA MPSOC INFINITY SOCIN 51
tem como objetivo armazenar os pacotes que chegam até a interface de rede e implemen-
tar o protocolo de handshake com a porta local do roteador. Já a thread SoCIn tem a
�nalidade de reunir os pacotes da mensagem que chegaram através da NoC SoCINfp e
transformá-los em uma transação TLM, que o controlador de cache do núcleo de pro-
cessamento da In�nity consiga decodi�car[13]. Esta organização pode ser observada na
�gura 2.19.
Figura 2.19 Organização da Interface de Rede 16
Observe na �gura 2.19 que os sinais de entrada da interface de rede do lado esquerdo
estão no nível de transação e os sinas do lado direito da imagem estão no nível de sinais.
2.4.4.2 Modelo de Mensagem
As mensagens que trafegam pela NoC são mensagens que fazem parte de um protocolo
de coerência de cache e que inclui mensagens de controle e de transferência de dados.
Desta forma, a mensagem que será transmitida na rede, dentro do payload do pacote é
organizada da seguinte forma: < service >< serviceparameters >, onde service é uma
ação do protocolo de coerência de cache solicitado e serviceparameters são os parâmetros
necessários para desempenhar este serviço. Estes parâmetros podem ser dos tipos:
16Fonte: Santana [13]
2.4 PLATAFORMA MPSOC INFINITY SOCIN 52
1. Source component: o controlador de cache que está enviando a mensagem pode
ser a Cache L1, por exemplo;
2. Destination component: o controlador de cache que irá receber a mensagem;
3. Address: corresponde ao endereço físico do dado;
4. Data: corresponde ao dado propriamente dito;
5. Owner: é o endereço de rede do proprietário do dado;
6. Shared number: indica com quantos núcleos o dado está sendo compartilhado.
Os serviços mencionados devem re�etir alguma ação do protocolo de cache a ser
tomada pelo controlador da cache depois de ter recebido as mensagens. Os serviços que
estão atualmente implementados no protocolo de coerência de cache na plataforma e que
podem ser especi�cados por um pacote de rede são apresentados juntamente com seu
código correspondente na tabela 2.2.
Tabela 2.2 Serviços carregados por um pacoteServiços Código
Error 0000Get shared 0001Get modi�ed 0010Invalidate 0011Invalidate ack 0100Invalidate started 0101Put modi�ed 0110Put modi�ed and shared 0111Put modi�ed ack 1000Foward get shared 1001Foward get modi�ed 1010Data 1011Unknow message 1100
A tabela 2.2 apresenta os serviços de coerência de cache que podem trafegar na rede.
A mensagem é transportada em bits, por isto, na parte direita da tabela é apresentado o
código em binário de cada serviço. Por exemplo, se é necessário avisar que houve erro, o
dado a ser transportado são 4 bits totalmente zerados.
2.5 CONCLUSÃO 53
2.4.4.3 Formato de Mensagem
Para dar suporte aos serviços do protocolo de coerência de cache, a mensagem possui os
seguintes campos: header, payload e trailer. Estes �its são apresentados na �gura 2.20.
Figura 2.20 Partes Constituintes da Mensagem 17
Observe que em todos os �its existem os campos BOP (Begin of Packet) e EOP
(End of Packet). Estes campos são utilizados para indicar quando a mensagem começa
(cabeçalho), onde está a carga útil e onde a mensagem termina (trailer). O cabeçalho
possui as informações de roteamento, como coordenadas x e y do roteador de origem
e do destinatário da mensagem (High Level Protocol (HLP) e Routing Information Bits
(RIB)), código do serviço solicitado pelo mecanismo de coerência de cache e os parâmetros
de serviço (Source component, Destination component, Owner e Shared number). A
carga útil carrega a informação do endereço (address). Já o trailer �ca encarregado do
transporte do dado (data).
2.5 CONCLUSÃO
Como pode ser observado os multiprocessadores trocam informações relativas a coerência
de cache, por exemplo, se o dado que está na memória é o mais atual, se estas requisições
são transportadas no formato de pacotes através da rede de comunicação, a NoC. Observe
que a comunicação entre os multiprocessadores, corresponde a um acesso não uniforme
17Fonte: Max [13]
2.5 CONCLUSÃO 54
de memória, dado que a informação está distribuída e desta forma, o tempo de acesso ao
dado depende: da localidade da informação, em que multiprocessado o dado se encontra,
e latência da rede, quão sobrecarregada de mensagens a rede está. Um dos fatores que
in�uência o congestionamento de uma NoC é o algoritmo de roteamento utilizado pelos
seus roteadores, pois um algoritmo que não pondera a sobrecarga da rede quando escolhe
o caminho para direcionar o pacote, pode agravar o congestionamento e assim aumentar
a latência de espera de entrega da informação à memória. Portanto, a utilização de um
algoritmo de roteamento que considere o estado de congestionamento da rede reduz a
latência de entrega das informações para os multiprocessadores.
55
CAPÍTULO 3
TRABALHOS RELACIONADOS
Neste capítulo serão apresentados os trabalhos relacionados. O trabalhos descritos apre-
sentam técnicas de roteamento adaptativos que consideram, entre outras melhorias, o
congestionamento da rede.
3.1 CATRA - CONGESTION AWARE TRAPEZOID-BASED ROUTING ALGO-
RITHM FOR ON-CHIP NETWORK
Consiste no método de roteamento de pacotes que tem como vantagem a utilização de in-
formações de congestionamento local e não-local na decisão de roteamento. Desta forma,
este método pode aumentar a e�ciência da rede com o balanceamento da carga da rede.
A grande contribuição deste trabalho é a ideia de considerar o nível de congestionamento
nos nós mais próximos do caminho de roteamento. Baseado nisto, é apresentada a ideia
de monitoramento do status de congestionamento dos nós em posições trapezoidais [8].
3.1.1 Probabilidades de Passagem de Pacotes pelos Nós
Um dos objetivos do CATRA é tomar a decisão de roteamento baseada nas condições
de congestionamento dos nós que mais enviam pacotes. Vale salientar que para uma
dada fonte e destino em um algoritmo adaptativo, alguns nós intermediários enviam mais
pacotes do que outros. Geralmente, os nós mais centrais, por serem mais acessíveis a vários
nós, enviam mais pacotes do que os roteadores que estão na borda. Considere a �gura 3.1
onde o pacote é enviado do nó 0 para o nó 35 enquanto a rede não está congestionada. No
nó fonte, o pacote pode ser enviado para os nós 1 e 6 com a probabilidade de 50% cada.
Quando o pacote chega ao roteador 1, tem duas opções os nós 2 e 7. A probabilidade
3.1 CATRA - CONGESTION AWARE TRAPEZOID-BASED ROUTING ALGORITHM FOR
ON-CHIP NETWORK 56
do pacote passar por estes nós é de 25%. Pacotes oriundos dos nós 2 ou 7, podem ser
entregues ao nó 8, assim com a probabilidade de 25% um pacote é transferido do nó 7 para
o destino, e assim sucessivamente. Observe que quanto mais longe do trapézio, menor
�ca a probabilidade do pacote ser direcionado para aqueles nós, desta forma CATRA só
analisa os pacotes que estão na posição trapezoidal.
Figura 3.1 Probabilidade de Passagem de Pacotes pelos Nós 1
3.1.2 Estratégia de Propagação de Congestionamento
Com o intuito de distribuir as informações de congestionamento entre os nós que estão
delimitados pelo trapézio, cada quatro roteadores são conectados a um agente. A �gura
3.2 apresenta esta distribuição dos agentes pela rede.
Cada agente tem duas atividades principais:
1. Coletar as informações de congestionamento dos roteadores a que estão ligados
(roteadores locais) e distribuir a informação para os agentes vizinhos;
2. Receber informação não-local dos agentes vizinhos e entregar aos roteadores locais.
1Fonte: Ebrahimi [8]2Fonte: Ebrahimi [8]
3.1 CATRA - CONGESTION AWARE TRAPEZOID-BASED ROUTING ALGORITHM FOR
ON-CHIP NETWORK 57
Figura 3.2 Distribuição dos Agentes 2
3.1.3 Métricas de Congestionamento
Todos os nós recebem 1-bit de informação de congestionamento, que informa se o bu�er
atingiu o limiar de congestionamento, de cada roteador vizinho e dois status de conges-
tionamento de 3-bits, que informa o número de células do bu�er que estão ocupadas, de
cada agente conectado. As métricas de congestionamento são apresentadas abaixo.
3.1.3.1 Calculando Congestionamento de Nós Vizinhos Para estimar o con-
gestionamento dos roteadores vizinhos, foi proposto utilizar a disponibilidade do bu�er
(armazenamento) na porta de entrada correspondente no nó subseqüente como métrica
de congestionamento. Como somente 1-bit é trocado entre os roteadores vizinhos, o bit só
é ativado quando o espaço ocupado no bu�er ultrapassa o limiar de 75%. Com o objetivo
de evitar mudanças bruscas nestes bits, foi desenvolvido um sistema de armazenamento
de histórico, onde um registrador de shift é adotado para armazenar o sinal de conges-
tionamento de 1-bit cada vez que um �it entra ou sai do bu�er. Com esta estratégia a
�ag de congestionamento só estará ativa quando os três bits do registrador de shift forem
iguais a 1, como apresenta a �gura 3.3. Observe que é utilizado um shift de 3 bits para
garantir que o sinal de 1-bit do congestionamento só seja ativado quando o bu�er tenha
atingido o limiar de congestionamento por no mínimo 2 ou 3 entradas e saídas de �its.
3.1 CATRA - CONGESTION AWARE TRAPEZOID-BASED ROUTING ALGORITHM FOR
ON-CHIP NETWORK 58
Figura 3.3 Circuito de Detecção de Congestionamento 3
3.1.3.2 Calculando Congestionamento de Nós Distantes Para realizar este cál-
culo, o número total de espaços disponíveis em bu�er em cada roteador é utilizado como
uma métrica de congestionamento. Assim, se o número total de espaços disponíveis em
um roteador for maior que um valor limite, então o nó é dito congestionado. Baseado em
experimentos o melhor valor limite foi 60%[8].
3.1.4 Resultados Experimentais
Para a obtenção dos resultados um simulador de uma NoC foi desenvolvido na linguagem
VHDL para modelar os principais componentes de uma rede on-Chip e as simulações fo-
ram realizadas para determinar a latência característica da rede. Para todos os roteadores,
o tamanho do dado foi de 32 bits. Como métrica de desempenho, �cou de�nido latên-
cia como o número de ciclos entre a inicialização da transmissão da mensagem emitido
pelo elemento de processamento (PE) e o instante quando a mensagem é completamente
entregue ao PE de destino. A taxa de solicitação �cou de�nida como a relação entre as
mensagens injetadas com sucesso na interface de rede e o número total de tentativas de
injeção. Foram utilizados os simuladores sintéticos de tráfego uniform random e hotspot
juntamente com o aplicações de trace do SPLASH-2. Os tamanhos dos pacotes foram
uniformemente distribuídos entre 1 e 5 �its.
3.1.4.1 Análise de Desempenho - Tráfego Uniforme
Cada PE gera um pacote de dados e os envia para outro PE utilizando uma distribuição
3Fonte: Ebrahimi [8]
3.1 CATRA - CONGESTION AWARE TRAPEZOID-BASED ROUTING ALGORITHM FOR
ON-CHIP NETWORK 59
uniforme. As redes utilizadas tinham os tamanhos: 8X8 e 14X14. A �gura 3.4 apresenta
os resultados entre os quais destacam-se a média do atraso de comunicação como uma
função da média da taxa dos pacotes injetados. Na letra a da �gura 3.4 é apresentado o
resultado para a rede 8X8 e na letra b da mesma �gura, para a rede 14X14.
Figura 3.4 Atraso Médio de Comunicação para Tráfego Uniforme 4
Para avaliar a e�ciência do esquema de roteamento proposto, os protocolos de ro-
teamento DBAR e NOP foram implementados. Estas técnicas utilizam algoritmo de
roteamento completamente adaptativo baseado no MAD-Y[8]. É observado que CATRA
obtém os melhores resultados, obtendo os menores números de latência. Isto ocorre dado
ao fato de que CATRA pode distribuir o tráfego de forma mais e�ciente do que os ou-
tros esquemas, desde que a unidade de decisão de roteamento é baseada no status do
congestionamento dos nós onde passam mais pacotes.
3.1.4.2 Análise de Desempenho - Tráfego com Hotspot
Neste caso um ou mais nós foram escolhidos para serem o hotspot e desta forma receberam
maior tráfego do que o tráfego regular uniforme. Em simulações, dado uma porcentagem
de hotspot H, a mensagem recentemente gerada é direcionada a cada nó do hotspot com
uma adição de H porcento de probabilidade. Foi simulado um tráfego de hotspot com
um único nó congestionado (4,4) e (7,7) na rede 8X8 e 14X14, respectivamente. O
desempenho com H = 10% é ilustrado na �gura 3.5.
4Fonte: Ebrahimi [8]5Fonte: Ebrahimi [8]
3.1 CATRA - CONGESTION AWARE TRAPEZOID-BASED ROUTING ALGORITHM FOR
ON-CHIP NETWORK 60
Figura 3.5 Atraso Médio de Comunicação para Tráfego com Hotspot 5
Observe que CATRA novamente obteve os melhores resultados, tanto na rede 8X8
(representada pela letra a) como na rede 14X14 (representada pela letra b).
3.1.4.3 Análise de Desempenho - Aplicação de Tráfego
O trace foi obtido com o simulador GEMS usando algumas aplicações do bechmark
SPLASH-2. Foram utilizados 64 nós de rede com as seguintes con�gurações: 20 proces-
sadores e 44 caches L2. Para a CPU foram utilizados núcleos similares ao Sun Niagara
e com processador SPARC. Cada núcleo de cache L2 tem 512KB, e desta forma, o total
de cache L2 compartilhada é de 22MB. A memória hierárquica que foi implementada é
governada por dois níveis de diretório de coerência de cache. Cada processador tem um
cache L1 privativa (split L1 e cache D, 64KB, 2-way, 3-ciclos por acesso). A cache L2 é
compartilhada com todos os processadores e dividida em dois bancos (44 bancos, 512KB
para cada, totalizando 22MB, 6 ciclos por acesso), conectados por roteadores no chip. O
tamanho do block L1/L2 é de 64B. O modelo de coerência inclui protocolo baseado em
MESI com diretórios distribuídos, com cada banco de L2 mantendo seu próprio diretório
local. A memória hierárquica simulada SNUCA-0, onde a memória fora do chip é de 4GB
DRAM com 220 ciclos de tempo de acesso. A �gura 3.6 apresenta os resultados.
Novamente o projeto CATRA foi comparado com NoP e DBAR, que são métodos
de roteamento com algoritmos totalmente adaptativos. Observe que CATRA apresenta
aproximadamente 26% de redução de latência em relação aos demais.
6Fonte: Ebrahimi [8]
3.2 CARS: CONGESTION-AWARE REQUEST SCHEDULER FOR NETWORK INTERFACES IN
NOC-BASED MANYCORE SYSTEMS 61
Figura 3.6 Média de Latência do Pacote 6
3.2 CARS: CONGESTION-AWARE REQUEST SCHEDULER FOR NETWORK
INTERFACES IN NOC-BASED MANYCORE SYSTEMS
A ideia principal do CARS é utilizar a informação global de congestionamento em uma
NoC composta por interfaces master e slave para reduzir os pacotes enviados para áreas
congestionadas pela priorização dos pacotes nas interfaces slaves. O pacotes coletam in-
formações ao longo do caminho e carregam isto para as interfaces de rede slaves. Os
pacotes começam a coletar as informações quando a distância dele é igual ou menor do
que três nós ao nó destino. Cada interface de rede slave mantém uma tabela para ar-
mazenar o valor de congestionamento estimado carregado pelos pacotes[4]. Os pacotes
são originários de 8 regiões da rede. Como é apresentado na �gura 3.7, existem 4 regiões
triangulares: nordeste (NE), noroeste (NW), sudoeste (SE) e sudeste (SW). Observe que
existem 4 regiões colunares: norte (N), sul (S), leste (E) e oeste (W). Caso o nó slave e
o nó master estejam na mesma coluna ou linha, somente a informação de congestiona-
mento colunar é útil. A ideia deste projeto pode ser explicada com o seguinte exemplo:
imagine que os nós master 0, 3, 6, 21, 24, 27, 42, 45 e 48 enviam requisições para o nó
slave (memória) 24. O nível de congestionamento dos roteadores é representado pelo nós
coloridos (quanto mais escuro a cor do nó, mais congestionado o nó está). Utilizando a
informação de congestionamento carregada pelos pacotes nas requisições da interface de
rede master para a interface de rede slave, o status de congestionamento de cada região
pode ser estimado na interface de rede slave. Neste exemplo, os níveis de congestiona-
mento das diferentes regiões são assumidas como as que estão apresentadas na �gura 3.7
3.2 CARS: CONGESTION-AWARE REQUEST SCHEDULER FOR NETWORK INTERFACES IN
NOC-BASED MANYCORE SYSTEMS 62
na tabela de congestionamento (CT) ao lado. Desde que as regiões NE, NW, N e W estão
altamente congestionadas, entregar as mensagens de respostas aos nós 48,42, 45 e 21 não
só aumenta o congestionamento destas áreas já congestionadas, como também aumenta
a latência média dos pacotes. Este problema pode ser suavizado pela priorização das re-
quisições dos pacotes baseados no nível de congestionamento das regiões. Aquelas regiões
cujos níveis de congestionamento forem menores, terão maior prioridade de envio. Assim
se obtém duas vantagens: a recepção da resposta oriunda do slave para regiões menos
congestionadas e redução temporária da injeção de tráfego nas áreas mais congestionadas.
Figura 3.7 Diferentes níveis de Congestionamento em Roteadores e Regiões 7
3.2.1 Implementação do CARS
Foi reservado um campo com 3 bits, chamado de status de congestionamento (CS), no ca-
beçalho de cada pacote para armazenar as informações de congestionamento do caminho
atravessado pelo pacote. Como mencionado, os pacotes começam a coletar a informação
sobre o congestionamento quando a distância até o nó destino é menor que ou igual a três
7Fonte: Daneshtalab [4]
3.2 CARS: CONGESTION-AWARE REQUEST SCHEDULER FOR NETWORK INTERFACES IN
NOC-BASED MANYCORE SYSTEMS 63
nós. O valor de congestionamento do roteador indica o número de portas de entradas con-
gestionadas correspondente a mensagem de resposta. O total de portas utilizadas neste
projeto é de 5 portas por roteador, desta forma só são necessários 3 bits para codi�car o
número total de portas que podem estar congestionadas[4]. O valor do congestionamento
é baseado no número de células ocupadas no bu�er, se o limiar for ultrapassado, então a
porta correspondente a este bu�er está congestionada. O valor de congestionamento do
roteador e o valor de CS (que está localizado no cabeçalho do pacote) são combinados, ou
seja, é calculada a média dos valores e o resultado é armazenado no cabeçalho do pacote,
formando o novo valor de CS. Na interface slave, os valores estimados de congestiona-
mento da região são armazenados na tabela de congestionamento (CT). Uma vez que o
pacote entra na interface de rede slave, a informação de congestionamento é extraída do
cabeçalho do pacote e combinada com o valor existente na tabela de congestionamento.
O arbitro seleciona o pacote que veio da região menos congestionada. Esta política pode
originar uma starvation, porque os pacotes que não foram escolhidos para serem enviados
podem nunca ser enviados devido ao congestionamento na região ser maior, assim para
evitar este problema, os valores de prioridade dos pacotes que ainda não foram escolhidos
são incrementados depois de cada processo de escolha. Para este trabalho foi utilizado
o algoritmo de roteamento odd-even, pois este algoritmo é adaptativo e não precisa de
canais virtuais para seu funcionamento.
3.2.2 Resultados Experimentais
Para avaliar o método utilizado pelo CARS um simulador de NoC foi desenvolvido em
VHDL. O simulador modela os componentes principais da NoC incluindo: interfaces de
rede, rodeadores e conexões. Foi realizada com uma comparação entre uma rede com o
CARS e outra rede igualmente desenvolvida, mas sem o CARS. A rede é composta por
interfaces slaves e master.
3.2 CARS: CONGESTION-AWARE REQUEST SCHEDULER FOR NETWORK INTERFACES IN
NOC-BASED MANYCORE SYSTEMS 64
3.2.3 Con�guração do Sistema
Neste trabalho foi utilizada uma rede com 30 nós (6X5) malha 2D. A �gura 3.8 apresenta
a arquitetura utilizada.
Figura 3.8 NoC utilizada pelo CARS 8
Destes 30 nós, 18 nós são processadores (cores master, conectados a uma interface
master) e outros 12 nós são memórias (cores slave, conectados a interfaces slave). Os
processadores são 32b-AXI e as memórias são DRAM 32b. Foi adotado controlador de
memória comercial com interface de memória, módulo DDR2SPA originária do Gaisler
ip-cores, o qual foi colocado entre a memória e a interface de rede. Adicionalmente,
cada estrutura do roteador inclui bu�ers, um alocador de canal virtual, uma unidade
de roteamento, um switch e um crossbar. Cada roteador tem 5 portas de entrada/saída
e cada porta de entrada tem 2 canais virtuais, isto foi necessário para evitar deadlock,
pois com esta arquitetura, os pacotes com mensagem de tipos diferentes (requisição e
resposta) são encaminhadas por diferentes canais virtuais. Os roteadores adotaram o
algoritmo odd-even e o roteamento wormhole. Para todos os roteadores, o tamanho do
8Fonte: Daneshtalab [4]
3.2 CARS: CONGESTION-AWARE REQUEST SCHEDULER FOR NETWORK INTERFACES IN
NOC-BASED MANYCORE SYSTEMS 65
dado é de 32 bits e a profundidade do bu�er é de 5 �its. Como métrica de desempenho
foi utilizada a latência, de�nida como sendo o número de ciclos entre a inicialização da
operação de requisição emitida pelo master (processador) e o instante em que a resposta é
completamente entregue ao master pelo slave (memória). A taxa de requisição foi de�nida
como a relação de injeções de requisições de leitura e escritas realizadas com sucesso e o
total de injeções realizadas [4].
3.2.4 Avaliação de Desempenho
Para avaliar o desempenho dois tipos de padrões de tráfego foram utilizados: tráfego
uniforme e não uniforme. No tráfego não uniforme, 70% do tráfego são de requisições
locais, onde a memória de destino tem apenas um nó de distância do processador e o
restante, 30% do tráfego, é uniformemente distribuído para memórias não locais. A
�gura 3.9 apresenta os resultados obtidos.
Figura 3.9 Avaliação de Desempenho pelo CARS: a)No tráfego uniforme e b) No tráfego nãouniforme 10
A �gura representada na letra a, corresponde ao modelo com tráfego uniforme. Já a
�gura na letra b, representa o tráfego não uniforme. Como se pode observar na �gura,
comparado com a arquitetura básica, a utilização do método CARS reduz a latência média
quando a taxa de requisições aumenta nos casos de trafego uniforme e não uniforme. O
ganho de desempenho perto do ponto de saturação (0,6) sob tráfego uniforme e não
uniforme foi de 27% e 23% respectivamente.
10Fonte: Daneshtalab [4]
3.3 A SYSTEMATIC REORDERING MECHANISM FOR ON-CHIP NETWORKS USING
EFFICIENT CONGESTION-AWARE METHOD 66
3.3 A SYSTEMATIC REORDERINGMECHANISM FOR ON-CHIP NETWORKS
USING EFFICIENT CONGESTION-AWARE METHOD
Neste trabalho é proposto um método de evitar congestionamento para redes on-chip e
reduzir o congestionamento utilizando basicamente as seguintes ideias: a primeira ideia é
empregar a informação de congestionamento global na arbitragem do roteador e a segunda
ideia é reordenar as requisições na interface de rede de acordo com a informação geral de
congestionamento.
3.3.1 Interface de Rede
Neste projeto foi utilizado o protocolo AMBA AXI, que possui várias funções como múlti-
plo endereçamento externo e funções de intercalação de dados. Neste protocolo os núcleos
IP podem ser classi�cados como master e slave. Os IP masters são aqueles que iniciam a
transação emitindo uma requisição de leitura ou escrita que um ou mais slaves (memó-
rias) recebem e executam para cada requisição. Este protocolo fornece uma identi�cação
(transaction ID) para cada transação. Transações oriundas do mesmo master IP core,
mas com diferentes identi�cadores não possuem restrição de ordenamento, já as transa-
ções com o mesmo identi�cador precisam ser completadas em ordem. Este sistema pode
ser visualizado nas Figuras 3.10 e 3.11 abaixo:
Figura 3.10 Interface Master 11
11Fonte: Daneshtalab [9]
3.3 A SYSTEMATIC REORDERING MECHANISM FOR ON-CHIP NETWORKS USING
EFFICIENT CONGESTION-AWARE METHOD 67
Figura 3.11 Interface Slave12
Na interface master a unidade de encaminhamento é composta do AXI-Queue, e uni-
dade de empacotamento, enquanto a unidade reversa, recebendo as respostas da rede, é
composta pela �la de pacotes, e a unidade de desempacotamento; a unidade de reorde-
namento é compartilhada entre os pacotes de encaminhamento e reverso. A unidade de
reordem é a parte que mais in�uencia a interface de rede. Na unidade de encaminha-
mento, é preparado o número da seqüência correspondente ao identi�cador da transação,
e evita o over�ow do bu�er de reordem pelo mecanismo de recepção que é proporcionado
por esta unidade. Por outro lado, na unidade reversa, esta unidade determina onde os
pacotes importantes da �la devem ser transmitidos (bu�er de reordem ou desempacota-
dor) e quando os pacotes do bu�er de reordem podem ser encaminhados para a unidade
de desempacotamento. Como apresentado na �gura 3.11, para evitar a perda da ordem
das informações do cabeçalho (identi�cador de transação, numero de seqüencia e etc...)
carregado pelas requisições que chegam, a FIFO tem sido considerada na interface slave
da interface de rede. Depois de processar uma requisição no núcleo slave, o pacote de res-
posta deve ser criado pelo empacotador. Como pode ser visto na �gura 3.11, para gerar
o pacote de resposta, depois do conteúdo do cabeçalho da requisição correspondente ser
chamado para a FIFO, e alguns parâmetros do cabeçalho (endereço de destino, tamanho
do pacote e etc...) serem modi�cados pelo adaptador, o pacote de resposta será formado.
12Fonte: Daneshtalab [9]
3.3 A SYSTEMATIC REORDERING MECHANISM FOR ON-CHIP NETWORKS USING
EFFICIENT CONGESTION-AWARE METHOD 68
De fato, os componentes do lado slave da interface em unidade de encaminhamento e
reverso são quase similares aos componentes do lado master da interface, com exceção da
unidade de reordenação.
3.3.2 Método de Balanceamento Global de Congestionamento
O objetivo do método de balanceamento global de congestionamento (BGC) é duplo. A
primeira ideia é utilizar a informação de congestionamento global no processo de arbitra-
gem do roteador e a segunda ideia é evitar o envio de pacotes para áreas congestionadas
pelo monitoramento da informação de congestionamento na interface slave da rede.
3.3.2.1 Usando a Informação de Congestionamento nos Roteadores Imedia-
tos
A ideia principal por trás do método BGC é permitir que nós congestionados encami-
nhem seus pacotes rapidamente, o que diminuirá signi�cativamente a probabilidade de
bloqueio geral. Considere o exemplo da �gura 3.12a onde uma rede mesh 4 X 4 com três
nós congestionados (5,6 e 10) é apresentada. Se um mecanismo justo de arbitragem é
usado no roteador 9, os pacotes que chegam dos roteadores congestionados 5 e 10 terão a
mesma chance de serem escolhidos pelo árbitro comparado com os outros pacotes vindos
dos roteadores 8 e 13. Desta forma, o roteador 9 pode ser um gargalo para os pacotes que
chegam da área congestionada. Este gargalo pode ser resolvido dando maior prioridade
para os pacotes oriundos dos roteadores 5 e 10 para acessar a porta de saída do roteador
9, aliando a carga de tráfego na área congestionada. Em contraste, pacotes oriundos dos
roteadores 8 e 13 deveriam esperar nos bu�ers de entrada do roteador 9 antes de acessar
o canal de saída, o que pode aumentar o congestionamento do roteador 9 signi�cativa-
mente. Em outras palavras, o tráfego em áreas altamente congestionadas é distribuído
sobre nós menos congestionados. Se for assumido que o valor de congestionamento de um
roteador é determinado pela condição de congestionamento do roteador, bem como em
seus vizinhos, e esta informação é carregada pelos pacotes, então os pacotes são capazes
de coletar a informação de congestionamento dos roteadores e seus vizinhos no caminho
3.3 A SYSTEMATIC REORDERING MECHANISM FOR ON-CHIP NETWORKS USING
EFFICIENT CONGESTION-AWARE METHOD 69
da fonte ao destino. Desde que este valor permite uma visão global do congestionamento
no caminho de roteamento, isto pode ser usado como um parâmetro de prioridade nos
roteadores para reconhecimento da área congestionada na rede. Então, a arbitragem no
roteador é realizada baseada na informação global do congestionamento carregada pelos
pacotes.
Figura 3.12 Distribuição do Tráfego a)sem b)com aplicação da ideia do BGC13
3.3.2.2 Usando a Informação de Congestionamento nas Interfaces Slaves
Os pacotes coletam as informações de congestionamento ao longo dos caminhos e car-
regam das interfaces de rede master até as interfaces slave. Esta informação global de
congestionamento pode ser utilizada na interface de rede slave para gerenciar o conges-
tionamento da rede para o envio de requisição e respostas para a rede. Considerando o
exemplo apresentado na �gura 3.13, onde o nó master 0, 4, 20 e 24 enviam requisições
A, B, C e D respectivamente, para a memória (slave) 12. É assumido que o nível de con-
gestionamento nos roteadores é organizado em quatro níveis de prioridade, os quais são
representados pelos nós coloridos da �gura 3.13 (por exemplo, quanto mais escuro o nó
está, maior é o nível de congestionamento a que ele está submetido). Foi assumido que a
rede pode ser dividida em quatro quadrantes de acordo com as coordenadas relativas aos
nós master e slave (por exemplo, quadrantes nordeste, noroeste, sudeste e sudoeste como
na imagem 3.13). Pelo uso da informação de congestionamento carregada pela interface
master da rede para a interface slave da rede 12, o status de congestionamento de cada
quadrante pode ser estimado na interface slave 12. Então, como é mostrado na �gura,
o nível de congestionamento recebido pelas requisições dos quadrantes sudoeste, sudeste,
3.3 A SYSTEMATIC REORDERING MECHANISM FOR ON-CHIP NETWORKS USING
EFFICIENT CONGESTION-AWARE METHOD 70
noroeste e nordeste são: 4,2,3 e 1 respectivamente. Como o quadrante sudoeste é o mais
congestionado, entregar a mensagem A (outras mensagens) do nó master 0 não só agrava
o congestionamento na área congestionada como também aumenta a latência da rede.
Este problema pode ser mitigado pela priorização das requisições baseadas no nível de
congestionamento dos quadrantes de tal forma que as requisições dos quadrantes menos
congestionados são priorizados. Desta forma a requisição D é entregue primeiro, seguida
das requisições B, C e A.
Figura 3.13 Diferentes Níveis de Congestionamento em Roteadores e Quadrantes14
3.3.2.3 Implementação do BGC - Seleção de Saída Adaptativa
Neste projeto foi utilizado o algoritmo odd-even, que é um modelo adaptativo que não
requer a utilização de canais virtuais. Neste método, a seleção é realizada localmente
de acordo com a condição de congestionamento dos nós vizinhos. O número de células
ocupadas no bu�er na entrada correspondente aos bu�ers de entrada dos nós vizinhos
é considerada como uma métrica de congestionamento. Portanto, se o espaço ocupado
no bu�er de entrada for maior que um valor limite, então a �ag de congestionamento se
torna '1', caso contrário '0'. Observe que por simplicidade, não é levado em consideração
a informação não local nas decisões de roteamento, a informação do congestionamento
global é utilizada para priorizar os pacotes que serão enviados no bu�er.
14Fonte: Daneshtalab [9]
3.3 A SYSTEMATIC REORDERING MECHANISM FOR ON-CHIP NETWORKS USING
EFFICIENT CONGESTION-AWARE METHOD 71
3.3.2.4 Implementação do BGC - Seleção de Entrada Adaptativa
É reservado um campo com 4 bits, chamado de status de congestionamento (SC), no ca-
beçalho de cada pacote para armazenar as informações de congestionamento do caminho
trilhado pelo pacote. Portanto, em cada roteador intermediário do caminho, o valor do
SC do pacote é atualizado tal que ele é combinado com a informação de congestionamento
do roteador atual. A informação de congestionamento do roteador é baseada nas condi-
ções de congestionamento (CC) dos vizinhos imediatos e do próprio roteador. As CC do
roteador e seus vizinhos são combinados de acordo com a tabela 3.2, onde x é a fração
do número de portas de entrada em relação ao total de número de portas de entrada do
roteador, enquanto que y é a fração do número de portas de entrada dos vizinhos que
estão congestionadas (por exemplo, porta de entrada dos vizinhos que estão conectadas
a saída do roteador) e o número de vizinhos. Cada roteador gera informação de con-
gestionamento de 4 bits pela concatenação da CC do roteador com a CC do vizinho. A
média da informação de congestionamento do roteador e do valor do SC no cabeçalho do
pacote é armazenado no cabeçalho do pacote como o novo SC. Usando este mecanismo o
pacote carrega a informação de congestionamento dos roteadores bem como dos vizinhos
ao longo do caminho. Como este valor contém uma visão global do caminho, ele pode
ser utilizado como uma métrica e�ciente do processo de arbitragem dos roteadores inter-
mediários para o reconhecimento das áreas congestionadas na rede. A função de seleção
da entrada do bu�er examina o valor de prioridade de todos os pacotes de entrada e dá
um subsídio ao pacote com o maior nível de congestionamento. Para evitar o starvation,
a cada tempo depois de encontrar o maior valor, as prioridades dos pacotes deferidos são
incrementados.
Tabela 3.1 Mapeamento dos Valores de Congestionamento local e dos vizinhos da porta deentrada em dois bitsx CC y CC
0 < x ≤ 14
00 0 < y ≤ 14
0014< x ≤ 1
201 1
4< y ≤ 1
201
12< x ≤ 3
410 1
2< y ≤ 3
410
34< x ≤ 1 11 3
4< y ≤ 1 11
3.3 A SYSTEMATIC REORDERING MECHANISM FOR ON-CHIP NETWORKS USING
EFFICIENT CONGESTION-AWARE METHOD 72
Figura 3.14 Escalonador Adaptativo com TIQ na Interface Slave 15
3.3.2.5 Implementação do BGC - Escalonador de Pedidos Adaptativo
Como apresentado na �gura 3.14, na interface de rede slave é armazenada uma tabela
com as informações oriundas do cabeçalho do pacote, que correspondem às informações
de congestionamento dos quadrantes. A tabela é conhecida como tabela de informações
dos quadrantes (TIQ). Uma vez que o pacote entra na interface slave, a informação de
congestionamento (SC) é extraída do cabeçalho do pacote para atualizar o TIQ. Com
esta �nalidade, a média do quadrante correspondente na tabela e o SC é substituído
com o valor anterior de TIQ. O valor de SC do pacote é recebido das coordenadas X
ou Y dos roteadores, atualizam o valor de congestionamento de dois quadrantes do TIQ
(por exemplo, um pacote oriundo da direção leste atualiza os valores de TIQ tanto do
sudeste quanto do nordeste. O escalonador, integrado com a unidade de �la de pacotes
(3.14), seleciona o pacote que vem de um quadrante menos congestionado. Se a requisição
pertencer a um roteador na coordenada X ou Y, os valores de congestionamento de ambos
os quadrantes relativos são considerados no escalonador. Para evitar starvation, o valor
de prioridade dos pacotes que estão esperando são incrementados depois de cada processo
15Fonte: Daneshtalab [9]
3.3 A SYSTEMATIC REORDERING MECHANISM FOR ON-CHIP NETWORKS USING
EFFICIENT CONGESTION-AWARE METHOD 73
de escalonamento.
3.3.3 Resultados Experimentais
Para avaliar o método BGC com a interface de rede slave que foi proposta, um simulador
NoC foi implementado em VHDL. O simulador modela todos os componentes principais
como a interface de rede, roteadores e �os. A interface de rede composta pelo método
BGC é comparada com a arquitetura básica em termos de latência sob diferentes padrões
de tráfego. A arquitetura básica é composta de interfaces de rede master slave, mas sem
a utilização do método BGC.
3.3.3.1 Con�guração do Sistema
Neste trabalho foram utilizados 30 nós (6 X 5) em uma rede tipo malha 2D. como apre-
sentado na �gura 3.15. Observe que destes 30 nós, 12 nós são processadores (núcleos
master, conectados a interface de rede master) e os outros 18 núcleos são memórias (nú-
cleos slave, conectados a interfaces de rede slave). Os processadores são 32b-AXI e as
memórias são DRAM. Cada estrutura do roteador inclui bu�ers de entrada, alocadores de
canal virtual (CV), unidade de roteamento, alocador de switch e crossbar. Cada roteador
tem 5 portas de entrada/saída, e cada porta de entrada do roteador tem 2 CV. Pacotes
com diferentes tipos de mensagem (requisição ou resposta) são atribuídos a canais vir-
tuais correspondentes para evitar deadlock de dependência de mensagem. O algoritmo
de roteamento, a largura do link, número de canais virtuais, profundidade do bu�er de
cada canal virtual, e o tipo de tráfego são os outros parâmetros que são especi�cados
no simulador. Os roteadores adotaram o roteamento odd-even e utilizam a comutação
wormhole. A largura dos dados utilizada foi 32 bits e a profundidade dos bu�ers foi de 5
�its.
Como métrica de desempenho, foi de�nida a latência dada pelo número de ciclos entre
a inicialização da operação de requisição emitida pelo master (processador) e o instante
em que as respostas são completamente entregues ao master pelo slave (memória). A
16Fonte: Daneshtalab [9]
3.3 A SYSTEMATIC REORDERING MECHANISM FOR ON-CHIP NETWORKS USING
EFFICIENT CONGESTION-AWARE METHOD 74
Figura 3.15 Layout de rede 6 X 5 16
taxa de requisição é de�nida como a relação das injeções de requisição de leitura/escrita
na interface de rede sobre o número total de injeções realizadas. Foi considerado que
todos os núcleos e roteadores operam na freqüência de 1 GHz, e para uma comparação
justa, foi mantido a largura de banda constante em todas as con�gurações. Todas as
memórias (núcleos slave) podem ser acessadas simultaneamente por cada núcleo master
continuamente gerando requisições de memória.
3.3.3.2 Avaliação de Desempenho
Para avaliar o desempenho da abordagem propostos, padrões de tráfego sintéticos uni-
formes e não uniformes foram considerados. O tráfego randômico representa o caso mais
genérico, onde cada processador envia em ordem requisições de leitura e escrita para as
memórias com uma probabilidade uniforme de envio para os processadores.
A �gura 3.16 a e b apresentam os resultados considerando os modelos de tráfego
uniforme e não uniforme respectivamente. Na presente con�guração, a rede on-chip utili-
zando o método BGC, denotado pelo MS-GLB, é comparada com a rede sem a utilização
18Fonte: Daneshtalab [9]
3.3 A SYSTEMATIC REORDERING MECHANISM FOR ON-CHIP NETWORKS USING
EFFICIENT CONGESTION-AWARE METHOD 75
Figura 3.16 Avaliação de desempenho: a)No tráfego uniforme e b) No tráfego não uniforme 18
do método BGC. Como é demonstrado em ambas as �guras, comparado com a arqui-
tetura básica, a NoC usando o método BGC proposto reduz a latência média quando a
taxa de requisição cresce sob os modelos uniforme e não uniforme de tráfego. O ganho de
desempenho próximo ao ponto de saturação (0.6) sob o modelo de tráfego uniforme e não
uniforme é de aproximadamente 27% e 23% respectivamente. A razão desta melhoria é
devido ao uso da arbitragem adaptativa apresentada e ao mecanismo de escalonamento.
Isto permite que o método BGC reduza as áreas congestionadas e assim a latência da
rede é reduzida, o que permite que mais pacotes entrem na rede. O esquema adaptativo
do BGC incluindo a seleção de saída (roteamento), seleção de entrada (arbitragem do
roteador), e escalonador podem ser utilizados independentemente.
Figura 3.17 Ganho de Desempenho em Cada Componente do BGC 19
A �gura revela que sob o per�l do tráfego uniforme, o esquema de seleção de entrada
adaptativo (arbitragem do roteador) sozinho promove um ganho de desempenho de 22%
enquanto que ganho de desempenho para o esquema de seleção de saída (roteamento) e o
19Fonte: Daneshtalab [9]
3.4 COMPARAÇÃO DAS ABORDAGENS 76
escalonamento de requisições é de 12% e 14% respectivamente. Por outro lado, enquanto
a maior parte do tráfego é local sob o modelo não uniforme, o esquema de seleção de
saída supera o esquema de escalonamento. Isto ocorre porque a decisão de roteamento
é baseada na informação local de congestionamento. Também foi variado o tamanho do
bu�er do pacote da interface de rede slave para mostrar como este parâmetro afeta o
desempenho. O resultado disto pode ser visualizado na �gura 3.18. Esta �gura mostra
a latência média da rede próxima ao ponto de saturação (0.6) sob o per�l do tráfego
uniforme. Os resultados revelam que se o tamanho do bu�er dos pacotes aumenta, a
latência média da rede reduz. O método proposto BGC não somente alcança ganho de
desempenho signi�cativo, mas também permite a redução da área overhead do bu�er do
pacote para mais de 60%. Por exemplo, a arquitetura proposta com um bu�er de pacote
de tamanho 32 oferece um desempenho melhor que o bu�er de pacotes com tamanho 80
no método básico.
Figura 3.18 Tamanho do Bu�er do Pacote20
3.4 COMPARAÇÃO DAS ABORDAGENS
Para fazer uma avaliação das características das abordagens relacionadas a este trabalho,
é apresentado a seguir uma tabela comparativa.
20Fonte: Daneshtalab [9]
3.5 CONCLUSÃO 77
Tabela 3.2 Comparação entre as Abordagens RelacionadasTrabalho Algoritmo
de Rote-amento
Avaliaçãode con-gestiona-mento
Obtençãode dados
Reordemdos paco-tes
Divisãoda Rede
Dado doConges-tiona-mentoTrans-portado
CATRA AlgoritmoPróprio
Local eGlobal
Agentes - - Limiar deocupaçãodo bu�er
CARS Odd-Even Global Cabeçalhodos pa-cotes etabela decongestio-namento
Na inter-face derede
Master eSlave
N ◦ dePortasCongestio-nadas
Systematic Odd-Even Local eGlobal
Cabeçalhodos pa-cotes etabela decongestio-namento
Na inter-face derede
Master eSlave
N ◦ dePortasCongestio-nadas
3.5 CONCLUSÃO
Observando a tabela 3.2, pode-se veri�car que os trabalhos, em sua maioria, utilizam
algoritmos adaptativos e desta forma precisam de bu�ers de reordenação e estes por sua
vez estão localizados na interface de rede. Outro tópico apresentado pelo projeto [9] é a
utilização do congestionamento global como critério para escolha dos pacotes que serão
enviados primeiramente, ou seja, o congestionamento global é utilizado como critério
para retirar os pacotes do bu�er na interface slave. Portanto, este trabalho pretende
simpli�car o roteador, e conseqüentemente a rede NoC, com a utilização do bu�er de
reordenação acoplado ao núcleo de processamento, o multiprocessado, e com a utilização
do congestionamento local e global como métricas para escolha do melhor caminho para
envio do pacote dentre os caminhos escolhidos pelo algoritmo adaptativo Odd-Even e
assim, aumentar a e�ciência de entrega do pacote. Com estas modi�cações é pretendido
reduzir a latência na entrega das informações e potência consumida pela rede NoC.
78
CAPÍTULO 4
UMA ESTRATÉGIA DE ROTEAMENTO
ADAPTATIVA BASEADA EM
CONGESTIONAMENTO
Neste capítulo é apresentada a abordagem proposta, que tem como objetivo principal
a redução de congestionamento em uma plataforma MPSoC baseada em NoC. Neste
trabalho foi utilizado um algoritmo de roteamento adaptativo, que visa a redução da
latência no envio de mensagens e a potência consumida pelos roteadores.
4.1 VISÃO GERAL
O presente trabalho tem como ideia fundamental a redução do congestionamento ocasi-
onado pela grande quantidade de mensagens de coerência de cache e de prefetching que
trafegam na rede. Para isto, é utilizado o algoritmo de roteamento Odd-Even, que é um
algoritmo adaptativo, e como critério de escolha da porta para o qual o pacote será enca-
minhado é utilizado o nível de congestionamento local e global. Desta forma, o algoritmo
de roteamento possui uma visão local e global do congestionamento da rede. Este cálculo
do congestionamento local e global é realizado em cada roteador que forma a rede. Como
o algoritmo de roteamento é adaptativo e os pacotes podem sair da ordem, é utilizado
um bu�er de reordem, localizado da interface de rede de cada núcleo de processamento
do core.
O congestionamento local corresponde a quantidade de células do bu�er que estão ocu-
padas em cada roteador vizinho ao roteador. Na �gura 4.1 é possível visualizar a rede,
observe que o roteador, que é representado por um circulo com um x dentro, que está
4.1 VISÃO GERAL 79
rodeado por um circulo cinza, possui como vizinhos os roteadores que estão roteados por
quadrados cinza.
Figura 4.1 Roteadores Vizinhos
O congestionamento global corresponde a média dos congestionamentos que o pacote
passa ao longo do caminho até chegar ao seu destino. Este valor de congestionamento é
armazenado no cabeçalho do pacote.
O roteador possui uma tabela divida em regiões (nordeste, sudeste, sudoeste e noroeste),
que armazena os valores de congestionamento dos pacotes que passaram pelo roteador.
A divisão em regiões da rede é realizada utilizando as coordenadas X e Y do destino do
pacote.
Para realizar a escolha da porta para a qual o pacote deverá ser encaminhado, é utilizado
os valores de congestionamento local e global. Assim, a porta que possuir o menor valor de
congestionamento, será escolhida para enviar o pacote. O �uxo de execução do algoritmo
Odd-Even modi�cado pode ser visualizado na �gura 4.2.
A implementação do projeto poderá ser analisada com maior detalhes na próxima
seção.
4.2 DETALHES DA IMPLEMENTAÇÃO 80
Figura 4.2 Fluxo da Execução do Algoritmo Odd-Even Modi�cado
4.2 DETALHES DA IMPLEMENTAÇÃO
O presente projeto tem como objetivo apresentar uma estratégia de roteamento adapta-
tiva que reduz o congestionamento da uma rede NoC. A plataforma utilizada para este
projeto foi a plataforma In�nity, como é detalhado no capítulo 2.4. A �gura 4.3 apresenta
como estão distribuídos os componentes da plataforma.
Figura 4.3 Plataforma In�nity 1
Observe que a rede é formada por núcleos de processamento, que são apresentados
1Fonte: Aziz [19]
4.2 DETALHES DA IMPLEMENTAÇÃO 81
na imagem como core, por roteadores, que são representados na imagem por um círculo
preenchido por um x, e por dispositivos de entrada e saída, que são representados pelo
DMA, UART, Timer e controlador de interrupção APIC. Esta plataforma difere das
plataformas utilizadas nos trabalhos apresentados no capítulo 3, pois os trabalhos [9] e
[8] utilizaram somente a rede NoC desenvolvida em VHDL e o trabalho [4] utiliza uma
plataforma MPSoc híbrida com processadores e memórias acoplados a rede NoC. O núcleo
de processamento da plataforma In�nity é apresentada na �gura 4.4.
Figura 4.4 Núcleo de Processamento In�nity2
2Fonte: Aziz [19]
4.2 DETALHES DA IMPLEMENTAÇÃO 82
Este núcleo é formado pelo processador Sparc V8, pelos barramentos de interrupção
do processador e de periféricos, além do sistema de hierarquia de memória composto
por dois níveis e um banco de memória. Para o trafego de pacotes, dados e protocolos
de coerência de cache, o núcleo de processamento possui também uma interface de rede
para a NoC. A arquitetura também dispõe de um controlador avançado programável de
interrupção (APIC) para gerenciar as interrupções oriundas dos dispositivos e dos pro-
cessadores. A função do APIC é priorizar e distribuir as interrupções pelo barramento
de interrupções para os LAPICs (Local Advanced PICS), que são responsáveis por in-
terromper o processador. O barramento exclusivo para interrupções garante uma maior
escalabilidade ao sistema com o tempo de resposta por interrupção conhecido. Por �m, a
arquitetura possui um barramento de periféricos conectado diretamente aos processado-
res, onde todos os periféricos (TIMER e UART) estão conectados. Estes periféricos são
mapeados em memória. A coerência é realizada com a utilização de diretórios, sendo um
para cada banco de memória. Os diretórios armazenam estado e a localização dos dados
por ele gerenciados. Por �m, cada núcleo possui o seu banco de memória que, em con-
junto com outros bancos, formam a memória do sistema, formando um endereço global
para os bancos. A cache L2 e a memória são compartilhadas por todos os núcleos através
da NoC [19]. Como pode ser visualizado na �gura 4.3 a NoC realiza a conexão entre
os núcleos de processamento e para realizar a tradução da mensagem para um formato
que a rede possa encaminhar é utilizada a interface de rede que foi apresentada na seção
2.4.4.1.
Para o desenvolvimento deste projeto a interface de rede apresentada na seção 2.4.4.1 foi
modi�cada. Foi adicionado a numeração dos pacotes nas threads cacheIN e dorectoryIN,
para que fosse possível ordenar os pacotes que trafegam na rede, dado que o protocolo de
cache precisa que os dados estejam na seqüencia que foram enviados e o algoritmo adap-
tativo não garante esta ordem. A interface de rede após as alterações pode ser observada
na �gura 4.5. Também foi adicionado um módulo que é responsável pela ordenação dos
pacotes, o reorder bu�er. Este módulo recebe o pacote de dados vindo do roteador e
veri�ca a numeração do pacote. Caso esteja na ordem, encaminha o dado para a thread
4.2 DETALHES DA IMPLEMENTAÇÃO 83
SoCIN que faz a tradução dos sinais para procotolo de tal forma que o processador possa
processar. Senão, o pacote é armazenado no bu�er de reordem até que o próximo pacote
que está na ordem chegue ao reorder bu�er. Observe que todo o pacote é armazenado no
bu�er de reordem, caso ele não esteja na ordem.
Cada reorder bu�er possui para cada roteador da rede, com a exceção do próprio rote-
ador, um bu�er de reordem dedicado.O trabalhos apresentados no capítulo 3 também
possuem bu�er de reordem localizados na interface de rede.
Figura 4.5 Interface de Rede In�nity Modi�cada
Para que fosse possível manter a ordem dos pacotes e assim a coerência de cache
ser mantida, o pacote que trafega na rede NoC foi alterado para conter a numeração do
pacote. O novo formato do pacote é apresentado na �gura 4.6.
Fazendo a comparação com o pacote anterior que trafegava na rede, apresentado na
seção 2.4.4.2, as modi�cações foram: adição do �it que corresponde a numeração do
pacote e adição do campo congestionamento no espaço do campo HLP no cabeçalho do
pacote. Foi adicionado o campo congestionamento no cabeçalho do pacote, este campo
está representado po CS X (status de congestionamento X - sigla em inglês) e CS Y
(status de congestionamento Y - sigla em inglês) na �gura 4.6.
O campo CS X representa o congestionamento global e é armazenado em 3 bits, já o
campo CS Y representa o congestionamento local e é armazenado em 3 bits. Observe que
4.2 DETALHES DA IMPLEMENTAÇÃO 84
Figura 4.6 Novo Formato Pacote NoC
os sinais que fazem a ligação entre os roteadores são representados com 3 bits, mas isto só
é possível, porque o tamanho do bu�er de entrada dos roteadores é 4, então no pior caso,
com o bu�er totalmente lotado, só é necessário a representação do valor 4 (0,1,2,3 e 4),
que pode ser realizado com 3 bits. Caso o bu�er de entrada do roteador seja ampliado,
estes bits que representam o congestionamento local precisam ser ampliados de tal forma
que se consiga representar os novos valores possíveis. O pacote utilizado pelo roteador
ParIS permite o aumento do número de �its que compõem o cabeçalho, desta forma, o
aumento do número bits para a representação não será um empecilho para a utilização
desta técnica. O congestionamento local é obtido analisando a quantidade de pacotes que
estão armazenadas dentro do bu�er de entrada de cada porta dos roteadores vizinhos ao
roteador. A �gura 4.7 apresenta um exemplo da conexão dos sinais utilizados no cálculo
do congestionamento local.
O sinais CS Saida (CS saidaNorte, CS saidaSul, CS saidaLeste e CS saidaOeste) re-
presentam os valores de quantos pacotes estão armazenados no bu�er de entrada de cada
porta de entrada do roteador, já os sinais CS Vizinho (CS VizinhoNorte, CS VizinhoSul,
CS VizinhoLeste, CS VizinhoOeste), representam os valores de quantos pacotes estão ar-
mazenados no bu�er de entrada de cada porta de entrada dos vizinhos do roteador, como
por exemplo, o CS VizinhoNorte que corresponde a saída enviada pelo roteador que está
4.2 DETALHES DA IMPLEMENTAÇÃO 85
Figura 4.7 Sinais Utilizados para Cálculo do Congestionamento Local
conectado a porta norte do roteador e o valor enviado por este sinal corresponde a quan-
tidade de pacotes que estão armazenados no bu�er de entrada da porta de entrada deste
roteador vizinho. Observe que a porta local, que está conectada à interface de rede, não
possui nenhum destes sinais e não participa do cálculo do congestionamento local. Isto
ocorre porque na porta local está conectada a interface de rede que possui um bu�er de
reordenação para os pacotes fora de ordem. Se os pacotes estiverem na ordem, a inter-
face de rede começará o processamento do dado imediatamente, desta forma não se faz
necessário o armazenamento do pacote no bu�er do roteador.
O congestionamento global corresponde aos valores de congestionamento de cada um dos
roteadores que o pacote passou até chegar ao seu destino. Assim, este valor corresponde
a uma visão global do congestionamento a que o pacote foi submetido. O valor deste
congestionamento é escrito no cabeçalho do pacote e dividido em dois campos, como já
foi apresentado anteriormente. O valor de CS Y é obtido pelo seguinte cálculo:
4.2 DETALHES DA IMPLEMENTAÇÃO 86
CSY = (CSV izinhoNorte+CSV izinhoLeste+CSV izinhoOeste+CSV izinhoSul)/4
(4.1)
Observando a equação (4.1) o campo CS Y armazena o valor médio do congestio-
namento, dado pela quantidade de pacotes armazenados no bu�er de entrada, de cada
roteador vizinho ao roteador. Este conceito foi obtido do trabalho [9], mas a forma de
representação deste valor foi modi�cada. No trabalho [9] o valor do congestionamento é
representado em 2 bits e para isto é necessário a utilização de uma tabela de conversão
como poder ser observado na seção 3.3.2.4. Esta forma de representação reduz o número
de bits utilizados, mas não apresenta o valor a que o congestionamento está e sim um
intervalo. Esta representação por ser mínima, di�culta os cálculos do congestionamento e
necessita da utilização de números fracionários. Portanto, neste trabalho foram utilizados
mais bits para representar o congestionamento, mas o cálculo do congestionamento �ca
mais simples e utiliza somente inteiros.
Para a representação do congestionamento CS X, que equivale ao congestionamento glo-
bal dentro de uma região, é necessário compreender a divisão da rede.
A rede NoC foi dividida nas regiões: nordeste, sudeste, noroeste e sudoeste e desta forma
o congestionamento pode ser mensurado por regiões. Este conceito foi obtido do trabalho
[9], e para Daneshtalab o valor do congestionamento global é utilizado para escolher qual
o pacote que será enviado primeiro no roteador. Para este trabalho, o valor do conges-
tionamento global serve para dar uma visão mais geral do congestionamento da rede ao
algoritmo de roteamento. Para o cálculo do congestionamento global foi adicionado ao
roteador uma tabela onde são adicionados os valores de congestionamento por área. A
atualização dos valores de congestionamento por área é realizado fazendo-se a média entre
o valor preexistente na tabela com valor obtido do cabeçalho do pacote que chegou. Esta
tabela foi adicionada no módulo IC do roteador ParIS. Na tabela 4.1 é apresentado um
exemplo de como a tabela armazena os valores.
Observando a tabela é possível notar que alguns pacotes já passaram pelo roteador,
4.2 DETALHES DA IMPLEMENTAÇÃO 87
Tabela 4.1 Exemplo de Quadro de CongestionamentoÁrea Valor do
Conges-tiona-mento
Nordeste 2Noroeste 1Sudeste 0Sudoeste 3
pois algumas áreas já possuem valores de congestionamento diferentes de zero. A região
Sudoeste é a mais congestionada, pois possui o valor 3 como valor de congestionamento
global. Com o entendimento das regiões é possível avaliar o cálculo do congestionamento
CS X, observe a equação (4.2):
CSX = (CGNordeste+ CGSudeste+ CGNoroeste+ CGSudoeste)/4 (4.2)
O algoritmo utilizado para atualizar a tabela de congestionamento global será apre-
sentado na seção 4.4. Para que o pacote chegue ao seu destino �nal é necessário que
os roteadores encaminhem a mensagem até que a mesma chegue ao roteador que está
acoplado a interface de rede a que o pacote se destina. O algoritmo responsável por esta
atividade é o algoritmo de roteamento e neste trabalho foi utilizado o algoritmo Odd-
Even, que é um algoritmo adaptativo. O funcionamento deste algoritmo é apresentado
na seção 4.3. Como os algoritmos adaptativos fornecem como resposta várias rotas que
o pacote pode seguir, neste trabalho foi utilizado como critério de escolha a rota gerada
pelo algoritmo Odd-Even, o qual minimiza o congestionamento global e local da rede.
Assim o roteamento decidirá o melhor caminho baseado nas características da rede. O
cálculo utilizado para a obtenção do congestionamento utilizado como critério de escolha
do algoritmo Odd-Even é apresentado na seção 4.4.1. A rede SoCINfp que utiliza o rotea-
dor ParIS, já possuía o algoritmo Odd-Even implementado, portanto só foram necessários
4.3 ALGORITMO DE ROTEAMENTO ODD-EVEN 88
o seguintes ajustes:
� No módulo IC do roteador ParIs:
� Adição do cálculo do congestionamento local e global;
� adição da tabela de congestionamento por região e do algoritmo de atualização
da tabela;
� No Módulo Paris do roteador ParIS:
� Adição das portas de comunicação com os roteadores vizinhos;
� No módulo FIFO de entrada do roteador ParIs:
� Escrita do valor de congestionamento global no cabeçalho do pacote.
Os módulos internos do roteador ParIS foram apresentados na seção 2.4.3. Nesta
seção é possível observar o diagrama e onde foram realizadas cada uma destas alterações.
4.3 ALGORITMO DE ROTEAMENTO ODD-EVEN
Este algoritmo é parcialmente adaptativo, pois permite múltiplas escolhas para o rotea-
mento dos pacotes [7]. Este algoritmo é deadlock-free e não necessita de canais virtuais
para seu funcionamento. No modelo Odd-Even, uma malha 2D é de�nida como sendo
composta por linhas (nós com o mesmo valor na coordenada y) e colunas (nós com o
mesmo valor na coordenada x). Uma coluna é dita par se for identi�cada por um valor
par, ou ímpar se o valor da coordenada for ímpar. Por exemplo, em uma malha K0XK1,
a coluna (2,j), com 0 < j < K1 − 1, é uma coluna par. O ideia básica deste algoritmo
é impedir que certos giros ocorram em uma dada posição da rede, como leste-norte e
norte-oeste (ou leste-sul e sul-oeste) em uma mesma coluna [7]. Para que este método
funcione algumas regras precisam ser seguidas, são elas:
Regra 1 Não é permitido a nenhum pacote realizar um giro leste-norte em nós localiza-
dos em colunas pares e nem giros norte-oeste em nós localizados em colunas ímpares.
4.3 ALGORITMO DE ROTEAMENTO ODD-EVEN 89
Regra 2 Não é permitido a nenhum pacote realizar um giro leste-sul em nós localizados
em colunas pares, nem giros sul-oeste em nós localizados em colunas ímpares.
O fundamento básico deste modelo é impedir que um pacote proveniente de um nó
mais a oeste na rede (um pacote que realizou um deslocamento para o leste) retorne para
o oeste após ser transmitido para o norte ou sul. A �gura 4.8 ilustra este conceito e o
pseudo-código deste algoritmo pode ser visualizado no algoritmo 1.
Figura 4.8 Algoritmo OE
Na �gura 4.8 é apresentada algumas possibilidades de caminhos de roteamento para
quatro pacotes em uma rede mesh 9 X 9. Si e Di representam o nó fonte e o nó destino
do pacote pi, 1 ≤ i ≤ 4. Os pacotes p1, p2, p3 e p4 perfazem estes caminhos descritos na
�gura, porque vários roteadores ao longo do caminho do pacote se encontram congestio-
nados, como é apresentado pelos círculos preenchidos com pontos, e desta forma somente
uma das portas de cada roteador está livre para fazer o encaminhamento do pacote.
A grande vantagem deste algoritmo é que a cada execução dele, vários caminhos são
4.3 ALGORITMO DE ROTEAMENTO ODD-EVEN 90
Algoritmo 1: Algoritmo Odd-Even
/*Nó fonte: (s0,s1); nó destino:(d0,d1); nó atual: (c0,c1) */conjunto− direcoes− possiveis← φe0 ← d0 − c0e1 ← d1 − c11: if e0 = 0 e e1 = 0 then2: Entrega o pacote no nó local e sai;3: end if4: if e0 = 0 then5: if e1 > 0 then6: adiciona Norte ao conjunto-direcoes-possiveis;7: else8: adiciona Sul ao conjunto-direcoes-possiveis;9: end if10: else11: if e0 > 0 then12: // mensagens para o leste13: if e1 = 0 then14: adiciona Leste ao conjunto-direcoes-possiveis;15: else16: if c0 é ímpar ou c0 = s0 then17: if e1 > 0 then18: adicione Norte ao conjunto-direcoes-possiveis;19: else20: adicione Sul ao conjunto-direcoes-possiveis;21: end if22: end if23: if d0 é ímpar ou e0 6= 1 then24: //coluna de destino ímpar ou ≥ 2 colunas do destino25: adicione Leste ao conjunto-direcoes-possiveis;26: end if27: end if28: else29: //mensagens para o oeste30: adicione Oeste ao conjunto-direcoes-possiveis;31: if c0 é par then32: if e1 > 0 then33: adicione Norte ao conjunto-direcoes-possiveis;34: else35: adicione Sul ao conjunto-direcoes-possiveis;36: end if37: end if38: end if39: //Selecione uma direção do conjunto-direcoes-possiveis para encaminhar o pacote40: end if
4.4 ALGORITMO DE ATUALIZAÇÃO DA TABELA DE REGIÕES 91
possíveis e assim pode-se evitar o congestionamento da rede evitando as áreas mais so-
brecarregadas. O cálculo do valor de congestionamento utilizado como critério de escolha
será apresentado na seção 4.4.1.
4.4 ALGORITMO DE ATUALIZAÇÃO DA TABELA DE REGIÕES
Cada vez que um pacote chega a um roteador, o valor do status de congestionamento do
cabeçalho do pacote é obtido (CS X e CS Y) e a tabela com os valores de congestionamento
da rede dividida por área, tem o valor atualizado, seguindo o algoritmo 2:
O congestionamento é armazenado seguindo a tabela apresentada em 4.1. Observe
que se o pacote vier da porta oeste do roteador, o valor do congestionamento é atualizado
utilizando os valores de congestionamento das regiões que possuem alguma conexão com
a direção oeste (noroeste e sudoeste) e assim para as demais regiões. Este conceito foi
retirado do trabalho [9], mas foram realizadas modi�cações, pois no trabalho [9] existe a
divisão de interfaces master e slave e neste trabalho não existe este conceito, pois todos
os núcleos de processamento da plataforma In�nity podem enviar e/ou receber pacotes.
Assim, a contribuição deste do trabalho [9] foi a ideia da tabela de congestionamento.
Observe também que o cálculo realizado para atualizar o valor de congestionamento de
cada região é uma média do valor preexistente na tabela com o valor que foi obtido
no cabeçalho do pacote. Como este valor pode resultar em um número fracionário, é
utilizada a função teto para se obter o valor inteiro mais próximo do resultado obtido. A
seguir é apresentada a utilização do congestionamento global e local na escolha do melhor
caminho para o encaminhamento do pacote.
4.4.1 Cálculo Congestionamento - Critério de Escolha
Após o roteador realizar o cálculo de quais portas poderão ser utilizadas para o envio do
pacote, é dado início ao processo de veri�cação do congestionamento e escolha da porta.
O cálculo do congestionamento é dado por uma soma dos congestionamentos global e lo-
cal, mas utilizando pesos para cada valor do congestionamento. Observe na equação (4.3):
4.4 ALGORITMO DE ATUALIZAÇÃO DA TABELA DE REGIÕES 92
Algoritmo 2: Algoritmo de Atualização da Tabela de Congestiona-
mento1: FUNCTION Atualiza Tabela de Congestionamento2: if Xdestino < Xatual and Ydestino = Yatual then3: CGNoroesteX <= teto((CGNoroesteX + CSX)/2)4: CGSudoesteX <= teto((CGSudoesteX + CSX)/2)5: CGNoroesteY <= teto((CGNoroesteY + CSY )/2)6: CGSudoesteY <= teto((CGSudoesteY + CSY )/2)7: else if Xdestino > Xatual and Ydestino = Yatual then8: CGNordesteX <= teto((CGNordesteX + CSX)/2)9: CGSudesteX <= teto((CGSudesteX + CSX)/2)10: CGNordesteY <= teto((CGNordesteY + CSY )/2)11: CGSudesteY <= teto((CGSudesteY + CSY )/2)12: else if Xdestino = Xatual and Ydestino > Yatual then13: CGNoroesteX <= teto((CGNoroesteX + CSX)/2)14: CGNordesteX <= teto((CGNordesteX + CSX)/2)15: CGNoroesteY <= teto((CGNoroesteY + CSY )/2)16: CGNordesteY <= teto((CGNordesteY + CSY )/2)17: else if Xdestino = Xatual and Ydestino < Yatual then18: CGSudesteX <= teto((CGSudesteX + CSX)/2)19: CGSudoesteX <= teto((CGSudoesteX + CSX)/2)20: CGSudesteY <= teto((CGSudesteY + CSY )/2)21: CGSudoesteY <= teto((CGSudoesteY + CSY )/2)22: else if Xdestino < Xatual and Ydestino < Yatual then23: CGSudoesteX <= teto((CGSudoesteX + CSX)/2)24: CGSudoesteY <= teto((CGSudoesteY + CSY )/2)25: else if Xdestino > Xatual and Ydestino < Yatual then26: CGSudesteX <= teto((CGSudesteX + CSX)/2)27: CGSudesteY <= teto((CGSudesteY + CSY )/2)28: else if Xdestino < Xatual and Ydestino > Yatual then29: CGNoroesteX <= teto((CGNoroesteX + CSX)/2)30: CGNoroesteY <= teto((CGNoroesteY + CSY )/2)31: else if Xdestino > Xatual and Ydestino > Yatual then32: CGNordesteX <= teto((CGNordesteX + CSX)/2)33: CGNordesteY <= teto((CGNordesteY + CSY )/2)34: end if35: endfunction
4.5 CONCLUSÃO 93
Para α ≥ 0 e α ≤ 10.
valor de congestionamento da porta = (α ∗ congestionamentoLocal)+
((10− α) ∗ (congestionamentoGlobalRoteador + congestionamentoGlobalV izinhos)
(4.3)
O peso de cada valor de congestionamento, global e local, na equação é dado pela
variável alpha. Observe que a utilização do peso alpha é uma forma de balancear a equa-
ção e ter somente números inteiros, o intervalo de variação de alpha indicará somente a
precisão do valor. A cada iteração do algoritmo Odd-even são armazenados não só as
possíveis portas para encaminhamento do pacote, como também o valor do congestio-
namento local de cada uma delas. Ao terminar a execução do algoritmo Odd-Even são
calculadas as coordenadas X e Y do possível destino do pacote e, utilizando estas coor-
denadas, é obtido o valor do congestionamento global da área a que o pacote se destina,
para cada uma das possíveis opções de rota. Com todos estes valores já obtidos é possível
calcular o valor de congestionamento da porta, como apresentado na equação supracitada.
Com os valores de congestionamento de cada porta, é realizada a comparação dos valores
de congestionamento de cada porta candidata. Aquela porta que tiver o menor valor de
congestionamento é a escolhida como a porta para qual o pacote deverá ser encaminhado.
4.5 CONCLUSÃO
A modi�cação da plataforma existente e o acréscimo das métricas de congestionamento,
bem como o bu�er de reordenação estar agregado ao núcleo de processamento, tem como
objetivo a redução da latência de envio dos dados e a redução da potência consumida
pela rede. Os resultados que foram obtidos com este projeto são apresentados no capítulo
a seguir, o capítulo 5.
94
CAPÍTULO 5
EXPERIMENTOS E RESULTADOS
Este capítulo descreve os experimentos realizados para validação da técnica de redução
de congestionamento e os resultados obtidos a partir destes experimentos. Para o desen-
volvimento do projeto foi utilizada a Plataforma In�nity, que por ser um ambiente de
simulação permite ser con�gurada de diversas formas. Os parâmetros que foram explo-
rados foram somente aqueles que são relativos a rede NoC, permanecendo constante os
valores de núcleos de processamento, memórias e caches, como será apresentado a seguir.
5.1 CONFIGURAÇÃO DA PLATAFORMA INFINITY
Para as várias execuções do sistema foram utilizados os seguintes parâmetros da plata-
forma, apresentados na tabela 5.1.
Os demais parâmetros que foram variados ao longo da execução serão apresentados
durante a apresentação dos resultados. A seguir serão apresentadas as métricas que foram
utilizadas na validação deste trabalho.
5.2 MÉTRICAS AVALIADAS
Para a validação deste trabalho foram utilizadas duas métricas: energia consumida da
rede e latência na entrega dos pacotes.
5.2.1 Energia Consumida
Omodelo da energia dinâmica consumida por um roteador da NoC considera a quantidade
de pacotes trafegados no roteador, a potência dissipada pelo roteador para passar um
5.2 MÉTRICAS AVALIADAS 95
Tabela 5.1 Parâmetros utilizados na RedeParâmetro Valor
Quantidade de Núcleos 16Tipo da Rede 2D meshTamanho do Bu�er de Entrada 4Processador SPARC V8 Estendido, 1GHz, 32 bitsMemória 64MB de RAM; Endereçamento GlobalCache L1 Privada, 4 palavras por bloco, mapea-
mento direto, 1KBCache L2 64KB por banco; Compartilhada, 8 pala-
vras por bloco, 16-wayRede NoC SoCINfp; roteador ParISAlgoritmo de Roteamento algoritmo adaptativo Odd-EvenChaveamento pacote (wormhole)Controle de Fluxo CréditoArbitragem Round-robinMemorização entrada (bu�er de entrada)
pacote através dele e o período de tempo que o roteador �cou ativo durante a execução
de uma aplicação [13]. O cálculo utilizado é apresentado a seguir:
Eri = Qri.Pri.tri
onde Qri corresponde ao número total de pacotes trafegados no roteador ri, Pri equivale
a potência média dissipada por um roteador ri para passar um pacote através dele e tri
corresponde ao período de tempo que o roteador ri está em atividade durante a execução
de uma aplicação. Com a informação do consumo de energia de um roteador é possível
calcular a energia dinâmica consumida por todos os roteadores da rede, observe:
Eenlaces =l−1∑i=0
(Qli.Pli).tli
onde Qli, Pli e tli representam o total de pacotes trafegados no enlace, a potência dissipada
pelo enlace li para passar um pacote através dele e o tempo trabalhado pelo li durante a
execução da aplicação respectivamente. Já a energia total consumida pela NoC é baseada
nas energias dinâmicas dos roteadores, dos enlaces e da energia estática da NoC. A energia
5.3 RESULTADOS 96
total consumida é dada por:
Etotal = Eroteadores + Eenlaces + Eestatica
Dado que a potência consumida em cada enlace é muito menor que a energia consumida
pelos roteadores, este cálculo de energia negligenciou a energia dinâmica Eenlace frente a
Eroteadores [13]. Assim a energia total é dada por:
Etotal = Eroteadores + Eestatica
5.2.2 Latência
Neste trabalho, como métrica de desempenho, foi utilizado o conceito de latência de�nido
como o intervalo de tempo, dado em ciclos de clock, em que o primeiro pacote da aplicação
é lançado na rede NoC e o tempo que o último pacote é recebido da NoC.
5.3 RESULTADOS
Neste tópico serão apresentados os resultados obtidos com a utilização do algoritmo Odd-
even modi�cado. Esta técnica será avaliada por uma aplicação e por geradores de tráfego.
5.3.1 Picture in Picture
Esta aplicação simula o comportamento dos receptores de televisão e de outros disposi-
tivos semelhantes, em que um programa (canal) é exibido simultaneamente em um ou
mais programas em pequenas janelas, na mesma tela. O som emitido pelo aparelho é
geralmente associado ao programa principal. Esta aplicação foi utilizada, pois ela é uma
aplicação distribuída entre os núcleos da rede. A imagem 5.1 apresenta como a imagem
é apresentada na tela.
Para esta aplicação foi comparado a execução do algoritmo XY com o algoritmo OE
com visão de congestionamento. O peso utilizado na equação de congestionamento para
5.3 RESULTADOS 97
Figura 5.1 Aplicação PIP1
esta aplicação foi de α igual a 0.5. Os resultados deste experimento em relação a energia
consumida, dada em joules, para cada um dos roteadores utilizando o algoritmo XY são
apresentados no grá�co 5.1 e para cada um dos roteadores utilizando o algoritmo Odd-
Even modi�cado, são apresentados no grá�co 5.2.
Grá�co 5.1 Energia Consumida pelo Algoritmo de Roteamento XY para a Aplicação PIP
A comparação da energia consumida por todos os roteadores da rede para os algorit-
5.3 RESULTADOS 98
Grá�co 5.2 Energia Consumida pelo Algoritmo de Roteamento OE para a Aplicação PIP
mos XY e OE são apresentados na no grá�co 5.3.
Grá�co 5.3 Comparação da Energia Consumida pelo Algoritmo XY e Algoritmo OE
Observe que a técnica desenvolvida neste projeto conseguiu uma redução de 13,35%
da energia consumida por todos os roteadores da rede em relação ao algoritmo XY. A
latência obtida no envio dos pacotes utilizando a aplicação PIP para o algoritmo XY e
Odd-Even modi�cados são apresentados na tabela 5.2.
Observe que a diferença entre o XY e o Odd-Even modi�cado, utilizando como métrica
5.3 RESULTADOS 99
Tabela 5.2 Latência Obtida com a Aplicação PIPAlgoritmo LatênciaAlgoritmo XY 3.289.399 ciclosAlgoritmo Odd-Even modi�cado 3.161.924 ciclos
a latência é de 127.475 ciclos a menos para o algoritmo Odd-Even. Portanto, a abordagem
proposta apresentou uma melhora de aproximadamente 4%.
5.3.2 Gerador de Tráfego Uniforme e Não-Uniforme
Foram desenvolvidos dois geradores de tráfego para auxiliar na validação do algoritmo
de roteamento proposto; um gerador de tráfego uniforme e um gerador de tráfego não-
uniforme. O conceito de cada um destes tipos de tráfego é descrito a seguir:
� Tráfego Uniforme - Cada roteador que forma a NoC envia pacotes para todos os
demais nós da rede;
� Tráfego Não-Uniforme - Cada roteador que forma a NoC envia pacotes para todos
os demais nós da rede e um dos roteadores envia o dobro dos pacotes para os
roteadores vizinhos a ele.
Nestes experimentos não foi utilizada a plataforma In�nity, mas somente a rede NoC
interligada a interface de rede. Drivers geradores de tráfego foram conectados a interface
de rede e a nova estrutura pode ser visualizada na �gura 5.2.
Vale salientar que os drivers é que são responsáveis pela geração do tráfego uniforme
e não uniforme, e que a rede utilizada possui 16 roteadores (rede 4 X 4). A geração do
tráfego foi realizada tomando como base o experimento realizado por [20]. No trabalho
[20] são apresentados os cálculos para a geração de tráfego a uma taxa especí�ca. Nele é
apresentada a capacidade de transmissão e os períodos ociosos necessários à geração do
tráfego. A capacidade de transmissão da rede é descrita pela equação (5.1).
5.3 RESULTADOS 100
Figura 5.2 Estrutura de Teste
chr = flitsize/ciclo (5.1)
Onde:
chr : Capacidade de transmissão
�itsize : Quantidade de bits de um �it;
ciclo : Tempo (em ciclos de clock) necessários para transmitir um �it.
A capacidade de transmissão representa a taxa máxima que a rede é capaz de trans-
mitir, ou seja, a capacidade total da rede (100%). Para a geração de tráfego que corres-
ponda a uma fração da carga total, é necessária a utilização de tempos ociosos para que
a taxa de transmissão seja atingida. O cálculo do tempo ocioso é dado pela equação (5.2).
Idle = pcksize ∗ ncyclesflit ∗(chr
ipr− 1
)(5.2)
5.3 RESULTADOS 101
Onde:
idle : Tempo Ocioso;
pcksize : Quantidade de �its de um pacote;
ncycles�it : Tempo (em ciclos de clock) necessários para transmitir um �it;
chr : Capacidade de transmissão;
ipr : taxa de transmissão do núcleo gerador.
Os experimentos foram subdivididos em 4 partes chamadas de experimento 1, 2, 3 e
4. No experimento 1 foi realizada a geração de tráfego utilizando 54 ciclos de clock entre
um envio e outro de pacotes para os roteadores da rede. Este experimento foi realizado
para o envio de 16 pacotes para cada um dos roteadores da rede, ou seja, a cada 54 ciclos
de clock era enviado 1 pacote para cada outro roteador da rede, e isto foi executado
em paralelo por cada um dos roteadores da rede. Já o experimento 2 foi realizado a
geração de tráfego utilizando 24 ciclos de clock entre um envio e outro de pacotes para os
roteadores da rede e este experimento foi realizado para o envio de 20 pacotes para cada
roteador da rede. O experimento 3 realiza a geração de tráfego utilizando 10 ciclos de
clock entre um envio e outro de pacotes para os roteadores da rede. Este experimento foi
realizado para o envio de 30 pacotes para cada um dos roteadores da rede. Finalmente,
o experimento 4 realiza a geração de tráfego utilizando 4 ciclos de clock entre um envio e
outro de pacotes para a rede e este experimento foi realizado para o envio de 40 pacotes
para os roteadores da rede. A tabela 5.3 apresenta a divisão dos experimentos utilizada.
Tabela 5.3 Divisão dos ExperimentosExperimento Ciclos entre Envios Número de Pacotes
(Repetição)
Experimento 1 54 ciclos 16 pacotesExperimento 2 24 ciclos 20 pacotesExperimento 3 10 ciclos 30 pacotesExperimento 4 4 ciclos 40 pacotes
No grá�co 5.4 são apresentados os resultados obtidos com o tráfego uniforme para o
algoritmo XY em relação a métrica latência, para os experimentos 1,2,3 e 4.
5.3 RESULTADOS 102
Grá�co 5.4 Desempenho do Algoritmo XY - Tráfego Uniforme
No grá�co 5.5 são apresentados os resultados obtidos com o tráfego uniforme para o
algoritmo Odd-Even sem modi�cação para a métrica latência, para os experimentos 1,2,3
e 4.
Grá�co 5.5 Desempenho do Algoritmo Odd-Even sem Modi�cação - Tráfego Uniforme
Observe no grá�co 5.4 que quanto maior a quantidade de pacotes e menor o tempo,
maior a latência do XY. O mesmo ocorre para o algoritmo Odd-Even no grá�co 5.5
A seguir são apresentados os resultados obtidos com a utilização do algoritmo Odd-Even
modi�cado para o tráfego uniforme e variando o valor de alfa. Os valores de alfa utilizados
foram 0,2,5,8,10. Estes valores de alfa foram escolhidos, porque eles abrangem os valores
5.3 RESULTADOS 103
extremos (0 e 10), o valor intermediário (5) e os valores entre o valor intermediário e os
valores extremos (2 e 8).
Grá�co 5.6 Desempenho do Algoritmo Odd-Even Modi�cado - Tráfego Uniforme
Observe no grá�co 5.6 que o valor de alfa que apresentou melhores resultados foi o
alfa igual a 2, onde o congestionamento da porta é formado pelo congestionamento global
e local. Exceção ocorreu no experimento 3 onde o valor de alfa igual 10 obteve o melhor
resultado. Neste caso o congestionamento da porta foi formado apenas pelo congestio-
namento local. O pior resultado do algoritmo odd-even modi�cado foi quando o valor
de alfa foi igual 0. Neste caso o valor de congestionamento da porta �ca determinado
somente pelo valor do congestionamento local e assim o algoritmo só possui uma visão
global do congestionamento.
Observe que comparando os melhores resultados obtidos com o algoritmo Odd-Even mo-
di�cado com o algoritmo XY e Odd-Even sem modi�cação, que são apresentados no grá-
�co 5.7, foram obtidas melhorias com o algoritmo Odd-Even modi�cado. As melhorias
apresentadas em relação aos algoritmos são apresentadas na tabela 5.4.
5.3 RESULTADOS 104
Tabela 5.4 Melhorias apresentadas com a utilização da estratégia em relação ao Algoritmo XYExperimento Valor de Alfa (Odd-
Even Modi�cado)Melhoria em Por-centagem XY
Melhoria em Por-centagem Odd-
Even sem Modi�-cação
Experimento 1 2 25% 22%Experimento 2 2 19% 18%Experimento 3 2 23% 20%Experimento 4 2 17% 19%
Grá�co 5.7 Comparação Latência Algoritmos - Tráfego Uniforme
Na análise do tráfego não-uniforme foram realizados dois experimentos, variando entre
eles, o local do roteador escolhido para enviar o quádruplo dos pacotes a seus vizinhos.
A �gura 5.3 apresenta os roteadores escolhidos.
Os roteadores escolhidos para o experimento são os apresentados na �gura 5.3 e que
estão envolvidos por um círculo. Observe que foram escolhidos dois roteadores, o pri-
meiro deles está localizado na extremidade esquerda da rede. Na numeração da rede ele
corresponde ao roteador de número 3, e o segundo está posicionado no meio da rede. Na
numeração da rede este último corresponde ao roteador de número 10. Eles foram esco-
lhidos por causa de sua posição, um roteador nesta rede pode estar na extremidade ou
no meio da rede. Os resultados obtidos para o tráfego não-uniforme aplicado ao roteador
mais a extremidade esquerda da rede, roteador 3, são apresentados a seguir.
5.3 RESULTADOS 105
Figura 5.3 Roteadores Utilizados na Geração do Trafego Não-uniforme
Para o algoritmo de roteamento XY, foram obtidos os seguintes valores de latência apre-
sentados no grá�co 5.8 para o tráfego não uniforme utilizando o roteador 3.
Grá�co 5.8 Desempenho do Algoritmo XY - Tráfego Não-Uniforme (Roteador 3)
Para o algoritmo Odd-Even sem modi�cação foram obtidos os resultados apresentados
no grá�co 5.9.
Para o algoritmo Odd-Even modi�cado, foram obtidos os resultados apresentados no
grá�co 5.10 para o tráfego não uniforme utilizando o roteador 3.
Observe que não houve variação dos valores apresentados pelo algoritmo XY, Odd-
Even sem modi�cação e nem para os valores apresentados pelo algoritmo Odd-Even
5.3 RESULTADOS 106
Grá�co 5.9 Desempenho do Algoritmo Odd-Even sem Modi�cação - Tráfego Não-Uniforme(Roteador 3)
Grá�co 5.10 Desempenho do Algoritmo OE Modi�cado - Tráfego Não-Uniforme (Roteador 3)
modi�cado,com exceção dos resultados apresentados pelo algoritmo Odd-Even modi�cado
para alfa igual a 0. Mas os melhores valores apresentados pelo algoritmo Odd-Even
modi�cado ainda são para alfa igual a 2 e alfa igual a 10.
Para o tráfego não-uniforme utilizando o roteador 10 como roteador que envia o quádruplo
de mensagens para seus vizinhos, foram obtidos os resultados que são apresentados a
seguir.
Para o algoritmo XY, foram obtidos os resultados apresentados no grá�co 5.11.
5.3 RESULTADOS 107
Grá�co 5.11 Desempenho do Algoritmo XY - Tráfego Não-Uniforme (Roteador 10)
Para o algoritmo Odd-Even sem modi�cação foram obtidos os resultados apresentados
no grá�co 5.12.
Grá�co 5.12 Desempenho do Algoritmo Odd-Even sem Modi�cação - Tráfego Não-Uniforme(Roteador 10)
Para o algoritmo Odd-Even modi�cado foram obtidos os resultados apresentados no
grá�co 5.13.
Observe que novamente neste experimento não houveram alterações no algoritmo
XY, no Odd-Even sem modi�cação e nem no algoritmo Odd-Even modi�cado, com a
exceção dos resultados obtidos quando alfa é igual a 0, que corresponde a quando o
congestionamento da porta é avaliado somente pelo congestionamento global.
5.3 RESULTADOS 108
Grá�co 5.13 Desempenho do Algoritmo OE - Tráfego Não-Uniforme (Roteador 10)
Com os resultados apresentados, é possível observar que para o melhor caso do algoritmo
Odd-Even modi�cado é apresentada uma melhoria de aproximadamente 25% em relação
ao algoritmo XY e de 23% em relação ao algoritmo Odd-Even sem modi�cação.
109
CAPÍTULO 6
CONCLUSÃO
Neste trabalho foi apresentado uma técnica para redução de congestionamento para siste-
mas multiprocessadores baseados em NoC. O objetivo desta técnica é encontrar caminhos
com menor tráfego e encaminhar o pacote por este.
Para atingir este objetivo o trabalho utilizou o algoritmo Odd-even para realizar a es-
colha das portas possíveis para encaminhar o pacote. Após esta escolha é veri�cado o
congestionamento local, analisando o estado do bu�er de entrada de cada um dos vizinhos
do roteador. O congestionamento global, que está localizado no cabeçalho do pacote é
atualizado a cada entrada, em um novo roteador durante o caminho que o pacote percorre
na rede até o seu destino. Finalmente, o caminho é escolhido e o pacote enviado.
Um experimento foi realizado na Plataforma In�nity, desenvolvida por André Aziz [19].
Esta plataforma foi modi�cada para dar suporte a análise de potência e latência, previ-
amente desenvolvidos por Max Santana [13] e utilizou a NoC SoCINfp desenvolvida por
César Zeferino [5]. A contribuição deste trabalho foi adicionar ao algoritmo de rotea-
mento Odd-Even, que está localizado no roteador ParIS da rede NoC SoCINfp, o critério
de congestionamento local e global à escolha da porta para o qual o pacote deverá ser
encaminhado. Esta plataforma permite a execução de aplicações que realizam trocas
de mensagens de coerência de cache e que permitem o estudo do comportamento do
algoritmo diante do tráfego gerado. O experimento utilizou a aplicação PIP (Picture-in-
Picture) e a abordagem proposta neste trabalho foi comparada com o algoritmo XY e
Odd-Even sem modi�cações utilizando como métricas a latência de envio dos pacotes e
consumo de energia.
Outros experimentos foram realizados utilizando os geradores de tráfego sintéticos uni-
forme e não uniforme aplicados a NoC SoCINfp desenvolvida por César Zeferino [5] e
CONCLUSÃO 110
modi�cada neste trabalho. Novamente a abordagem proposta foi comparada com o algo-
ritmo XY e Odd-Even sem modi�cações, mas utilizando como métrica somente a latência
do envio dos pacotes.
Os experimentos foram realizados com uma rede de 16 núcleos (rede 4X4). Os resultados
foram obtidos utilizando-se a plataforma In�nity, através da qual a técnica proposta de-
monstrou uma redução a energia consumida em 13,35% em comparação com o algoritmo
XY, e uma redução na latência do envio dos pacotes em 4% para α igual 0.5. Já os re-
sultados apresentados nos experimentos realizados com a NoC e os geradores de tráfego,
apresentaram uma melhoria de até 25% na latência do envio dos pacotes. Foi possível
também observar a variação do peso na equação de escolha da melhor rota gerada pelo
algoritmo Odd-Even neste experimento, e assim veri�car que para o tráfego uniforme e
não-uniforme os melhores valores de α são 2 e 10.
Como trabalhos futuros foram identi�cados as seguintes melhorias: alterar dinamica-
mente o valor do peso α, que é utilizado no cálculo de congestionamento da abordagem
proposta. Desta forma serão obtidas melhorias na métrica latência; modi�car o algo-
ritmo de ordenação no bu�er de reordenação para que seja considerado o roteador fonte
e destino, assim será possível reduzir o número de bu�ers utilizados.
111
REFERÊNCIAS
[1] Charles E. Stroud Laung-Terng Wang and Nur A. Touba. System-on-Chip Test
Architectures. Elsevier, 1 edition, 2008.
[2] David Geer. Chip makers turn to multicore processors. Computer IEEE, 2005.
[3] Davide Bertozzi and Luca Benini. Xpipes: A network-on-chip architecture for gigas-
cale systems-on-chip. IEEE Circuits and Systems Magazine, 2004.
[4] Juha Plosila Masoud Daneshtalab, Masoumeh Ebrahimi and Hannu Tenhunen. Cars:
Congestion-aware request scheduler for network interfaces in noc-based manycore
systems. DATE '13 Proceedings of the Conference on Design, Automation and Test
in Europe, 2013.
[5] Cesar Albenes Zeferino and Altamiro Amadeu Susin. Socin: A parameterizable
and scalable networks-on-chip. 16th Symposium on Integrated Circuits and Systems
Design, 2003.
[6] Poona Bahrebar adn Dirk Stroobandt. The hamiltonian-based odd-even turn mo-
del for maximally adaptative routing in 2d mesh network-on-chip. Computers and
Eletrical Engineering 2015, 2015.
[7] Ge-Ming Chiu. The odd-even turn model for adaptative routing. IEEE TRANSAC-
TIONS ON PARALLEL AND DISTRIBUTED SYSTEMS, 11(7), 2000.
[8] Pasi Liljeberg Juha Plosila Masoumeh Ebrahimi, Masoud Daneshtalab and Hannu
Tenhunen. Catra - congestion aware trapezoid-based routing algorithm for on-
REFERÊNCIAS 112
chip network. Design, Automation and Test in Europe Conference and Exhibition
(DATE), 2012.
[9] Juha Plosila Masoud Daneshtalab, Masoumeh Ebrahimi and Hannu Tenhunen. A
systematic reordering mechanism for on-chip networks using e�ciente congestion-
aware method. Journal of Systems Architecture, 59, 2013.
[10] Frederico G. M. E. Santo Cesar Albenes Zeferino and Altamiro Amadeu Susin. Paris:
A parameterizable interconnect switch for networks-on-chip. SBCCI - Symposium
on Integrated Circuits and Systems Design, pages 204�209.
[11] John L. Hennessy and David A. Patterson. Arquitetura de Computadores: Uma
abordagem quantitativa. Elsevier, 4 edition, 2008.
[12] Tobias Bjerregaard and Shankar Mahadevan. A survey of research and practices of
network-on-chip. ACM Computing Surveys (CSUR), 38(1), 2006.
[13] Max Santana Rolemberg Farias. UMA ABORDAGEM META-HEURÍSTICA PARA
O MAPEAMENTO DE TAREFAS EM UMA PLATAFORMA MPSOC BASEADA
EM NOC. PhD thesis, Universidade Federal de Pernambuco, 2014.
[14] Jaume Joven Eduard Fernandez-Alonso, David Castells-Ru�as and Jordi Carrabina.
Sorvey of noc and programming models proposals for mpsoc. IJCSI International
Journal of Computer Science Issues, 9(3):22�32.
[15] David Patterson and John L. Hennessy. Organizacao e Projeto de Computadores -
A Interface Hardware Software. 3 edition, 2005.
[16] Everton Alceu Carara. Uma exploração arquitetural de redes intra-chip com topo-
logia malha e mode de chaveamento Wormhole. Trabalho de Conclusão de Curso,
2004.
[17] José Carlos Sant'Anna Palma. Reduzindo o Consumo de Potência em Redes Intra-
Chip através de Esquemas de Codi�cação de Dados. PhD thesis, Universidade Federal
do Rio Grande do Sul, 2007.
[18] Marcos Barcellos Hervé. Métodos de teste de redes-em-chip (nocs). Trabalho de
Conclusão de Curso, 2009.
[19] Andre Aziz. Controle de Agressividade de Prefetch em uma Arquitetura Multicore
com Coerencia de Cache Baseada em Diretorio e NoC. PhD thesis, Universidade
Federal de Pernambuco, 2014.
[20] Leonel Pablo Tedesco. Uma proposta para geração de tráfego e avaliação de desem-
penho para nocs. Trabalho de Conclusão de Curso, 2005.
[21] Márcio Eduardo Kreutz Cesar Albenes Zeferino and Altamiro Amadeu Susin. Rasoc:
a router soft-core for networks-on-chip. Design, Automation and Test in Europe
Conference and Exhibition, 2004.
[22] Stephen W. Keckler Vikas Agarwal, M.S. Hrishkesh and Doug Burger. Clock rate
versus ipc: the end of the road for convetional microarchitectures. Proceedings of
the 27th annual international symposium on Computer architecture, 2000.
[23] Wayne Wolf. The future of multiprocessor system-on-chips. Design Automation
Conference, pages 681�685, 2004.
[24] Ahmed Amine Jerraya Wayne Wolf and Grant Martin. Multiprocessor system-on-
chip(mpsoc)technology. IEEE TRANSACTIONS ON COMPUTER-AIDED DE-
SIGN OF INTEGRATED CIRCUITS AND SYSTEMS, 27(10):1701�1713.