universidade federal de pernambuco centro de informática ... · duas questões são críticas em...

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.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.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-


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.


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.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]


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


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]


Figura 2.6 Rede Malha 2D 3

Figura 2.7 Rede Toroide 2D 4

Figura 2.8 Rede Hipercubo 3D 5


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.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]


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]


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.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]


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


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.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


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]


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;


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]


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



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



Figura 2.18 Estrutura Interna do Roteador ParIS 15


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


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


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]


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]


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.


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]


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]


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



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]



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.


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.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




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.


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




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.




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



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,



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.




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



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




de escalonamento.


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




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




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


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.


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]


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]


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


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


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á


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:


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,


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.


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


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.

universidade federal de pernambuco centro de informática ... · duas questões são críticas em...

Documents