1Abstract— Strategies to parallelize applications is one way to
increase performance in computer architectures. In addition to the hardware organization, some techniques are adopted, maintaining its architecture or instruction set, in order to increase the flow of processing instructions, such as pipeline and software pipelining. This paper presents a version of the software pipelining technique in IPNoSys, an unconventional architecture, for improved performance in the execution of applications containing loops. The new version was compared with an already implemented version of the software pipelining technique to IPNoSys and was two times more efficient than the old version.
Keywords— IPNoSys, Software Pipelining, Paralelismo em Nível de Instrução, Loop.
I. INTRODUÇÃO
M arquiteturas convencionais, as instruções de um programa são executadas de forma sequencial. Em [1], foi introduzida uma técnica capaz de acelerar a execução de algoritmos sequenciais dividindo as instruções em estágios de tamanhos iguais. Cada estágio poderia ser executado em uma unidade independente. Desse modo, em um mesmo momento, seria possível ter mais de uma instrução sendo executada no processador, cada uma em um estágio diferente. A esta técnica foi dada o nome de pipeline.
A técnica de pipeline não afeta o tempo de execução individual das instruções, mas melhora a vazão delas em um programa. O pipeline gerou algumas outras técnicas baseadas na concepção de dividir tarefas entre elementos para melhorar o desempenho de arquiteturas. Uma delas foi o software pipelining.
Outras formas de exploração de paralelismo são utilizar redundância de componentes como nos computadores superescalares, execução de várias instruções simultaneamente como nos VLIW (Very Long Instruction Word), ou desenvolvimento de arquiteturas não-convencionais, entre outras.
Uma arquitetura não-convencional, IPNoSys (Integrated Processing NoC System), trouxe um novo componente que uniu processadores e roteadores em um único elemento chamado de RPU (Unidade de processamento e Roteamento). Essa arquitetura une várias RPUs em uma malha e fornece um excelente ambiente para a execução de aplicações paralelas. No entanto, permanece ainda pouco explorada em certos aspectos, como no paralelismo em nível de instrução.
Este trabalho consiste na implementação de uma técnica de 1 D. F. L. Nunes, Universidade Federal Rural do Semi-Árido, Mossoró, RN, Brasil, denis.freire@ufersa.edu.br
S. R. Fernandes, Departamento de Ciências Exatas e Naturais, Universidade Federal Rural do Semi-Árido, Mossoró, RN, Brasil, silvio@ufersa.edu.br
paralelismo em nível de instrução que visa melhorar o desempenho de aplicações na arquitetura IPNoSys. Para isso, será explorada a técnica do software pipelining, a qual cria uma aceleração na execução de laços de repetição. Além disso, este trabalho irá comparar a implementação com a proposta usando software pipelining.
Através do mecanismo software pipelining, as instruções dentro do laço de repetição são divididas entre os elementos processantes da IPNoSys. A intenção é a diminuição do tempo de ociosidade dos núcleos e, consequentemente, a redução do tempo de execução de aplicações.
Na próxima seção, será apresentada uma breve revisão sobre software pipelining. Em seguida, será mostrada a arquitetura IPNoSys original, seguida por técnicas de software pipelining implementadas para esta arquitetura, dentre elas, a técnica proposta por esse artigo. Por fim, os resultados de simulação e avaliação da arquitetura proposta.
II. SOFTWARE PIPELINING
A técnica de software pipelining, descrita por [2], afirma que computadores com arquiteturas do tipo VLIW possuem componentes funcionais que possibilitam a execução simultânea de instruções dentro de um laço de repetição, similar ao pipeline dos computadores convencionais.
A ideia do software pipelining é iniciar a próxima iteração do loop antes do término da primeira. Dessa forma, várias iterações do laço estariam executando de forma concorrente, fazendo o tempo total da execução do laço ser menor.
Apesar da noção do software pipelining ser bem definida, várias implementações podem ser encontradas, dependendo do tipo da arquitetura que implementou a técnica. Os trabalhos de [4], [5] e [6] mostram implementações diferentes para obter o mesmo resultado.
III. IPNOSYS A. Visão Geral
A IPNoSys (Integrated Processing NoC System) é uma arquitetura de processamento paralelo descrita por [7] e teve seu conceito baseado em NoC. A principal distinção entre a IPNoSys e outras redes em chip é a alteração dos roteadores com a inserção de uma Unidade Lógica e Aritmética (ULA), a fim de prover, além da transmissão de pacotes, o processamento de instruções. Essa estrutura modificada foi descrita em [8] e chamada de Unidade de Processamento e Roteamento ou RPU (Routing and Processing Unit). Além da ULA, cada RPU possui uma Unidade de Sincronismo (SU – Synchronization Unit), buffers, crossbar e árbitros.
A IPNoSys é uma rede de RPUs com topologia grelha-2D, D. F. L. Nunes and S. R. Fernandes
Software Pipelining in a Non-Conventional
Architecture to Improve Performance
como mostra a Figura 1. Nos quatro cantos da rede, existe, ligada a cada RPU adjacente, uma estrutura chamada Unidade de Acesso à Memória – MAU (Memory Access Unit). A MAU é responsável pela execução de instruções de acesso a memória e sincronização. As aplicações são descritas através de uma linguagem própria, em forma de pacotes que trafegam pela rede. Os demais tipos de operações são executados pelas RPUs da rede enquanto são roteados.
Figura 1. Arquitetura IPNoSys.
O processamento na IPNoSys se dá quando as MAUs injetam pacotes na rede. A cada RPU pela qual o pacote passa, ao menos uma instrução é retirada e executada. Se houver algum resultado, é inserido no pacote. Depois de executar uma instrução, a RPU em questão roteia o pacote para a próxima RPU e aguarda a chegada de um novo pacote, se houver. A cada ciclo, o pacote diminui progressivamente, até ser consumido por completo. É possível ter até 4 pacotes (vindos um de cada MAU), trafegando entre as RPUs, o que representa um paralelismo em nível de thread. Os pacotes na IPNoSys utilizam o modelo backpacker [9], em que os dados estão sempre presentes junto com as instruções. Com isso, é possível reduzir a quantidade de acessos à memória.
Como pode ser visto na Figura 1, uma das MAUs é diferenciada para realizar entrada e saída de dados (IOMAU). O tamanho da rede pode variar em tempo de projeto, mas o algoritmo de roteamento e o formato dos pacotes se mantém.
A arquitetura foi descrita utilizando a linguagem SystemC [10], com precisão de ciclo. A IPNoSys também apresenta uma linguagem assembly chamada de PDL – Package Descrition Language) e um montador.
B. Formato do Pacote
O pacote na IPNoSys é formado por palavras de 32 (trinta e dois) bits, e em cada palavra são usados 4 bits extras para indicar o tipo (Figura 2). As três primeiras palavras de um pacote são o seu cabeçalho. As palavras seguintes são as instruções e operandos da aplicação. A quantidade de palavras de instrução depende da aplicação e a quantidade de operandos está relacionada ao tipo de instrução. Por fim, a última palavra do pacote contém a identificação de fim do pacote.
Nas três palavras de cabeçalho, são encontrados campos relativos à origem e ao destino do pacote, quantidade de
instruções e outros detalhes do programa. Nas palavras de instrução, além do código da operação e quantidade de operandos necessários (NO), há dois campos, chamados de Resultado_1 e Resultado_2, usados normalmente para indicar posições no próprio pacote em que os resultados das operações devem ser inseridos. Em instruções de sincronização e acesso à memória, um dos campos possui o endereço da MAU que a executará. Nas palavras de operandos, os 32 (trinta e dois) bits são utilizados como operandos da instrução.
Figura 2. Formato do Pacote IPNoSys. C. Programabilidade
Para se executar aplicações na IPNoSys, é necessário descrever o programa através da PDL. Sua ISA original (Instruction Set Architecture ou conjunto de instruções) define 32 (trinta e duas) instruções. Utilizando este conjunto de instruções, é possível desenvolver aplicações que podem estar dispostas em um ou mais pacotes.
Demais características da IPNoSys, como o funcionamento da MAU, IOMAU, IONode etc, foram suprimidas por questões de espaço. Mais detalhes podem ser encontrados em [7], [8] e [11].
IV. SOFTWARE PIPELINE EM IPNOSYS
No modelo original da IPNoSys, apenas uma RPU executa uma instrução do pacote por vez. Podendo-se ter, no máximo, 4 RPUs executando uma instrução, cada uma de um pacote diferente. No restante do tempo as RPUs passam apenas a transmitir os pacotes. Devido a isso, a execução de laços de repetição acontece injetando o mesmo pacote na rede repetidamente. Após a execução sequencial de todas as instruções do pacote, a última RPU do caminho envia uma mensagem para a MAU de origem do pacote, para inseri-lo novamente na rede. Esse procedimento se repete conforme a quantidade de vezes definida pelo laço de repetição.
É importante ressaltar que o laço deveria ser composto por três pacotes. O primeiro inicializa os valores das memórias e chama o segundo pacote através da instrução de controle que deve ser enviada até a MAU. O segundo pacote corresponde
ao corpo do laço e, ao final deste, ocorre uma tomada de decisão para determinar se o laço chegou ao fim ou se deve ser repetido. Se houver uma nova iteração, o valor da variável de controle é incrementado e o pacote é novamente injetado na rede. Caso o laço tenha esteja concluído, é chamado o pacote com o código após o laço. Na Figura 3 é mostrado esse procedimento. As instruções EXEC e SEND na Figura 3 representam pacotes de controle que são enviados das RPUs que as decodificaram até a MAU que a executará tantas vezes quanto for a lógica do laço de repetição.
Figura 3. Laço de Repetição Tradicional no IPNoSys.
Tal operação, apesar de funcional, tem o desempenho prejudicado pela quantidade de mensagens trocadas entre as RPUs e a MAU, para leitura e gravação de valores na memória e requisições para reinjetar o pacote. Motivado por isso e sabendo da subutilização da rede de ULAs nas RPUs, surgiram duas ideias de implementação de software pipelining em IPNoSys. A primeira, proposta por [12] e a segunda, por este artigo. Tais propostas serão abordadas nas próximas seções.
A. IPNoSys com Software Pipelining I
No trabalho proposto por [12], foi apresentada uma técnica de software pipelining para IPNoSys. O método utilizado insere uma palavra adicional após cada palavra de instrução. Essa nova palavra contém dois campos que definem a quantidade de iterações e um contador. Além disso o campo Apontador, do cabeçalho, e a palavra de fim de pacote do pacote, foram modificados para conter também o valor da quantidade de iterações.
O modelo de execução proposto funciona da seguinte forma: a RPU, no caminho do pacote, retira uma instrução e verifica a próxima palavra. Se for um operando, a instrução é executada normalmente. Contudo, se for uma palavra com as instruções de laço, a RPU executa a operação e envia a instrução e seus operandos para a próxima RPU, a fim de que se proceda nova execução. Na Figura 4 pode ser visto a estrutura das palavras de instrução na IPNoSys com software pipelining I.
Figura 4. Palavras de instrução da IPNoSys com Software Pipelining I. Com isso, uma instrução que esteja no pacote é executada a cada RPU que passa. De modo que cada RPU do caminho do pacote equivale executa todas as instruções de uma iteração do laço. A Figura 5 mostra esse efeito.
Iterações do Laço
1 2 3
Ciclos
RPU X RPU Y RPU Z 1 op1=i
2 op2=op1+1 op1=i
3 op3=op2+5 op2=op1+1 op1=i
4 op3=op2+5 op2=op1+1
5 op3=op2+5
Figura 5. Modelo de Programação do Software Pipelining Tipo I.
O tratamento de dependência de dados é feito utilizando-se do próprio modelo de execução da IPNoSys. Se o resultado de uma operação deverá ser usado pela próxima instrução, a RPU salva esse resultado em um de seus buffers e aguarda a próxima instrução chegar até ela, momento em que finalmente utilizará o resultado salvo. Nesse modelo, todas as RPUs no caminho do pacote executarão todas as instruções de laço de repetição de modo que a quantidade de repetições do laço fica restrita à quantidade de RPUs no caminho do pacote.
B. IPNoSys com Software Pipelining II
Como forma de implementar uma técnica de pipeline com total compatibilidade com a arquitetura original, sejam em modelo de programação, computação na RPUs e formato do pacote, foi desenvolvida uma nova técnica de software pipelining para IPNoSys utilizando um método diferente, a qual é proposta neste artigo.
A nova técnica propõe que cada RPU retire uma instrução do pacote e a execute na quantidade de vezes definida pelo laço. Para a implementação deste processo, foram criadas duas novas instruções para a ISA da IPNoSys, chamadas de LOOP e RT. A nova instrução LOOP (Fig. 6) serve para configurar as RPUs, para que a próxima instrução seja executada repetidamente. Nesse ínterim, a instrução RT encarrega-se de resolver os problemas de dependências de dados.
1 LOOP r1; // Qtd. de instruções dentro do laço 2 op; // Qtd. de repetições
Figura 6. Palavras da Instrução LOOP.
A instrução LOOP utiliza dois parâmetros para configurar as RPUs. No espaço destinado ao Resultado_1, deve ser informada quantas das próximas instruções fazem parte do laço de repetição. Já no espaço dedicado ao operando, é indicada a quantidade de repetições que o laço deve executar. A Fig. 6 contém e visão do programador e o formato da palavra da instrução LOOP.
Essa estratégia de informar a quantidade de instruções que fazem parte do laço serve para delimitar quantas das próximas instruções serão executadas em loop.
Quando decodificam uma instrução LOOP as RPUs são configuradas para retirarem uma instrução que faz parte do laço e enviar o restante do pacote para próxima RPU. Após retirar uma instrução, a RPU inicia o processo de executar a instrução conforme a quantidade de vezes definida no laço. Enquanto executa, também transmite o resto do pacote para a próxima RPU. Para a configuração das RPUs, a instrução LOOP é propagada junto com o restante do pacote. Assim, cada RPU do caminho: retira a instrução LOOP e seu operando; decrementa o valor de r1; retira a próxima instrução, que será a instrução a ser executada por ela repetidamente; insere a instrução LOOP no pacote novamente (com o r1 decrementado); envia o pacote para a próxima RPU. A Figura 7 mostra o modelo de programação desta arquitetura.
Processador
RPU X RPU Y RPU Z
Ciclos
1 op1=i
2 op1=i op2=op1+1
3 op1=i op2=op1+1 op3=op2+5
4 op2=op1+1 op3=op2+5
5 op3=op2+5
Figura 7. Modelo de Programação do Software Pipelining Tipo II.
É importante notar que, com o novo modelo, após a RPU ser configurada pela instrução LOOP e executar a primeira iteração da sua instrução no laço, já efetuará a transmissão da instrução seguinte para a próxima RPU. Desse modo, cada RPU com instruções do laço executa e transmite simultaneamente. Além disso, à medida que as RPUs são configuradas, várias delas executam simultaneamente, sempre em uma iteração anterior relacionada à próxima RPU.
Os programas executados por esta arquitetura podem apresentar três tipos de dependências de dados. O primeiro tipo diz respeito a um resultado de uma operação ser utilizado pela própria instrução, como na operação 2 1 1. O
segundo tipo é o cenário em que o resultado gerado por uma RPU X, que está dentro do laço, deve ser enviado para uma RPU Y que também está dentro do laço. E, por último, quando uma RPU X, dentro do laço, precisa enviar o resultado de sua operação para uma RPU Y que está fora do laço. Os três tipos de dependências podem ser vistos na Figura 8, que mostra um trecho do código de um algoritmo para cálculo de um fatorial em linguagem PDL.
Como forma de tratar as dependências de dados, foi criado dentro de cada RPU um mecanismo de predição. Esse mecanismo consegue prever qual das RPUs utilizará o resultado gerado pela RPU atual. O sistema foi feito levando em consideração que cada palavra do pacote IPNoSys tem um endereço. Conhecendo-se o endereço da palavra atual e o endereço da palavra do resultado gerado, é possível prever qual instrução empregará esse resultado e, consequentemente, para qual RPU ele deverá ser enviado.
Figura 8. Dependências de dados na IPNoSys com Software Pipeline Tipo II. Dependência dentro da instrução (verde); dependência entre instruções dentro do laço (azul); dependência de dados entre instruções dentro e fora do laço (vermelho).
Quando a RPU identifica que o resultado será utilizado pela instrução que ela mesma está executando (em verde na Figura 8), o dado é gravado no seu próprio buffer e retirado durante a próxima execução. Nesse caso, há necessidade do programador inicializar o operando explicitamente com um valor default (como em 5 e 1 na Figura 8). Com isso, a arquitetura utiliza o valor default como operando na execução da instrução na primeira iteração, em seguida armazena o resultado para ser usado como operando na iteração seguinte do laço e assim por diante.
Quando a dependência de dados é entre uma instrução que está dentro do laço e outra que está fora (em vermelho na Figura 8), a RPU ignora a existência desse dado até a última execução do laço. Isso acontece porque a instrução que está dentro do laço irá executar repetidas vezes, mas a instrução que está fora só irá executar uma. Com isso, apenas na última execução é que se torna necessário o dado salvo no buffer da RPU. Ao fim do laço de repetição, o resto do pacote caminha normalmente e o resultado é propagado até a RPU de destino.
Para o último caso (em azul na Figura 8), em que a dependência de dados acontece entre RPUs que estão dentro do laço, uma instrução auxiliar, chamada RT (retransmitir) foi criada. Quando uma RPU identifica que o resultado da operação que está executando deverá ser usado por outra RPU,
ela encapsula esse resultado em um pacote de controle contendo a instrução RT endereçada à RPU destino. Esse pacote trafega na rede através do canal virtual dedicado aos pacotes de controle até chegar na RPU que usará o operando. Ao chegar no destino, a RPU identifica que a instrução RT é endereçada a ela, retira o operando e descarta o resto do pacote de controle. A Figura 9 contém as palavras da instrução RT.
Figura 9. Palavras da Instrução RT.
Sendo assim, uma RPU que recebeu uma instrução a qual depende do resultado de uma instrução anterior irá sempre aguardar a chegada desse resultado (através do RT) para que proceda a execução. Nos testes efetuados, em quase todos os casos a instrução RT chegou na RPU destino antes do momento em que o dado seria utilizado. Dessa forma, as RPUs que necessitam de um dado raramente ficam aguardando esse dado chegar.
V. RESULTADOS
Primeiramente, para averiguar a eficiência da IPNoSys com software pipelining proposta neste artigo, foram feitos testes comparando apenas com a IPNoSys original. O programa utilizado foi o de calcular o fatorial de um número de forma iterativa, como o mostrado na Figura 10, cujo código equivalente em PDL encontra-se na Figura 8.
1 loop = fat;
2 a = 1;
3 for(int i = 1 ; i <= loop ; i++){
4 | a = a * i;
5 }
Figura 10. Algoritmo de fatorial.
O programa foi executado nas duas arquiteturas para se calcular os fatoriais dos números de 4 a 15. De acordo com o algoritmo, o número de repetições executadas é definido pelo número de entrada menos 1. Ou seja, calcular o fatorial de 4 requer 3 repetições. Já o fatorial de 5 requer 4 iterações e assim sucessivamente. A Figura 11 mostra a quantidade de ciclos de clock necessários para execução de cada instância do programa nas duas arquiteturas.
Figura 11. Comparação de desempenho na execução de um fatorial entre a IPNoSys original (azul) e a IPNoSys com Software Pipelining do Tipo II (vermelho).
A IPNoSys com software pipelining do tipo II (arquitetura proposta) tem um desempenho significativamente melhor do que a IPNoSys original, já que foi significativamente menor a quantidade de transmissão de pacotes dentro da rede. Devido a utilização de paralelismo, o aumento do número do fatorial a ser calculado gera um aumento sutil na quantidade de ciclos necessária para a execução. Na IPNoSys original, aumentar em um o valor para se calcular o fatorial significa a injeção de um novo pacote na rede. No cálculo do fatorial do número 15, a quantidade de ciclos necessários para execução na arquitetura original chega a ser superior a 11 vezes a quantidade de ciclos da versão com software pipelining tipo II. As duas técnicas de software pipelining em IPNoSys discutidas neste artigo tem características e limitações diferentes. Para efeito de comparação a aplicação apresentada em [12] foi reproduzida e executada na proposta apresentada por este trabalho e o resultado comparado ao de [12]. A escolha desse algoritmo se deu pelo fato de ser o único exemplo mostrado com os resultados pelo autor de [12].
1 for(int i = 1 ; i <= MAX ; i++){
2 | op1 = 1 + 1;
3 | op2 = op1 + 2;
4 | op3 = op2 + 3;
5 | op4 = op3 + 4;
6 }
Figura 12. Algoritmo do Exemplo da Aplicação.
Em cada execução, a quantidade iterações do laço foi sendo aumentada. Os valores das iterações foram 10, 50, 100, 200, 300, 500, 700 e mil iterações. Os resultados das três arquiteturas foram organizados no gráfico da Figura 13. A métrica observada foi a quantidade de ciclos de clock.
0 0,5 1 1,5 2 2,5 3 3,5 4 4,5 4 5 6 7 8 9 10 11 12 13 14 15 Ciclos de Clock (milhares) Fatorial
Figura 13. Comparação de desempenho em laço de repetição entre a IPNoSys Original (azul), IPNoSys com Software Pipelining Tipo I (roxo) e IPNoSys com Software Pipelining Tipo II (vermelho).
Foi possível notar que, mesmo nos testes com poucas iterações, as versões que implementam software pipelining levam uma grande vantagem em relação à versão original. Isso se deve à redução da quantidade de palavras trafegando na rede, isto é, as RPUs passam mais tempo processando as instruções do que transmitindo as palavras.
Quando se aumenta ainda mais o número de iterações, a quantidade de ciclos de clock da IPNoSys original aumenta consideravelmente. De acordo com os testes, para mil repetições, a IPNoSys original precisa de cerca de 80 (oitenta) mil ciclos de clock. Já as versões com software pipelining se mostraram significativamente melhores, com execuções em média cinco vezes mais rápidas para cada mil iterações.
Comparando apenas as versões com software pipelining, a versão proposta neste artigo (tipo II) completou a execução de mil iterações em 8.102 ciclos de clock. De acordo com gráfico também é possível notar que com mil iterações a quantidade de ciclos no tipo I é quase o dobro do obtido pelo tipo II. Esses resultados afirmam que, para melhorar o desempenho, a IPNoSys deve diminuir ao máximo a quantidade de comunicações entre as RPUs.
VI. CONCLUSÃO
Este trabalho apresentou uma implementação alternativa de paralelismo em nível de instrução para a arquitetura não convencional IPNoSys. O modelo proposto é baseado na técnica de software pipelining, a qual busca acelerar a execução de laços de repetição.
Foi observado que já existia uma versão da IPNoSys com software pipelining, o qual, entretanto, apresentava algumas
fragilidades que poderiam ser eliminadas. O novo modelo de software pipelining para IPNoSys se mostrou mais eficiente no tocante à velocidade de processamento, chegando a superar em mais de dez vezes a rapidez da IPNoSys original e em duas vezes a da primeira versão da IPNoSys com software pipelining apresentada por [12].
Apesar dos bons resultados obtidos, o novo modelo de software pipelining limita a quantidade de instruções dentro do laço de repetição de acordo com o número de RPUs disponíveis na rede. Como cada instrução dentro do laço é entregue para uma RPU, se um programa tiver mais instruções que RPUs a IPNoSys entra num estado de “execução localizada”, em que a última RPU do caminho executa as demais instruções do pacote. Esse cenário é prejudicial ao software pipelining, pois acaba com o paralelismo e prejudica o desempenho.
Como trabalhos futuros, serão implementados tratamentos para esse cenário como a divisão do laço de repetição entre as outras MAUs da IPNoSys, de modo a obter paralelismo em nível de instrução e de thread ao mesmo tempo. Outra solução, que poderá ser implementada e avaliada, é dividir a quantidade de instruções do pacote pela quantidade de RPUs disponíveis de modo que cada RPU possa retirar mais de uma instrução (utilizando o campo IPR já presente no cabeçalho).
REFERÊNCIAS
[1] D. A. Patterson and J. L. Hennessy, Organização e Projeto de
Computadores: A Interface Hardware/Software, 4th ed. São
Paulo/SP: Elservier, 2014.
[2] M. Lam, “Software pipelining: an effective scheduling technique for VLIW machines,” ACM SIGPLAN Not., vol. 23, no. 7, pp. 318–328, 1988.
[3] R. B. Jones and V. H. Allan, “Software pipelining: a comparison and improvement,” in 23rd Annual Workshop and Symposium of
Microprogramming and Microarchitecture, 1990, pp. 46–56.
[4] B. R. Rau, “Iterative Module Scheduling: An Algorithm for Software Pipelining Loops,” in MICRO-27, 1994, pp. 63–74. [5] M. Kandemir and I. Kolcu, “Exploiting Software Pipelining for
Network-on-Chip architectures,” in IEEE Computer Society Annual
Symposium on Emerging VLSI Technologies and Architectures (ISVLSI’06), 2006, vol. 00, pp. 295–302.
[6] H. Wei, J. Yu, H. Yu, M. Qin, and G. R. Gao, “Software Pipelining for Stream Programs on Resource Constrained Multicore Architectures,” IEEE Trans. Parallel Distrib. Syst., vol. 23, no. 12, pp. 2338–2350, Dec. 2012.
[7] S. R. F. de Araújo, “Projeto de Sistemas Integrados de Propósito Geral Baseados em Redes em Chip – Expandindo as
Funcionalidades dos Roteadores para Execução de Operações: A plataforma IPNoSys,” Tese de Doutorado, Universidade Federal do Rio Grande do Norte, 2012.
[8] S. R. Fernandes, B. C. Oliveira, M. Costa, and I. S. Silva, “Processing while routing: a network-on-chip-based parallel system,” IET Comput. Digit. Tech., vol. 3, no. 5, pp. 525 – 538, 2009.
[9] S. Tieg, “A new computing paradigm for the 21st century,”
EETimes VIrtual Conference: System-on-Chip 2.0. 2010.
[10] “SystemC,” 2015. [Online]. Available: http://accellera.org/. [Accessed: 20-Oct-2015].
[11] S. R. Fernandes, B. C. Oliveira, and I. S. Silva, “Using NoC routers as processing elements,” in Proceedings of the 22nd Annual
Symposium on Integrated Circuits and System Design Chip on the Dunes - SBCCI ’09, 2009, vol. 24.
[12] A. L. de Medeiros, “Implementação da técnica de Software Pipeline na Rede em Chip IPNoSys,” Dissertação de Mestrado, Universidade Federal do Rio Grande do norte, 2014.
0 10 20 30 40 50 60 70 80 10 50 100 200 300 500 700 1000 Ciclos de Clock (milhares) Quantidade de Iterações
Dênis F. L. Nunes graduou-se em 2012 em Ciências da
Computação pela Universidade Federal Rural do Semi-Árido (UFERSA). Atualmente é mestrando em Ciências da Computação pelo Programa de Pós-Graduação em Ciências da Computação em parceria ampla pela Universidade Federal Rural do Semi-Árido e Universidade do Estado do Rio Grande do Norte (PPgCC – UERN/UFERSA). E funcionário da Diretoria de Ensino a Distância da UERN. Tem experiência nas áreas de Arquitetura de Computadores, Sistemas Embarcados, Processadores Reconfiguráveis, VHDL.
Silvio R. Fernandes possui graduação em Ciências da
Computação pela Universidade Federal do Rio Grande do Norte (2005), mestrado (2008) e doutorado (2012) em Sistemas e Computação pela Universidade Federal do Rio Grande do Norte. Tem experiência na área de Ciência da Computação, com ênfase em Arquitetura de Sistemas de Computação, atuando principalmente nos seguintes temas: arquiteturas não-convencionais, MPSoCs, redes em chip e sistemas embarcados. Atualmente é professor da Universidade Federal Rural do Semi-Árido (UFERSA) no curso de Ciências da Computação.
