Utilização do Barramento CoreConnect para
Implementação de CMP com Processadores Java
Rodrigo Bittencourt Motta
Universidade Federal do Rio Grande do SulInstituto de Informática - Av. Bento Gonçalves, 9500 Campus do Vale - Porto Alegre, Brasil
rbmotta@inf.ufrgs.br
RESUMO
Em um momento em que é cada vez mais complicado explorar o ILP (Instruction Level Parallelism) e aumentar a frequência de clock, a indústria tem optado por integrar mútiplos processadores em um único chip. Em sistemas embarcados, que tem restrições de área, potência e
time-to-market, a troca de processadores com designs
complexos pela utilização de vários processadores design simples, permite acelerar o tempo de projeto e proporcionar alta escalabilidade. O objetivo desse trabalho é aplicar a abordagem CMP utilizando processadores Java integrados com uma memória de dados compartilhada através da interface CoreConnect da IBM.
Categorias e Identificação do Assunto
C.1.3 [Arquiteturas de Processadores]: Outros Estilos de Arquiteturas – Arquiteturas Adaptáveis
Termos Gerais
Paralelismo, DesempenhoPalavras-Chave
Chip Multiprocessing, Paralelismo em Nível de Thread, Processador Java
1. INTRODUÇÃO
A proliferação de sistemas computacionais cada vez mais inteligentes e integrados ao nosso cotidiano é um fenômeno evidente. Apenas para exemplificar alguns destes aparelhos, podem-se citar: impressoras, telefones celulares, câmeras fotográficas e filmadoras digitais, videogames, tocadores de mp3 e tocadores de mídia portáteis. Estes dispositivos são denominados sistemas computacionais embarcados. O que caracteriza este tipo de sistema é não só a sua qualidade normalmente portátil como em uma filmadora digital ou embutida como em um freio ABS, como também o seu paradigma diferenciado e mais restritivo do que os sistemas computacionais tradicionais, já que sistemas embarcados em geral executam poucas e definidas funções [3].
O que se vê em sistemas computacionais tradicionais, como em computadores pessoais de propósitos gerais, é a
tecnologia sendo usada em função de um aumento de performance, sendo o tempo de computação a principal métrica. Entretanto, quando no desenvolvimento de sistemas computacionais embarcados, o projetista vê-se diante de outros desafios, tais como as questões de portabilidade, o limite de consumo de energia sem grandes perdas de desempenho, a possibilidade de funcionamento em uma rede maior, e o curto tempo de projeto [1]. Todas estas questões devem ser balanceadas de acordo com aplicações alvo normalmente bem determinadas, especificação esta que também é característica de sistemas embarcados.
A metodologia tradicionalmente utilizada pela maioria dos processadores para aprimorar o desempenho é a utilização de mecanismos cada vez mais complexos para aumentar o ILP (Instruction Level Parallelism). No entanto, como mostrado em [2], por exemplo, mecanismos de exploração agressiva do ILP podem consumir mais de 55% do total de dissipação de potência de um processador, o que não é permitido em sistemas embarcados. Além disso, a exploração do ILP, que tem se mantido nas últimas décadas, está alcançando o seu limite. Por outro lado, a tecnologia de fabricação dos circuitos integrados tem avançado constantemente e permitido que seja possível colocar um número cada vez maior de transistores em uma mesma área de silício. Uma das abordagens que pode se beneficiar dessa tendência é a utilização de múltiplos cores de processadores em um único chip ou CMP (Chip Multiprocessing). Em sistemas embarcados, a utilização de CMP permite maior escalabilidade e balanceamento de carga como a arquitetura Piranha [4].
O presente trabalho propõe a implementação de uma abordagem CMP visando sistemas embarcados utilizando a interface CoreConnect da IBM como barramento de comunicação entre processadores Java e uma memória de dados compartilhada.
Este artigo está organizado como segue: a Seção 2 apresenta algumas arquiteturas comumente utilizadas em abordagens CMP. A Seção 3 aborda o Processador Java utilizado para o desenvolvimento da aplicação proposta. A Seção 4 mostra o funcionamento do barramento
CoreConnect da IBM. A Seção 5 apresenta a aplicação desenvolvida juntamente com alguns resultados. Finalmente, a última Seção apresenta as conclusões e aponta os trabalhos futuros.
2. CMP (CHIP MULTIPROCESSING)
Na abordagem CMP o chip é composto por dois ou mais processadores, chamados cores, que executam concorrentemente em diferentes regiões do código. Normalmente são utilizados cores simples de processadores homogêneos, mas também pode-se utilizar cores heterogêneos e com diferentes graus de complexidade. A principal vantagem da abordagem CMP é possibilitar a grande utilização do TLP (Thread Level Parallelism) das aplicações atingindo um alto troughput.Normalmente, a abordagem CMP usa cores simples de processadores, capazes de executar uma única thread, para explorar somente moderadas quantidades de paralelismo dentro de uma thread, enquanto executa múltiplas threads em paralelo em múltiplos cores [5]. No entando, se uma aplicação não puder ser decomposta em threads, os cores serão subutilizados.
Apesar do design de qualquer chip CMP ser bastante particular, um chip típico provavelmente deve conter algumas ou a maioria das seguintes características: os cores têm suas próprias memórias cache com uma cache de nível secundário compartilhada, os controladores de memória devem ser separados em módulos, deve haver um mecanismo de roteamento de rede, um mecanismo de coerência e um mecanismo de integração e comunicação intra-chip.
A seguir serão discutidas algumas abordagens para implementação de CMP.
2.1 CMP COM CACHE
COMPARTILHADA
A Figura 1 ilustra uma arquitura de CMP com cache compartilhada. A seta em vermelho indica o caminho para a comunicação entre os cores.
Figura 1 – Arquitetura de CMP com cache compartilhada.
A abordagem com cache compartilhada oferece a menor latência de comunicação entre os cores. Tão logo a CPU 1 escreve uma linha da cache a CPU 2 tem acesso sem ter que fazer uma busca em um bloco remoto. Isso mantém o trafêgo entre os cores longe do mecanismo de E/S, maximizanndo a banda de comunicação os periféricos. Uma outra vantagem dessa abordagem é a possibilidade de alocação dinâmica de memória cache entre os cores. Supondo-se que a CPU 1 está utilizando toda a sua cache alocada mas a CPU 2 está utilizando apenas uma fração da cache que lhe foi alocada, o controlador da cache pode, dinamicamente, atribuir para a CPU 1 um pouco da área da cache que a CPU 2 não está utilizando.
No entanto, enquando as vantagens dessa abordagem vem em forma de desempenho, as desvantagens vem em forma da complexidade do controlador da cache. Isso acontece porque é necessário implementar uma política de compartilhamento da cache para possibilitar alocação dinâmica entre os cores. Outra desvantagem é que a banda da cache cresce conforme o número de cores que são colocados no chip.
2.2 CMP COM E/S COMPARTILHADA
A Figura 2 ilustra uma arquitura de CMP com cache compartilhada. A seta em vermelho indica o caminho para a comunicação entre os cores.
Figura 2 – Arquitetura de CMP com E/S compartilhada.
A abordagem de CMP com E/S compartilhada tem a vantagem da simplicidade em relação à abordagem de CMP com cache compartilhada, mas essa vantagem é paga com um menor desempenho e flexibilidade. A comunicação entre os cores é realizada sem a necessidade de sair do chip e é gerenciada pela lógica que manipula a comunicação a troca de informação com o exterior do chip. Como as memória caches são separadas, não são necessárias alterações na controladora da cache para implementar a comunicação entre os cores. Isso significa que são necessárias poucas modificações em um processador para a implementação dessa abordagem.
A principal desvantagem dessa abordagem é que o mecanismo de E/S deve ser robusto o suficiente para implementar a comunicação intra-chip e off-chip ao mesmo tempo. Outra desvantagem é não é que as memórias caches dos cores podem ser subutilizadas, já que não é possível fazer alocação dinâmica de memória cache.
2.3 CMP COM ENCAPSULAMENTO
COMPARTILHADO
A Figura 3 ilustra uma arquitura de CMP com encapsulamento compartilhado. A seta em vermelho indica o caminho para a comunicação entre os cores. Essa abordagem as vezes é chamada de DCM (Dual Chip Module) ou MCM (Multichip Module, para mais de 2 chips). A rede de conexão utilizada para a comunicação entre os módulos não é mostrada, mas pode ser desde uma rede completamente roteada até um simples barramento utilizando um chipset externo para comunicação.
Figura 3 – Arquitetura de CMP com encapsulamento compartilhado.
Das abordagens apresentadas, a arquitetura com encapsulamento compartilhado é o mais simples e mais rápido de ser implementado, visto que não são necessárias modificações na lógica dos processadores.
A principal desvantagem dessa arquitetura é a latência de comunicação entre os cores já que para a troca de informações é necessário utilizar a rede de interconexão da mesma maneira que uma abordagem SMP (Symmetric Multiprocessor). Outra desvantagem é que a frequência da rede de interconexão tende a ficar mais limitada a cada novo core adicionado ao modelo.
3. PROCESSADOR JAVA
O processador Femtojava [6] foi criado com restrições de área e potência visando especificamente sistemas embarcados. Na realidade, o processador Femtojava é o resultado de uma metodologia adotada para a geração semi-automática de um sistema embarcado a partir de uma descrição Java. O Femtojava implementa um subconjunto de instruções Java: são apenas 68 no total. Neste subconjunto encontram-se instruções necessárias para
operações básicas de pilha, manipulação de vetores, desvios condicionais e incondicionais, execução de métodos estáticos e acesso a campos de classes.
Outras características do Femtojava são: o conjunto reduzido de instruções, arquitetura Harvard, pequeno tamanho e facilidade de inserção e remoção de instruções. Sua microarquitetura pode ser observada na Figura 4. Somando-se a isso, possui algumas características interessantes, como o tamanho da máquina de controle ser diretamente proporcional ao número de instruções utilizadas. Isto só é possível porque o Femtojava é gerado a partir de um ambiente de CAD (Computer Aided Design), chamado Sashimi [6].
Figura 4 – Microarquitetura do Processador FemtoJava [7].
4. IBM CORECONNECT
A interface CoreConnect [8] consiste de uma estrutura de interconexão reutilizável organizada em uma hierarquia de barramentos e integra a biblioteca de núcleos denominada Blue Logic. Os núcleos dessa biblioteca são pré-projetados e pré-verificados para trabalharem com os protocolos da arquitetura CoreConnect, possibilitando o reuso de chip para chip. A Figura 5 mostra a interface CoreConnect.
Figura 5 – Interface CoreConnect [7].
A arquitetura CoreConnect provê três barramentos para a interconexão de núcleos:
PLB (Processor Local Bus): o barremento PLB é endereçado para alta performance, baixa latência e flexibilidade de design.
OPB (On-chip Peripheral Bus): é um barramento secundário criado para aliviar os gargalos na performance do sistema através da carga capacitiva no barramento PLB.
DCR (Device Control Register bus): é um barramento utilizado para a leitura e escrita de registradores de status e configuração de baixa performance.
5. APLICAÇÃO
Essa seção visa apresentar a arquitetura projetada, os experimentos realizados bem como os resultados obtidos.
5.1 ARQUITETURA INICIALMENTE
PREVISTA
A arquitetura prevista inicialmente é mostrada na Figura 6.
Figura 6 – Arquitetura inicialmente prevista.
A arquitetura é composta por dois processadores FemtoJava Multicíclo cada um com sua memória de instruções (ROM) e uma memória de dados (RAM) compartilhada. Os processadores não acessam diretamente a memória compartilhada, mas o barramento PLB da
interface CoreConnect que é responsável por determinar o fluxo da comunicação.
A interface CoreConnect é um bloco IP (Intelectual
Property) descrito em VHDL que pode ser instanciado em
plataformas configuráveis através do software EDK (Embbeded Development Kit) da empresa Xilinx. Os blocos VHDL do processador FemtoJava são gerados a partir do ambiente Sashimi juntamente com os arquivos de memória em formato coe. O formato coe é o utilizado pelo Core do software ISE da Xilinx para as memórias internas de dispositivos configuráveis. No entando, para implementação dessa arquitura, foi encontrado um problema na inserção dos arquivos de memória em formato coe utilizando o software EDK. Devido a este problema e ao prazo para implementação da proposta, a arquitetura foi modificada, conforme será descrito na próxima seção.
5.2 ARQUITETURA PROJETADA
A arquitetura da aplicação desenvolvida é mostrada na Figura 7.
Figura 7 – Arquitetura da aplicação.
Em contraste com a arquitetura da Figura 6, a arquitetura da Figura 7 substitui a interface CoreConnect por um outro bloco VHDL que é responsável pela arbitragem do fluxo de dados entre os processadores e a memória RAM. Na Figura 7 esse fluxo está representado pela seta vermelha.
A interface de arbitragem, ao contrário da interface CoreConnect, não é genérica e foi desenvolvida exclusivamente para controlar o fluxo de dados entre processadores FemtoJava e uma memória de dados compartilhada.
5.3 EXPERIMENTO
Para validar a arquitetura desenvolvida e extrair dados de latência da comunicação, foi utilizado o algoritmo de ordenação BubleSort onde a idéia é que cada iteração seja executada por um processador FemtoJava. A Figura 8 mostra o diagrama do experimento realizado.
Figura 8 – Experimento realizado.
As memórias de dados dos dois processadores FemtoJava possuem uma cópia do mesmo programa, que consiste em executar uma iteração do algoritmo BubleSort em um vetor de dados qualquer que está armazenado na memória de dados compartilhada.
O chaveamento entre os processadores para acessar o vetor na memória de dados é realizado pelo mecanismo de arbitragem através da instrução FemtoJavaIO.write que é disparada quando o processador termina a execução do fluxo de instruções presente em sua memória de instruções. Quando isso acontece, o processador que terminou a execução é resetado e o caminho para o acesso à memória de dados é liberado para o outro processador e assim sucessivamente.
O processo termina quando o vetor de dados está ordenado. A percepção desse evento ocorre porque ao término de cada iteração do algoritmo de ordenação é relizada uma comparação entre o vetor de dados que está sendo ordenado e um vetor de dados idêntico, mas já ordenado.
O experimento foi realizado através de teste em hadware. Os blocos VHDL dos processadores e do mecanismo de arbitragem, juntamente com os arquivos coe das memórias de instruções e da memória de dados foram sintetizados no FPGA Virtex II-Pro da Xilinx utilizando a ferramenta de desenvolvimento ISE, também da Xilinx.
5.4 RESULTADOS
Esta seção tem o objetivo de apresentar resultados de área da arquitetura projetada em relação ao processador FemtoJava tradicional e de latência do mecanismo de arbitragem.
A Figura 9 mostra os dados de ocupação do FPGA Spartan-3 X3S200 da XIlinx (em tabelas-verdade de 4 entradas). 2148 3304 41 0 500 1000 1500 2000 2500 3000 3500
FemtoJava FemtoJava CMP Mecanismo de Arbitragem
Figura 9 – Dados de ocupação do FPGA.
Pode-se observar que a arquitetura desenvolvida possui cerca de 35% a mais de área que a arquitetura FemtoJava tradicional (deve-se observar que estão inclusos nesses resultados a área das memórias de dados e de instruções). Já o mecanismo de arbitragem ocupa cerca de 1,2% da área total na arquitetura desenvolvida.
A Figura 10 mostra o número de ciclos de execução para o algoritmo BubleSort para um vetor de dez posições na plataforma FemtoJava e na arquitetura desenvolvida. O experimento foi realizado com uma freqüência de 5MHz.
77379 77984 0 10000 20000 30000 40000 50000 60000 70000 80000 90000 FemtoJava FemtoJava CMP
Figura 10 – Número de ciclos de execução.
É importante destacar que o fato de o número de ciclos ser maior na aplicação projetada deve-se ao fato de um dos processadores ficar ocioso enquanto o outro está executando. A diferença de 0,8% a mais no número de ciclos da arquitetura projetada se deve principalmente ao mecanismo que realiza a abritragem para o acesso a memória de dados compartilhada.
6. CONCLUSÕES E TRABALHOS
FUTUROS
Este artigo mostrou o desenvolvimento de uma aplicação utilizando a abordagem CMP com processadores Java com memória de dados compartilhada.
Pode-se concluir que, para os experimentos realizados, a área e latência do mecanismo de acesso à memória compartilhada não tiveram influência
significativa na performance geral da execução da aplicação.
Uma possibilidade de trabalho futuro é implementação de um mecanismo para permitir que o chaveamento para seleção do processador que vai acessar a memória de dados compartilhada seja realizado antes que a execução do programa da memória de instruções tenha terminado. Para isso, entretanto, seria necessário implementar uma instrução de Sleep e outra de Wake-up no processador FemtoJava, para congelar a execução e reiniciar a ponto parado respectivamente.
Uma outro trabalho possível seria a implementação de uma nova arquitetura para o processador FemtoJava com múltiplos cores. Isso permitiria também o desenvolvimento de um mecanismo para dar suporte a migração de tarefas entre os cores. Seria possível também a aplicação de técnicas para realizar o desligamento dos cores ociosos para estimar os ganhos de potência estática.
O desenvolvimento de uma arquitetura com cores heterogêneos seria um outro trabalho interessante, que permitiria realizar o escalonamento das tarefas para serem executadas nos cores que melhor se encaixassem nas suas restrições (energia, potência e deadline). Essa solução seria bastante conveniente para sistemas embarcados e possibilitaria a realização de comparações entre a execução das tarefas em processadores com único core ou processadores com múltiplos cores homogêneos.
Por fim, a abordagem CMP tem se mostrado bastante atraente para as novas aplicações onde um alto troughtput é essencial e demostrado que o a troca de complexidade por escalabilidade pode ser extremamente atraente para uma vasta gama de aplicações.
7.
REFERÊNCIAS BILIOGRAFICAS
[1] Wolf, W. H., “Computer as components: principles of
embedded computing system design”, Morgan Kaufmann
Publishers, 2001.
[2] T. Austin, D. Blaauw , S.Mahlk e, T.Mudge, C.Chakrabarti, and W.W olf, Mobile Supercomputers. Computer (2004), Vol.37, p.81.
[3] A. C. Beck. “Uso da Técnica VLIW para Aumento de Performance e Redução do Consumo de Potência em Sistemas Embarcados Baseados em Java”. Dissertação de Mestrado apresentada ao PPGC-UFRGS, 2004.
[4] Barroso, L.A.; Gharachorloo, K.; McNamara, R.; Nowatzyk, A.; Qadeer, S.; Sano, B.; Smith, S.; Stets, R.; Verghese, B. “Piranha: a scalable architecture based on
single-chip multiprocessing”. Proceedings of the 27th International Symposium on Computer Architecture, 2000, pp. 282-293.
[5] Nayfeh, B.A.; Olukotun, K. “A single-chip multiprocessor”. Computer, Volume 30, Issue 9, Sept. 1997, pp. 79-85. [6] S. Ito, L. Carro, R. Jacobi, “Making Java Work for
Microcontroller Applications”. IEEE Design & Test, vol.
18, no. 5, Set-Oct. 2001, pp. 100-110.
[7] A. C. S. Beck and L. Carro, “Low Power Java Processor for Embedded Applications”, in IFIP 12th International
Conference on Very Large Scale Integration (VLSI-SOC).
Germany, 2003.
[8] IBM Corporation. “CoreConnect bus architecture”. http://www-03.ibm.com/chips/products/coreconnect/.
