BLESS

A arquitetura BLESS (MOSCIBRODA; MUTLU, 2009) parte da abordagem da eliminação dos buffers da arquitetura de rede tradicional. Dessa forma, não há buffers de entrada e consequentemente não há como utilizar canais virtu- ais (seção 2.6). Os próprios canais físicos atuam como buffers para a NoC e, para que a abordagem sem buffers seja viável, é necessário que o número de canais de saída seja maior ou igual ao número de canais de entrada. Dife- rentemente da abordagem clássica na qual os pacotes ou flits que disputam um mesmo canal de saída são armazenados em buffers, a arquitetura BLESS admite um sistema de prioridades no uso dos canais. O pacote mais prioritário utiliza o canal enquanto os outros são redirecionados aos canais restantes de acordo com um mecanismo de prioridades. O critério de prioridade mais efe- tivo é o oldest-first no qual os pacotes ou flits são dotados de um mecanismo de tempo de vida baseado no timestamp de seus respectivos momentos de criação (MOSCIBRODA; MUTLU, 2009).

Há dois tipos de abordagens BLESS: a baseada em flits denominada de FLIT-BLESS e a baseada em pacotes, a qual utiliza a técnica de roteamento em wormhole (seção 2.6), denominada de WORM-BLESS.

Na abordagem FLIT-BLESS cada flit é roteado de maneira individual, o que facilita os mecanismos de controle dos switches. Por outro lado, a existên- cia de vários flits têm impacto no tempo de transmissão, afetando a latência da NoC (seção 2.4). Além disso, cada flit necessita de um cabeçalho o que tam- bém afeta negativamente a latência e o consumo energético da rede. Final- mente maiores latências implicam em maiores requisitos de buffers de saída para a montagem dos pacotes a partir de seus respectivos flits. As regras de

priorização de portas para a abordagem FLIT-BLESS são especificadas na Tabela 2. Resumidamente, dado um conjunto de flits que chegam ao switch, os flits que possuem mais tempo imersos na rede serão alocados às portas desejadas (que permitem chegar de maneira eficiente ao destino - regra 1) ao passo que os flits mais novos serão defletidos (regra 2).

A abordagem WORM-BLESS foi concebida como a evolução da aborda- gem FLIT-BLESS a fim de transpor os desafios da abordagem FLIT-BLESS supracitados. Na WORM-BLESS, a princípio, somente o primeiro flit do pa- cote necessita de cabeçalho. Os outros flits seguirão o mesmo caminho do primeiro não se espalhando pela rede.

Os mecanismos de injeção de pacotes e de arbitragem na NoC devem ser levemente modificados para que se evitem que determinados fluxos de tráfego monopolizem os canais. Na abordagem WORM-BLESS é utilizado o mecanismo de truncagem de pacotes que pode ser explicado por meio do corte de um pacote em grupos menores. Para seu correto funcionamento é necessário agregar um mecanismo de alocação de portas de saída para cada pacote composto por uma pequena tabela no switch. Em cada divisão de pa- cotes é necessário agregar um cabeçalho para a segunda parte resultante da divisão.

A combinação do algoritmo de truncagem de pacotes com a priorização de portas a partir do timestamp é importante pois assegura que os flits mais ve- lhos são sempre roteados para a porta desejada. Assim os flits mais antigos tornam-se prioritários e sempre estarão seguindo um caminho que se apro- xima do caminho ótimo para chegar ao seu destino. Na Tabela 2, há as regras de priorização de portas para a abordagem WORM-BLESS. Nota-se que tais regras distinguem flits de cabeçalho de flits de dados. Para um determinado flit de cabeçalho, uma nova porta necessita ser alocada. A porta desejada e não alocada para nenhum outro grupo de flits é a mais prioritária (regra 1). No caso deste tipo de porta de saída não estar disponível, a próxima prioridade são as portas desejadas e que estão atualmente alocadas para um determi- nado grupo de pacotes (regra 2). Neste caso, a porta é realocada para o novo grupo de flits, sendo que o grupo para o qual a porta estava alocada será trun- cado. Assim um grupo de flits mais prioritário é capaz de truncar um grupo de pacotes já alocado. O primeiro flit do grupo de pacotes truncados torna-se um

novo flit de cabeçalho e será realocado para outra porta. Assim haverão dois grupos de flits os quais serão roteados de maneira independente ao destino. No caso de todas as portas já estarem ocupadas por flits de prioridades maio- res, o flit de cabeçalho é alocado para uma porta de saída não desejada (ele é defletido - regras 3 e 4). Finalmente se o flit não é de cabeçalho, por definição sua porta de saída já está definida e alocada (regra 5).

Tabela 2: BLESS: políticas de priorização de pacotes

flit BLESS worm BLESS

1 - atribuir flit para porta dese- jada

2 - atribuir flit para porta não de- sejada

⊂ pacote a transmitir é defle-

tido

if flit contém cabeçalho then

1 - atribuir flit para porta não alocada desejada

2 - atribuir flit para porta alocada de- sejada

⊂ pacote em transmissão é trun-

cado

3 - atribuir flit para porta não alocada e não desejada

⊂ pacote a transmitir é defletido 4 - atribuir flit para porta alocada não desejada

⊂ pacote em transmissão é trun-

cado

⊂ pacote a transmitir é defletido

else

5 - atribuir o flit para a porta que está alocada ao seu respectivo pacote

end if

Nota: O switch arbitra suas portas conforme a ordem de prioridades desta Tabela. Somente portas livres são consideradas, ou seja, portas que não foram assinaladas a flits de maior prioridade (maior tempo na rede) em um

mesmo ciclo.

É importante ressaltar que o mecanismo de truncagem ocorre somente para pacotes com níveis de prioridade inferior a do pacote a ser injetado ou retransmitido. No caso de haver mais de uma porta disponível, os algoritmos priorizam a porta que está na mesma direção pela qual o flit adentrou no switch.