NetworkInterface

COMMUNICATION MODELS FOR NETWORK ON CHIP
Aline Vieira de Mello, Luciano Copello Ost, Fernando Gehm Moraes, Ney Calazans
{ alinev, ost, moraes, calazans}@inf.pucrs.br
Pontifícia Universidade Católica do Rio Grande do Sul – PUCRS/FACIN
Av. Ipiranga, 6681 - Prédio 30 / Bloco 4 - Telefone: +55 51 3320-3611 - Fax: +55 51 3320-3621
90619-900 - Porto Alegre - RS - BRASIL
ABSTRACT
1
INTRODUCTION
2
BASIC OCP PROTOCOL
O padrão de comunicação OCP define uma interface
ponto-a-ponto entre dois núcleos. Neste contexto, um
núcleo deve atuar como mestre e o outro como escravo.
Apenas o mestre (iniciador) pode enviar comandos
inicializando as transações. O escravo por sua vez
responde aos comandos informados, tanto recebendo
como passando dados ao mestre. Basicamente, existem
dois tipos de comandos: escrita e leitura de dados
(palavras). A Figura 1 ilustra dois tipos de transações
geradas a partir dos comandos de escrita e leitura.
Extensões para esses comandos são: no caso de
escrita, broadcast, e de leitura, ReadEx. Os comandos
tornam possível a transferência de palavras entre
interfaces OCP. O número máximo de bits (word size)
de uma palavra que pode ser transferida em uma
operação OCP simples limita-se a: 8, 16, 32, 64 e 128
bits. Deve-se ressaltar que OCP baseia-se no conceito
de extensão de zeros (zero-extended), ou seja, utilizamse zeros para preencher uma palavra com largura menor
que as permitidas pelo protocolo.
Mestre
Comando aceito
Mcmd = RD;
Madd
ccept
ScmdA
Sdata
sp
Sre ;
Requisição de leitura
Requisição aceita
Resposta à requisição;
envio de dado(s)
Escravo
Leitura
Comando, endereço
Resposta, dado
Escrita
Comando, endereço
Comando aceito
Mcmd = RD;
Madd; Mdata
ccept
ScmdA
Requisição de escrita
Requisição aceita
Figura 1 - Exemplo de transações de escrita e leitura OCP.
As transações de escrita e leitura de palavras podem
acontecer separadamente, ou seja, respostas para
requisições podem ocorrer em ciclos diferentes. Além
de transações simples (escrita e leitura), OCP possui
suporte para transações em modo rajada (do inglês,
burst). O modo rajada caracteriza-se pela transmissão de
dados em volume, requerendo acréscimo de sinais na
interface OCP. A utilização desse modo pode ser
necessária para núcleos que atuem com alta
transferência de dados, como um núcleo DSP.
Uma interface OCP é composta por um conjunto de
sinais que podem ser utilizados para dar suporte às
particularidades de um núcleo. Ou seja, as
particularidades inerentes ao núcleo indicam quais
sinais devem compor a sua interface e o invólucro OCP
no qual este será inserido. Todos os sinais OCP são
ponto-a-ponto, unidirecionais e são amostrados na borda
de subida do relógio. Estes sinais são classificados em
três grupos: (i) sinais de fluxo de dados, (ii) sinais
opcionais de controle, (iii) e sinais de teste.
Dentre todos os sinais suportados pelo protocolo
destacam-se os sinais básicos (subconjunto dos sinais de
fluxo de dados). Justifica-se essa afirmativa porque
estes sinais devem compor a interface de qualquer
núcleo dotado de interface OCP. Estes sinais são
descritos na Tabela 1.
Tabela 1 - Conjunto de sinais básicos OCP.
Nome
Clk
Largura
1
Parâmetro de
Função do sinal
configuração de Controle
largura
Fixo
Variável Relógio OCP
Mcmd
3
Fixo
Mestre
Endereço de comando
Maddr
1-32
Addr_wdth
Mestre
Endereço de Transferência
Mdata
8/16/32/64/128
Data_wdth
Mestre
Escrita de Dados
1
Fixo
Escravo
Aceitação de transferência
Sdata
8/16/32/64/128
Data_wdth
Escravo
Leitura de Dados
Sresp
2
Fixo
Escravo
Resposta de Transferência
ScmdAccept
Na versão 2.0 deste protocolo, o conjunto de sinais
básicos foi reduzido [OCP03]. Por exemplo, os sinais
Mdata e Sdata não precisam compor a interface de um
núcleo OCP. Maiores informações referentes aos sinais
OCP podem ser obtidas na especificação do protocolo
[OCP02] [OCP02a].
3
EXTERNAL HERMES NOC
INTERFACE
A HERMES é uma infra-estrutura usada para gerar
NoCs para diferentes topologias, tamanhos de flits,
profundidades de buffer e algoritmos de roteamento. A
HERMES implementa três níveis hierárquicos do
modelo de referência OSI: (i) físico – corresponde a
interface de comunicação entre os roteadores, (ii) enlace
- adota o protocolo handshake para o envio e
recebimento de dados de forma confiável e (iii) rede –
no qual é implementado o modo de chaveamento por
pacote wormhole [2][3].
O principal componente desta infra-estrutura é o
roteador HERMES (Figura 2). Este roteador possui uma
lógica de controle centralizada e o limite de cinco portas
bidirecionais: East, West, North, South e Local. Cada
porta possui uma fila de tamanho parametrizável para o
armazenamento temporário de flits. A porta Local
estabelece a comunicação entre o roteador e seu IP. As
demais portas ligam os roteadores a seus roteadores
vizinhos.
porta norte
índice(2)
porta local
índice(4)
porta oeste
índice(0)
lógica de
CHAVE
controle
de
chaveamento
porta leste
índice(1)
W
data_out
tx
ack_tx
S
porta sul
índice(3)
data_in
rx
ack_rx
Figura 2 – Arquitetura do roteador HERMES.
Data_out contém o dado a ser enviado; Tx indica a presença
de um dado válido a ser transmitido; Ack_tx indica que o dado
foi enviado com sucesso; Data_in contém o dado a ser
recebido, com largura configurável; Rx indica a presença de
um dado válido a ser recebido; Ack_rx indica que o dado foi
transmitido com sucesso.
O pacote na infra-estrutura HERMES é formado por
2 flits de controle e 2n - 1 flits de informação útil, onde n
é o tamanho do flit em bits. O primeiro flit contém a
informação do endereço origem e destino do pacote,
usado na definição da rota que o pacote deve seguir na
rede, enquanto que o segundo flit informa o tamanho da
informação útil do pacote. Para um núcleo transmitir
uma mensagem de escrita para a rede este deve
transmitir:
tx
ack_tx
data_out
0111
local address
& target address
4
0002
size
AAAA
address
1234
data
NETWORK INTERFACES
Um aspecto importante na abordagem de redes
intra-chip consiste em como integrar núcleos à rede,
garantindo a comunicação entre estes através do meio
de comunicação. A menos que o núcleo atenda ao
protocolo de comunicação da rede, torna-se necessário
criar um invólucro que permita integrá-lo à mesma. Um
invólucro deve possibilitar a integração física (interface
- largura de sinais, sinais de entrada e saída) e os
serviços de comunicação (segmentação e remontagem
dos pacotes) entre o núcleo e a rede. No contexto de
redes intra-chip denomina-se esse invólucro de interface
de rede (IR).
Segundo Kumar [1], é possível dividir o projeto
interno da IR em duas partes: (i) a parte específica à
rede (independente do núcleo), responsável pela
temporização, bufferização e aspectos de sincronização
durante a transmissão/recepção de dados; (ii) parte
específica
ao
núcleo,
responsável
pela
montagem/desmontagem dos pacotes.
As IR, em geral, fornecem serviços da camada de
transporte do modelo de referência ISO-OSI [22],
porque esta é a primeira camada onde os serviços
oferecidos são independentes da execução da rede. Este
é um ingrediente chave para conseguir a
desacoplamento entre a computação e a comunicação
[16,24], que permite os núcleos IP e a interconexão
possam ser projetados independentemente [Radulescu].
Dentro desse contexto, visando aumentar a
reusabilidade da HERMES em projetos distintos,
padronizaram-se as interfaces de rede com o protocolo
OCP. Denomina-se HERMES-OCP a rede intra-chip
HERMES com interface OCP. Objetiva-se com essa
abordagem simplificar ao máximo as transações
(núcleo-chave), tornando a HERMES o mais
transparente possível para os núcleos que a empregam
como meio de comunicação. A porta Local do roteador
HERMES é a única que segue o padrão OCP.
Dependendo do IP, a porta local pode possuir uma
interface de rede OCP do tipo mestre, escravo ou
mestre-escravo (Figura 3).
Mestre:
Iniciador do Sistema
Mestre/Escravo:
Iniciador/alvo do Sistema
Núcleo
Núcleo
Mestre
Mestre
Escravo:
Alvo do Sistema
Núcleo
Escravo
Solicitação
Escravo
Solicitação
OCP
Resposta
Escravo
Resposta
Escravo
Mestre
Mestre
NoC - Hermes
Figura 3 - Tipos de módulos que podem ser conectados à
rede intra-chip via OCP e funcionamento básico do
intercâmbio de informações.
Deve-se ressaltar que núcleos que desejem
comunicar-se via a HERMES-OCP devem atender ao
protocolo OCP adotado pela rede. Não basta que os
núcleos possuam interfaces OCP compatíveis. Deve-se
definir sobre o protocolo OCP o conjunto de sinais
utilizados, e qual o protocolo de comunicação adotado
pela rede. Em outras palavras, o nível físico da
HERMES adota OCP, o nível de enlace define um
formato de pacote, composto por uma seqüência de
transações OCP e o nível de rede é uma comunicação
ponto-a-ponto, que pode ser diferente para cada par de
núcleos. Neste contexto foram desenvolvidos para a
rede HERMES dois tipos de IRs OCP: (i) IR OCP
NORMA; (ii) IR OCP NUMA.
Um IP mestre pode iniciar 4 tipos de operação
segundo o protocolo OCP-IP. Inicialmente, propõe-se
aqui que apenas duas destas sejam usadas na
comunicação, escrita e leitura, deixando de fora leitura
exclusiva e broadcast.
4.1.
NORMA
No modelo de comunicação do tipo NORMA (NoRemote Memory Access) não há um mapa global de
endereços, sendo a comunicação realizada pela troca de
mensagens entre os núcleos. Em um sistema NORMA
cada núcleo é independente, bastando haver a
informação dos "serviços" que este pode oferecer aos
demais núcleos.
Na presente proposta, foram utilizados os sinais
básicos OCP acrescido do sinal SrespAccept (Tabela 2).
Este sinal garante que a resposta a uma leitura foi
transmitida com sucesso.
Tabela 2 - Sinais OCP NORMA.
Nome
Largura
Função do sinal
Clk
1
Relógio OCP
Mcmd
3
Endereço de comando
Maddr
1
Endereço de Transferência
Mdata
Flit size NoC
ScmdAccept
Escrita de Dados
1
Aceitação de transferência
Sdata
Flit size NoC
Sresp
2
Leitura de Dados
Resposta de Transferência
SrespAccept
1
Aceitação da resposta
Tanto para operação de escrita como para a de
leitura, um conjunto de transações básicas OCP é
transmitido pelo master_ocp. Por exemplo, para o IP
mestre escrever dados em outro IP, as transações
descritas na Tabela 3 devem ser executadas:
Tabela 3 - Protocolo para transmissão de dados (escrita)
no modelo NORMA.
Mcmd
Mdata
WR
WR
WR
WR
WR
WR
Target
Payload
size
d0
d1
...
dn-1
Para o IP mestre ler dados de outro IP, ele deve
gerar as transações descritas na Tabela 4:
Tabela 4 - Protocolo para transmissão de leituras no
modelo NORMA.
Mcmd
Mdata
WR
WR
RD
RD
RD
RD
Target
Payload
size
d0
d1
...
dn-1
Para um núcleo escravo responder às solicitações de
leitura providas por um núcleo mestre, este deve gerar
as transações descritas na Tabela 5.
Tabela 5 - Protocolo para transmissão de respostas de
dados lidos no modelo NORMA.
Sresp
Sdata
realizar os processos de segmentação e remontagem.
Note-se que isto adiciona uma camada ao protocolo de
comunicação da HERMES-OCP, sob responsabilidade
do usuário.
O padrão OCP na versão 1.0 não prevê a
possibilidade de realizar uma leitura em rajada com o
mestre apenas especificando o endereço inicial e uma
certa quantidade de posições a serem lidas. Isto é
possível fazer hoje se mestre e escravo possuírem
interface mestre-escravo, através do uso de split
transactions. Neste caso, o mestre envia um pacote de
controle requisitando a leitura em rajada (interpretado
no nível de rede) e o escravo usa sua interface mestre
para enviar, via escrita na interface escravo do mestre,
os dados solicitados. Na versão 2.0, a funcionalidade
mencionada pode ser obtida a partir de transações de
resposta a pedido de leitura em rajada, tornando a
comunicação mais eficiente. Na versão atual do
protocolo aqui proposto, uma leitura de 10 posições
implica o envio de 10 endereços pelo mestre e a
resposta de 10 valores pelo escravo, onde cada para
endereço/valor constitui uma única transação OCP de
leitura. Contudo, o tráfego de leitura ocupa a rede nos
dois sentidos a cada leitura.
4.2.
NUMA
No modelo de comunicação do tipo NUMA (NonUniform Memory Access) existe um espaço único de
endereçamento, sendo muito similar às estruturas
tradicionais de barramento. Definir o mapa de memória
e evitar conflitos entre os núcleos é papel do projetista.
Neste modelo como no NORMA, foram utilizados
os sinais básicos OCP acrescido do sinal SrespAccept
(Tabela 6).
DVA DVA DVA DVA
d0
d1
...
Tabela 6 - Sinais OCP NUMA.
dn-1
Algumas observações importantes devem ser
colocadas:
Propõe-se não utilizar o sinal Maddr para transmitir
endereços através da HERMES-OCP, pois na rede não
há transmissão separada de dados e endereços. Assim,
endereços devem ser encapsulados da mesma forma que
informação útil (dados). Por este motivo, a largura desse
sinal é reduzida a um bit (largura mínima na interface
OCP da rede HERMES). Utiliza-se esse sinal para
cumprir a especificação mínima de sinais básicos OCP,
conforme descrito em [OCP02]. Isto será mudado
oportunamente para uma interface menos desotimizada,
quando se passar para a versão da NoC compatível com
OCP versão 2.0..
Independente da operação desejada, deve-se enviar,
por comando OCP write, o endereço do núcleo destino e
o número de palavras de N bits que compõe o restante
do payload.
Não é possível misturar comandos de escrita e
leitura em um pacote enviado pela rede HERMES-OCP.
O tamanho máximo do payload é de 2N-1 palavras
de N bits, onde N corresponde ao tamanho do flit em
bits. Caso um determinado núcleo necessite um pacote
maior que este, é responsabilidade da IR do mesmo
Nome
Largura
Clk
Função do sinal
1
Relógio OCP
Mcmd
3
Endereço de comando
Maddr
1-32
Mdata
Flit size NoC
ScmdAccept
Endereço de Transferência
1
Escrita de Dados
Aceitação de transferência
Sdata
Flit size NoC
Sresp
2
Leitura de Dados
Resposta de Transferência
SrespAccept
1
Aceitação da resposta
O modelo NUMA simplifica a comunicação, pois
basta enviar o endereço de destino e o dado, porém não
permite a transferência de dados em rajada. Por
exemplo, para o IP mestre escrever dados em outro IP, a
transação descrita na Tabela 7 deve ser executada:
Tabela 7 - Protocolo para transmissão de dados (escrita)
no modelo NUMA.
Mcmd
WR
Maddr
target + address
Mdata
data
Para o IP mestre ler dados de outro IP, ele deve
gerar a transação descrita na Tabela 8:
Tabela 8 - Protocolo para transmissão de leitura no
modelo NUMA.
Mcmd
RD
Maddr
target + address
Para um núcleo escravo responder à solicitação de
leitura provida por um núcleo mestre, este deve gerar a
transação descrita na Tabela 9.
Tabela 9 - Protocolo para transmissão de resposta de dado
lido no modelo NUMA.
Sresp
DVA
Sdata
data
Cabe ressaltar que no modelo NUMA o sinal
Maddr, como observado na Tabela 7 e Tabela 8, é
utilizado e carrega duas informações: (i) endereço do
núcleo destino e (ii) endereço interno ao núcleo onde se
deseja ler ou escrever.
5
WRAPPER DEVELOPMENT
6
COMPARISON
Gates
NoC 2x2
Master
Slave
MasterSlave
NoC OCP
Serial
Memória
R8
1664
198
171
379
2509
392
106
992
Fenix2x2 1s2m1p para a VIRTEX 2CV1000fg456-4
NORMA
NUMA
LUTs Ocupação Gates ASIC Gates LUTs Ocupação Gates ASIC
de LUTs
0,35 micron
de LUTs 0,35 micron
1016
19,84%
16739 1602
985
19.24%
16629
99
1,93%
1273
143
71
1.39%
870
86
1,68%
1211
181
90
1.76%
938
189
3,69%
2522
342
170
3.32%
1841
1437
28.07%
2267 2405 1384
27.03%
748
195
3,81%
929
83
60
1.17%
256
53
1,04%
4953
30
19
0.37%
4989
485
9,47%
33088
943
471
9.20%
26616
7
CONCLUSION AND FUTURE WORK
8
REFERENCES
[1] Kumar, S. On Packet Switched Network for Chip
Communication. In: Axel Jantsch and Hannu Tenhunen,
editors, Networks on Chip, chapter 5, Kluwer Academic
Publishers, 2003, pp. 85-106.
[2] Hwang, K. Advanced Computer Architecture :
Parallelism, Scalability, Programmability. New York :
McGraw-Hill, 1993, pp.213-256.
[3] Mohapatra, P. Wormhole Routing Techniques for
Directly Connected Multicomputer Systems. ACM
Computing Surveys, Volume: 30(3), Sep. 1998.