Universidade

do Vale do Itaja
CTTMar Engenharia de Computao
Disciplina: Tpicos Especiais em Engenharia de Computao
Professor: Cesar Albenes Zeferino
Atividade: Modelagem e Avaliao de rbitros de NoC

Instrues Gerais

Esta trabalho consiste na modelagem de rbitros de uma NoC em SystemC e na
avaliao do desempenho desse rbitros no simulador RedScarf. Para tal, siga as
instrues abaixo. A especificao da avaliao apresentada ao final deste
documento.

Referencial terico: Arquitetura do rbitro

A NoC modelada no RedScarf a rede SoCIN, a qual utiliza um esquema de
arbitragem distribuda em que cada porta possui um rbitro que escalona o uso
do seu canal de sada pelos canais de entrada das outras portas.

O rbitro implementado na forma de um componente denominado OC (Output
Controller) que recebe requisies dos circuitos de roteamento dos canais de
entrada (componente IC Input Controller) e utiliza um critrio de prioridade
para selecionar uma dessas requisies.

A figura a seguir ilustra um roteador 3x3 (e.g. roteador de um dos cantos da
topologia em malha) em que podem ser observados os blocos IC (lado esquerdo
da figura) e os blocos OC (lado direito da figura).

Figura 1 Digrama de blocos de um roteador 3x3 da NoC SoCIN

Output Controller OC

O OC tem como entrada os sinais de requisio (req request) provenientes dos
blocos IC. Essas entradas so representadas pelas linhas conectadas esquerda
de cada instncia do OC.

J as sadas do bloco OC so seus sinais de concesso (gnt grant) que so
encaminhados aos multiplexadores que conectam o canal de entrada selecionado
ao canal de sada ao qual o bloco OC est associado. Uma sada adicional, no
ilustrada na figura, um sinal chamado Idle que indica aos canais de entrada se o
canal de sada est ocioso (no ocupado). Esse sinal til quando utilizado um
roteamento adaptativo que avalia duas alternativas de sada e, no caso de uma
estiver ocupada, requisita a que estiver disponvel.

As entradas req e as sadas gnt consistem de vetores de pinos, sendo que a
dimenso desses dois vetores depende do nmero N de canais de entrada que
podem ser conectados ao canal de sada escalonado pelo rbitro. Por exemplo, na
figura anterior, um canal de sada pode ser utilizado por dois canais de entrada,
ento N igual a 2 e req e gnt so formados pelos sinais: req0 e req1; e gnt0 e
gnt1, respectivamente.

Alm desses sinais, o bloco OC possui duas entradas de sistema: relgio (clk) e
reestabelecimento (rst). A primeira entrada recebe o sinal que sincroniza a
atualizao de todos os registradores do roteador em um intervalo de tempo
constante (perodo). J a segunda entrada (re)estabelece o estado desses
registradores em valores conhecidos quando for ativado (normalmente, no incio
da operao do sistema).

Os blocos OC do roteador ParIS da rede SoCIN, usada no RedScarf, suportam at
quatro requisies, sendo a quantidade definida pelo parmetro N, j citado.

Dessa forma, a interface e os parmetros deste bloco so definidos como segue:

Quadro 1 Interface do OC
Nome
Largura
Direo
Significado
clk
1 bit
Entrada
Relgio
rst
1 bit
Entrada
Reestabelecimento
req0
1 bit
Entrada
Requisio 0
req1
1 bit
Entrada
Requisio 1
req2
1 bit
Entrada
Requisio 2
req3
1 bit
Entrada
Requisio 3
gnt0
1 bit
Sada
Concesso 0
gnt1
1 bit
Sada
Concesso 1
gnt2
1 bit
Sada
Concesso 2
gnt3
1 bit
Sada
Concesso 3
idle
1 bit
Sada
No ocupado

Quadro 2 Parmetros do OC
Nome
Tipo
Significado
N
Natural
Nmero de requisies

Arbiter

Internamente, o bloco OC constitudo de um componente denominado Arbiter,
que possui interface similar do bloco OC e dentro do qual implementado o
escalonador de requisies. A nica diferena que o Arbiter agrupa os sinais de
requisio (req0, req1, req2 e req3) e de concesso (gnt0, gnt1, gnt2 e gnt3) do
OC em sinais vetoriais de largura N, os quais so denominados R e G,
respectivamente. Isso permite que o Arbiter tenha uma interface escalvel,
enquanto o OC mantem uma interface fixa.

Quadro 3 Interface do Arbiter
Nome
Largura
Direo
Significado
clk
1 bit
Entrada
Relgio
rst
1 bit
Entrada
Reestabelecimento
R
N bits
Entrada
Requisies
G
N bits
Sada
Concesses
idle
1 bit
Sada
No ocupado

Quadro 4 Parmetros do Arbiter
Nome
Tipo
Significado
N
Natural
Nmero de requisies

Internamente o sub-bloco Arbiter composto de um codificador de prioridades
programveis (CPP ou PPE Programmable Priority Encoder) e um gerador de
prioridades (GP ou PG Priority Generator). O codificador de prioridades analisa
as requisies recebidas e seleciona uma delas (ativando o sinal de concesso
correspondente) com base no critrio de prioridades gerado pelo outro bloco. A
Figura 2 apresenta o diagrama de blocos do Arbiter (os nomes dos seus blocos
esto escritos em portugus, mas no decorrer deste texto e no modelo SystemC
so utilizadas as denominaes em ingls).

n

Codificador de
Prioridades
Programvel (CPP)

idle
G

P
n

Gerador de
Prioridades
(GP)

Figura 2 Diagrama de blocos do Arbiter
Fonte: Santo, Zeferino e Susin (2003)

Essa organizao permite a implementao de diferentes esquemas de
arbitragem modificando-se apenas o gerador de prioridades. Por exemplo, para
implementar um rbitro de prioridades fixas, o PG deve gerar uma configurao
constante de prioridades (ex. 0001). J em um esquema de prioridades
variveis, o PG deve gerar uma configurao de prioridades que atualizada
segundo algum critrio (ex. circular, randmico,...). Nenhuma alterao precisa
ser feita no PPE.

Na Figura 2, observa-se que o PPE estende a interface do Arbiter incluindo
entradas de prioridade (P) que so geradas pelo PG. Este, por sua vez, tem como
entrada o valor corrente dos sinais de concesso (G) e pode lev-los em
considerao no momento da atualizao do critrio de prioridade, conforme o

esquema de arbitragem utilizado. Em um rbitro de prioridades fixas, essa

entrada (G) ignorada.

Os quadros a seguir descrevem as interfaces e os parmetros do PPE e do PG.

Quadro 5 Interface do PPE
Nome
Largura
Direo
Significado
clk
1 bit
Entrada
Relgio
rst
1 bit
Entrada
Reestabelecimento
R
N bits
Entrada
Requisies
P
N bits
Entrada
Prioridades
G
N bits
Sada
Concesses
idle
1 bit
Sada
No ocupado

Quadro 6 Parmetros do PPE
Nome
Tipo
Significado
N
Natural
Nmero de requisies

Quadro 7 Interface do PG
Nome
Largura
Direo
Significado
clk
1 bit
Entrada
Relgio
rst
1 bit
Entrada
Reestabelecimento
G
N bits
Entrada
Concesses
P
N bits
Sada
Prioridades

Quadro 8 Parmetros do PG
Nome
Tipo
Significado
N
Natural
Nmero de requisies


Programmable Priority Encoder PPE

O codificador de prioridades programveis baseado em um arranjo de n (do
parmetro N) clulas de arbitragem, onde n o nmero de canais de entrada (ou
sada) no roteador. Como pode ser visto na Figura 3, cada clula i faz a
arbitragem de uma requisio R(i) e gera um sinal de confirmao G(i).

P0

R0
R

Imed
in

R
Imed
out

P1

R1

Imed
in

R
Imed
out

Pn-1

Rn-1

Imed
in

Imed
out
G

clk
idle

G0

G1

Gn-1

Figura 3 Diagrama de blocos do codificador de prioridades programvel

Fonte: Santo, Zeferino e Susin (2003)

A clula de maior prioridade a nica cuja entrada P(j) igual a 1. Para as

demais clulas i (onde i varia de 0 a n-1, sendo i j), P(i) igual a 0. A clula j
inicia a arbitragem e ativa sua sada de confirmao G(j) se sua entrada de
requisio R(j) estiver ativada. Nesse caso, ela informa clula seguinte (j+1 mod
n) que o recurso arbitrado j foi alocado, ativando sua sada Imed_out. Com base
nessa informao, a clula j+1 mod n (e as demais) tomam cincia de que no
podem ativar suas sadas de confirmao, mesmo que todas elas possuam suas
entradas de requisio ativas. Contudo, se a clula de maior prioridade no tiver
uma requisio pendente, ento sua sada Imed_out ser igual a 0 e a clula
seguinte ser a prxima clula a realizar a arbitragem e assim sucessivamente.
Cada clula de arbitragem implementa o circuito lgico indicado na Figura 4.

P

Imed_in

Imed_out

Figura 4 Circuito lgico da clula de arbitragem
Fonte: Santo, Zeferino e Susin (2003)

Uma limitao da arquitetura descrita acima que a atualizao do esquema de
prioridades provoca uma mudana na configurao dos sinais de confirmao.
Para garantir que esses sinais se mantenham estveis enquanto o recurso
alocado utilizado pelo requisitante selecionado, cada par de sinais R(i)-G(i),
onde i varia de 0 a n-1, encaminhado a um autmato de Moore com dois
estados (S0 e S1) implementado por um nico flip-flop e com uma sada
denominada Greg(i), conforme ilustrado na Figura 5. No estado S0, a sada Greg
igual a zero e quando a entrada de confirmao G ativada, o autmato transita
para o estado S1 e a sada Greg passa a ser igual a um. O autmato se mantm
nesse estado at que a requisio R que ocasionou a ativao do sinal de
confirmao G retorne a zero. Isso estabelece um protocolo no qual a requisio
selecionada deve ser mantida ativada para que a confirmao correspondente
tambm o seja, garantindo a alocao do recurso.

G

S0
R=0

G=1
S1

Estado
S0
S1

Greg
0
1

Figura 5 Autmato para registro dos sinais de confirmao
Fonte: Santo, Zeferino e Susin (2003)

O sinal de sada Idle, que indica que o recurso escalonado pelo rbitro est
disponvel, gerado a partir de uma operao lgica NOR aplicada sobre todos os
sinais Greg(i). Quando um desses sinais ativado, a sada Idle desativada.

Priority Generator PG

O gerador de prioridades o bloco que implementa a poltica de escalonamento
utilizada pelo rbitro e oferece a flexibilidade para implementao de diferentes
tipos de rbitro no roteador ParIS, como por exemplo:

rbitro de prioridades fixas (rbitro esttico): Gera uma padro de
prioridades constante (ex.: 0001). a alternativa de implementao
mais simples e de menor custo;

rbitro de prioridades variveis rotativas: Atualiza o padro de
prioridades rotacionando o padro corrente (ex: 0001 => 0010=>
0100=> 1000). A atualizao pode ser feita a cada ciclo de relgio ou
cada ciclo de arbitragem (quando o recurso liberado e novas requisies
deve ser escalonadas);

rbitro de prioridades variveis randmicas: Utiliza algum mecanismo
para gerao de nmero aleatrio e um codificador para gerar o padro
de prioridades (com apenas um bit em 1) a partir desse nmero
randmico. Em implementaes em silcio, utiliza-se um circuito
denominado LFSR (Linear Feedback Shift Register), o qual capaz de
gerar nmeros pseudoaleatrios;

rbitro de prioridades variveis tipo Round-Robin: Atualiza o padro de
prioridades com base na concesso corrente de modo a assegurar que a
ltima requisio atendida tenha a menor prioridade no prximo ciclo de
arbitragem.


PG Round-Robin

A arquitetura de referncia para este trabalho o rbitro Round Robin. O PG
desse rbitro ilustrado na Figura 6. Ele baseado em um registrador paralelo-
paralelo inicializado com apenas o bit 0 em 1. A cada ciclo de arbitragem, o
registrador atualizado pela sada da funo rrd que rotaciona os sinais de
confirmao G em d posies para a esquerda. Essa funo constituda
basicamente por fios e, nesta implementao, d configurado em 1. A aplicao
da funo rrd assegura que a requisio selecionada no ciclo de arbitragem
corrente ter a menor prioridade no ciclo de arbitragem seguinte. A execuo de
um ciclo de arbitragem caracterizada pela ocorrncia de uma transio de 0
para 1 em qualquer um dos n sinais de confirmao em G. O circuito de deteco
de ciclo de arbitragem destacado na regio sombreada na Figura 6. Ele
composto de n flip-flops tipo D, n portas AND de duas entradas e uma porta OR
de n entradas. A sada desse circuito o sinal que habilita a atualizao do
registrador de prioridades, o que s feito quando um ciclo de arbitragem
completado.

rrd

n
n

PRE

ena

ena

CLR

clk

PRE

PRE

ena

CLR

CLR

clk
rst

P0

P1

Pn-1

Figura 6 Circuito lgico do PG Round-Robin

Fonte: Santo, Zeferino e Susin (2003)

(NOTA: A figura contm um erro. As sadas dos flip-flops do circuito de deteco do ciclo de arbitragem
devem ser invertida na entrada da porta AND)

Outros rbitros

O presente trabalho consiste na implementao de modelos SystemC de trs
rbitros, na integrao desses modelos ao RedScarf e na comparao do
desempenho desses rbitros em relao ao Round-Robin.

Os rbitros a serem implementados so:

Prioridade fixas (ST): o PG (pg_st) fornece um valor fixo de prioridades
igual a 0001;

Prioridades rotativas (RT): o PG (pg_rt) fornece um vetor de prioridades
inicial igual a 0001 e rotacional esse vetor a cada ciclo de arbitragem; e

Prioridades randmicas (RD): o PG (pg_rd) gera um nmero aleatrio e, a
partir dos dois bits menos significativos desse nmero gera um dos
seguintes vetores de prioridades: 0001, 0010, 0100 ou 1000.

Os modelos SystemC devem ser escritos a partir do modelo do rbitro Round-
Robin, validados e apenas ento integrados ao RedScarf. Recomenda-se iniciar
pelo rbitro ST (por ser o mais simples), valid-lo e integr-lo ao RedScarf para
compreender o fluxo de desenvolvimento. Aps, deve-se repetir o processo para
os rbitros RT e RD, pela ordem, pois possuem complexidade incremental.

Devem ser utilizados apenas os construtores RTL do SystemC (similares aos de
uma linguagem de descrio de hardware), dado que assume-se que todos os
alunos possuem formao base no projeto de sistemas digitais.

Modelo SystemC de referncia

O componente de referncia deste trabalho o Arbiter com PG Round-Robin. Ele
composto dos seguintes arquivos:

parameters.h: contm definies dos parmetros da rede SoCIN. nele
que est definido o parmetro N e o tipo de rbitro a ser utilizado;

arbiter.h: descreve a estrutura do rbitro, a qual composta de instncias
do PPE e do PG, devidamente conectadas entre si e interface do rbitro;

ppe.h e ppe.cpp: descrevem a interface (.h) e a funcionalidade (.cpp) do
PPE. No arquivo .h, so declarados os sinais de entrada e de sada, os
sinais internos, variveis e mtodos, alm do construtor que registra os
mtodos como processos do simulador, os quais ativados conforme suas
lista de sensibilidade;

pg_rr.h e pg_rr.cpp: de forma similar descrevem a interface (.h) e a
funcionalidade (.cpp) do PG Round-Robin. No caso da implementao de
outros rbitros, devem ser criados novos arquivos a partir desses,
renomeando-os de modo a identificar a arquitetura implementada (st, rt
ou rd).

Para desenvolvimento e validao de um componente, antes da integrao ao
simulador, deve-se utilizar um test bench (em portugus: bancada de teste). O
test bench um modelo SystemC composto dos seguintes arquivos, alm dos
arquivos que compem o rbitro (descritos previamente)

main.cpp: o arquivo de topo que integra todos os componentes do test
bench e a partir do qual o SystemC gera o simulador system.x;

driver.h e driver.cpp: descrevem a interface e a funcionalidade do Driver,
que o componente gerador dos estmulos (vetores de teste) que so
aplicados ao projeto sob verificao (DUV Design Under Verification).
No caso do rbitro, o Driver gera vetores de requisies para que se possa
identificar se o componente apresenta o comportamento esperado;

monitor.h e monitor.cpp: descrevem a interface e a funcionalidade do
Monitor, componente que observa e imprime os sinais de entrada
(estmulo) e de sada (resultado) do DUV em um terminal ou arquivo. No
caso do modelo fornecido, ele apresenta mensagens com os valores
correntes da interface do componente. Em modelos mais sofisticados de
verificao, um monitor pode verificar o resultado produzido pelo DUV e
compar-lo com os valores esperados de modo a sinalizar eventuais
inconsistncias (o que no o caso no presente modelo, o qual exige que
o projetista analise os resultados);

O main.cpp possui comandos que geram um arquivo de sada (waves.vcd) para
visualizao do comportamento dos sinais da interface do rbitro em um
diagrama de formas de onda. Trata-se de uma alternativa a mais para verificar se
o comportamento esperado alcanado, complementando o recurso j
disponibilizado pela mensagens impressas pelo Monitor.


Roteiro inicial para as atividades prticas

Pr-requisitos de software

Os seguintes software e bibliotecas devem estar instalados em seu computador:

Biblioteca SystemC;
Ambiente Qt Creator (ou algum compilador C++);
Visualizador de diagramas de formas de onda (ex. GTKWave, Scansion).


Instalao do template de projeto SystemC no Qt Creator

Para os usurios do Qt Creator, foi criado um template que facilita a configurao
inicial de um projeto SystemC. O template est disponibilizado na pasta desta
atividade. Para utiliz-lo, devem ser seguidos os passos abaixo:

1. Antes de abrir a IDE QtCreator, extraia o template contido no arquivo .zip
(ele inclui um diretrio a ser extrado);

2. Coloque o diretrio extrado (systemcproject) no local abaixo (ou
equivalente, conforme o sistema operacional do seu computador):

<QT_CREATOR_DIR>/share/qtcreator/templates/wizards/

Exemplos:
Windows:
C:\Qt\Qt5.4.1\Tools\QtCreator\share\qtcreator\templates\wizards

Linux:
/home/<user>/Qt5.4.1/Tools/QtCreator/share/qtcreator/templates/wizards
ou
/usr/share/qtcreator/templates/wizards

OS X:

/Applications/Qt Creator.app/Contents/Resources/templates/wizards/

ou

/Users/<user>/Qt/Qt Creator.app/Contents/Resources/templates/wizards

3. Abra o Qt Creator e crie um novo projeto;

4. Haver a opo SystemC Project na categoria Non-Qt Project. Selecione-a e
siga as etapas seguintes como requisitado pela ferramenta.

Estes procedimentos foram testados em ambientes Windows, Linux e OSX 10.8
com SystemC 2.3 e IDE Qt Creator a partir da Verso 3.2.0. Para verses
anteriores da IDE, o template outro!

IMPORTANTE: Deve-se selecionar corretamente o diretrio SystemC e no usar
espaos nos nomes do diretrio de projeto e do diretrio SystemC

Carregando o projeto do Arbiter

O componente de referncia deste trabalho o Arbiter com PG Round-Robin.
Esse modelo disponibilizado com os componentes do test bench utilizado para
sua verificao, incluindo os seguintes arquivos:

Arquivo de projeto Qt
o arbiter.pro

Cabealhos (.h)
o arbiter.h
o driver.h
o monitor.h
o parameters.h
o pg_rr.h
o ppe.h

Fontes (.cpp)
o driver.cpp
o main.cpp
o monitor.cpp
o pg_rr.cpp
o ppe.cpp


Para carregar e executar o projeto, siga os passos abaixo:

1. Crie um diretrio com o nome arbiter em algum caminho que no
contenha
espaos
ou
caracteres
especiais
(ex.
C:\systemc_work\arbiter);

2. No gerenciador de arquivos ou Qt Creator, carregue o arquivo arbiter.pro
ou crie um projeto novo com base no template SystemC. Aparece uma
caixa de dilogo intitulada Configure Project. Nela, clique sobre o cone
Details do kit de compilao (identificado pelo nome Desktop Qt...), Nos
dois campos de formulrio, edite o contedo para remover o prefixo
build- e o sufixo do kit de compilao, mantendo apenas o caminho de
diretrio e o nome do projeto, como neste exemplo:

c:\systemc_work\build-arbiter-Desktop_Qt_5_4_1_MinGW_32bit-Debug
c:\systemc_work\arbiter

Aps, clique em Configure e aguarde. O projeto ser devidamente
carregado;
3. No navegador do projeto, faa um duplo clique sobre o arquivo arbiter.pro
para abri-lo. Aps, atualize o caminho do diretrio no qual o SystemC est
instalado (varivel SYSTEMC_PATH). Se necessrio, corrija o caminho.
Salve o arquivo e ento e feche-o;
4. Compile o projeto (Menu: Build > Run). Aps compilado, o simulador ser
executado e um terminal ser apresentado com as mensagens geradas
pelo componente Monitor do test bench, como ilustrado na figura a seguir

Figura 7 Mensagens impressas no terminal pelo Monitor

5. Caso tenha um visualizador de formas de onda instalado, visualize o
arquivo gerado pelo simulador (waves.vcd). Por exemplo, no Mac OS X,
use o Scansion, invocando-o da seguinte forma pelo terminal do sistema:
$ /Applications/Scansion waves.vcd

No Scansion e em outras ferramentas, deve-se utilizar os procedimentos
especficos para visualizar os sinais da simulao. A figura a seguir mostra
o diagrama de formas de ondas exibido pelo Scansion. Como pode ser
observado, a cada quatro de relgio, as quatro requisies R[3:0] so
ativadas simultaneamente. O rbitro Round-Robin ento seleciona uma
das requisies e ativa a sada G correspondente. A cada ciclo de
arbitragem, uma requisio diferente selecionada, conforme esperado
de um rbitro Round-Robin. Depois de quatro ciclos de arbitragem, as
requisies so ativadas simultaneamente e mantidas at serem
atendidas. Cada requisio atendida mantida em nvel alto por quatro
ciclos de relgio. Da mesma forma, o rbitro promove uma alocao
equilibrada.

Figura 8 Digrama de formas de ondas da simulao do rbitro Round-Robin

Criando um novo rbitro no projeto

Abaixo, so apresentados os procedimentos para criar um novo modelo de
rbitro a partir do modelo j existente. Siga os passos abaixo para criar o rbitro
de prioridades fixas (ST de static):

1. Abra o arquivo arbiter.h e remova o comentrio da linha 26 (comando:

//#include "pg_st.h") e os comentrios das linhas 78 a 86 (as
quais instanciam o modelo do gerador de prioridades fixas). Com isso,
voc habilitar a compilao e a instanciao do componente pg_st. Aps,
salve e feche o arquivo;

2. Abra o arquivo parameters.h e defina o parmetro ARBITER_TYPE com
o valor 1 para selecionar o rbitro de prioridades fixas. Aps, salve e feche
o arquivo;
3. Duplique os arquivos pg_rr.h e pg_rr.cpp e renomeie suas cpias com os
nomes pg_st.h e pg_st.cpp, respectivamente. Com isso, voc ir criar os
arquivos sobre os quais voc ir modelar o rbitro de prioridades fixas;

4. Adicione os arquivos criados ao projeto. Para isso, clique com o boto

direito sobre o nome do projeto no navegador e, no menu pop up exibido,
selecione a opo Add Existing Files...
5. Abra o arquivo pg_st.h e substitua as trs ocorrncias da expresso pg_rr
pela expresso pg_st (no use o recurso de refatorao, pois ele ir
realizar essas trocas no arquivo pg_rr.h). Faa o mesmo para a expresso
PG_RR, substituindo-a pela expresso PG_ST. Aps, salve e feche o arquivo;
6. Abra o arquivo pg_st.cpp e substitua as sete ocorrncias da expresso
pg_rr pela expresso pg_st (nas definies dos mtodos). Aps, salve e
feche o arquivo;

7. Uma vez que todos arquivos tenham sido editados, rode o compilador. A
simulao deve gerar as mesmas mensagens produzidas pelo rbitro
Round-Robin, dado que nenhuma modificao foi feita no comportamento
do modelo editado.

Pronto!!!!! Voc agora est apto para editar os arquivos do componente pg_st
para criar o rbitro de prioridades fixas. Os mesmos procedimentos desta seo
devem ser aplicados quando for criar os PGs dos rbitros de prioridades
rotativas (pg_rt) e randmicas (pg_rd).


Incluindo um novo rbitro no RedScarf

Para incluir um novo rbitro no simulador RedScarf, devem ser seguidos os
procedimentos abaixo (caso a sua verso disponibilize esse recurso):

1. No Windows e no Linux, copie os arquivos .h e .cpp do componente
desenvolvido (ex. pg_st.h e pg_st.cpp) e o arquivo modificado do rbitro
(arbiter.h) para o diretrio RedScarf/system.

Obs: No OS X, o diretrio system fica localizado dentro do bundle do RedScarf.
Para acess-lo, clique com o boto direito do mouse sobre cone do app e
selecione a opo Mostrar contedo do pacote no menu pop up exibido. O
diretrio estar no caminho RedScarf.app/Contents/MacOS/system

2. No Windows e no Linux, abra o arquivo system.ini localizado no diretrio

RedScarf/etc. No OS X, este diretrio fica localizado dentro do bundle
do RedScarf, no caminho RedScarf.app/Contents/MacOS/etc

3. Na seo System_Sources do arquivo system.ini aberto, acrescente as
seguintes definies no final da lista de definies de arquivos fonte do
simulador. O parmetro CppFile aponta para o arquivo .cpp do modelo e
s definido se ele possuir um fonte.

31\CppFile=pg_st
31\CacheOptions=noCache
size=31

Note o prefixo numrico nas duas primeiras linhas e o valor do parmetro
size. A cada novo componente, esse nmero deve ser incrementado. Por
exemplo, ao acrescentar um novo componente, size ser igual a 32.

O parmetro CacheOptions define a opo de salvamento e recuperao
de objetos da cache do RedScarf, a qual usada para acelerar a
compilao do simulador. O valor noCache evita o uso da cache e
adotado nos modelos em desenvolvimento e teste para garantir que o seu
fonte seja sempre compilado. Nos outros valores, o arquivo fonte no
mais compilado e o RedScarf copia a ltima verso do arquivo objeto
salvo na cache. O valor noOptions no acrescenta sufixos ao nome do
objeto. Outros valores (listados no cabealho do arquivo system.ini)
definem os parmetros da NoC dos quais o componente depende e so
utilizados para construir o nome do objeto a ser salvo na cache.
4. Na seo Arbiter_Types, acrescente as definies abaixo:

2\Type=ST
size=2
Isso necessrio para que o novo modelo de rbitro esteja disponvel
para escolha no painel de configurao dos experimentos.

Pronto!!!! Agora a ferramenta ir compilar e linkar o componente novo no
simulador, bem como oferecer a alternativa de escolha desse modelo na aba
System Simulation.

Instrues para a atividade da avaliao

Implemente os seguintes modelos de rbitro (definidos previamente) e
verifique-os por simulao:

rbitro de prioridades fixas (rbitro esttico)
rbitro de prioridades variveis rotativas
rbitro de prioridades variveis randmicas

Aps a verificao, acrescente cada rbitro ao RedScarf, certificando-se que esto
corretamente integrados. Para isso, preciso confirmar que o modelo est
disponvel para escolha no painel de configurao e que o RedScarf consegue
compilar e simular uma rede utilizando o modelo.

Aps a integrao dos trs modelos ao RedScarf, realize experimentos de
avaliao de desempenho para comparar esses modelos de rbitro entre si e com
o modelo j disponibilizado (Round-Robin). Utilize o seguinte cenrio:



Configurao do sistema
Xsize
Ysize
Channel Width

4
4
32 bits

Padro de trfego
Destination node(s)
Traffic class
Type of injection
Switching technique
Number of packets per flow
Deadline (ns)
Required bandwidth (Mbps)
Message size (bits)

Uniform
RT0
Constant
Wormhole
50
0
320
256

Configurao do experimento
Router architecture
Routing algorithm
Flow control (switching)
Arbiter type
Input buffers (flits)
Output buffers (flits)
Channel Fclk range

ParIS
XY
CB-(WH)
RR, ST, RT e RD
4
0
10-100 (inc +10)

Aps a simulao, analise os resultados e procure identificar as diferenas entre
os desempenhos dos modelos de rbitro, incluindo ponto de saturao, trfego
aceito mximo, latncia mdia e disperso (jitter) abaixo da saturao, entre
outras. Utilize os grficos e as tabelas disponibilizadas para identificar as
mtricas. Na sua anlise, com base na teoria estudada, procure justificar o
porque dos valores obtidos.

Entregue relatrio impresso contendo:

1. Cdigo fonte: Inclua apenas os trechos de cdigo fonte que expressem as
caractersticas especficas de cada rbitro. Ou seja, para cada rbitro,
inclua os segmentos de cdigos que descrevem a poltica de prioridades
do rbitro;
2. Descrio do cenrio dos experimentos: inclua a descrio do cenrio
especificada anteriormente;
3. Resultados: grficos e tabelas obtidos na simulao;
4. Anlise: discusso dos resultados obtidos com base na teoria estudada e
disponibilizada na literatura.

Informaes adicionais:
Este trabalho individual. Embora todos os alunos devam chegar aos
mesmos resultados experimentais na suas simulaes, os relatrios e,
principalmente, a anlise dos resultados so especficos de cada aluno. Se
for identificada similaridade em dois ou mais relatrios, a nota do
relatrio ser dividida entre eles.

Critrios de avaliao:
o Organizao do relatrio e aderncia s normas de metodologia
(20%)
o Qualidade da apresentao dos resultados cdigo, grficos e
tabelas (20%)
o Qualidade do texto escrito (20%)
o Qualidade da anlise crtica dos resultados (40%)

Prazo para entrega: 23/05/2016 (ser descontado 0,5 por dia de
atraso)

Bibliografia

DALLY, William James; TOWLES, Brian. Principles and practices of
interconnection networks. New York: Morgan Kaufmann, 2004. (Captulo 18)

SANTO, Frederico Guilherme Mariani do Espirito; ZEFERINO, Cesar Albenes;
SUSIN, A. A. Modelos Parametrizveis de rbitros Distribudos para a sntese de
roteadores de Redes-em-Chip . In: CONGRESSO BRASILEIRO DE COMPUTAO,
3., 2003, Itaja. Anais... Itaja: UNIVALI-CTTMar, 2003. p. 717-728.

SILVA, Eduardo Alves da. RedScarf: ambiente para avaliao de desempenho de
Redes-em-Chip. 2014. Trabalho de Concluso de Curso. (Graduao em Cincia
da Computao) Universidade do Vale do Itaja, Itaja, 2014.

SYNOPSYS. Describing synthesizable RTL in SystemC. Synopsys, 2002.

WIKIPEDIA. Linear feedback shift register. 2015. Disponvel em:
<http://en.wikipedia.org/wiki/Linear_feedback_shift_register>. Acesso em: 25
maio 2015.

ZEFERINO, Cesar Albenes. Redes-em-Chip: arquiteturas e modelos para
avaliao de rea e desempenho. 2003. Tese (Doutorado em Computao)
Programa de Ps-Graduao em Computao, Universidade Federal do Rio
Grande do Sul, Porto Alegre, 2003.

ZEFERINO, Cesar Albenes; SANTO, F. G. M. E.; SUSIN, A. A. ParIS: A
Parameterizable Interconnect Switch for Networks-on-Chip. In: 17th (INT.)
SYMPOSIUM ON INTEGRATED CIRCUITS AND SYSTEMS DESIGN (SBCCI), 2004,
Porto de Galinhas. Proceedings... New York: ACM Press, 2004. p. 204-209.