Utilização do Barramento CoreConnect para - Inf

Utilização do Barramento CoreConnect para
Implementação de CMP com Processadores Java
Rodrigo Bittencourt Motta
Universidade Federal do Rio Grande do Sul
Instituto de Informática - Av. Bento Gonçalves, 9500 Campus do Vale - Porto Alegre, Brasil
[email protected]
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 timeto-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, Desempenho
Palavras-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 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.
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.
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.
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 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
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.
interface CoreConnect que é responsável por determinar o
fluxo da comunicação.
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.
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.
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 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.
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
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.
3500
3304
3000
2500
2148
2000
1500
1000
500
41
0
FemtoJava
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).
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.
90000
80000
77379
77984
FemtoJava
FemtoJava CMP
70000
60000
50000
40000
30000
20000
10000
0
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/.