Académique Documents
Professionnel Documents
Culture Documents
Multiprocessados
Abstract
The old design model where a single processor provided all the functionalities on an embedded system
is not suitable anymore. A cell phone is a typical system that requires heterogenous multiple proces-
sors to support all its resources. With the advent of multiprocessor systems, software engineers are
facing new requirements to reach a high performance, mainly related to parallelism exploration. High
complexity and stringent time-to-market constraints obligate designers to develop hardware and soft-
ware simultaneously. In order to achieve that, an executable model of the whole system becomes
essential even at the beginning of the design process. This chapter discusses several issues on em-
bedded systems design, related both to hardware and software, focusing on the development of a
simulation model for a multiprocessor system.
Resumo
O antigo modelo de projeto no qual um nico processador era capaz de suprir todas as funciona-
lidades de um sistema dedicado j no mais suficiente. Um exemplo de sistema que requer uma
nova abordagem um aparelho celular, que pode ter mltiplos processadores, inclusive de categorias
diferentes. O surgimento de sistemas multiprocessados trouxe novos requisitos de software, principal-
mente relacionados explorao de paralelismo, para que o desempenho necessrio seja atingido.
Com o aumento da complexidade do sistema e a presso para lanamento no mercado, torna-se ne-
cessrio o desenvolvimento simultneo de hardware e software. Para isso, necessrio desenvolver
um prottipo funcional para realizar experimentos e testar a execuo do software nas fases iniciais
de projeto. Este captulo aborda questes gerais sobre como construir um sistema dedicado, tanto do
ponto de vista de hardware como de software, focando num exemplo prtico de um simulador de um
sistema multiprocessado.
7.1. Introduo
Com o aumento na densidade de circuitos integrados e sua popularizao
nos mais diversos dispositivos dedicados, a tarefa de desenvolver um sistema
complexo como um celular, PDA, tocador de DVD ou um console de videogame
torna-se cada vez mais dependente da infraestrutura de simulao que uti-
lizada no incio do ciclo de desenvolvimento. Questes crticas relacionadas
331
Azevedo, Rigo e Arajo
332
Projeto e Desenvolvimento de Sistemas Dedicados Multiprocessados
333
Azevedo, Rigo e Arajo
Custo unitrio: Quanto custar produzir uma unidade do produto final (ex-
cluindo o NRE).
NRE: Sigla para Non-recurring engineering, o valor gasto uma nica vez
para produzir o produto, tambm chamado de custo de engenharia.
Tamanho fsico: Quanto de integrao ser necessrio para o produto. Cada
nova instncia de um produto tende a ficar menor.
Desempenho: Qual a velocidade do produto para realizar sua funcionalidade.
Freqncia do processador ou nmero de instrues por segundo no
so mtricas de desempenho para um usurio final, que est preo-
cupado com a execuo da funcionalidade desejada num intervalo de
tempo factvel. Exemplos de medidas: quantas folhas por segundo uma
impressora capaz de imprimir, quantas fotos por segundo possvel
tirar com uma cmera digital, etc.
Consumo de energia: O aumento de funcionalidades de um produto pode
ocasionar um aumento no consumo de energia. Dois outros aspectos
importantes esto relacionados com o consumo de energia: a durao
da bateria em dispositivos que dependam dessa fonte de energia e a
dissipao de calor, que pode afetar o tamanho do dispositivo, com a
exigncia de dissipadores, ou mesmo impedir que ele seja utilizvel em
certos locais.
Flexibilidade: Capacidade de trocar a funcionalidade do dispositivo sem ter
outro custo de NRE.
Tempo de prototipao: Tempo necessrio para implementar uma verso to-
talmente funcional do sistema.
Tempo para mercado: Tempo necessrio para comear a vender o produto
(time-to-market).
Facilidade de manuteno: Capacidade de modificar o sistema aps o seu
lanamento para adequ-lo a novas funcionalidades ou corrigir deficin-
cias.
Corretude: Garantia de que as funcionalidades implementadas so satisfat-
rias.
334
Projeto e Desenvolvimento de Sistemas Dedicados Multiprocessados
Lucro
Pico de lucro
Lucro
Em tempo
D
o
im
um
in
ns
Pico de lucro
u
i
co
com atraso
o
do
do
to
co
en
ns
m
um
Au
Atrasado
o
A L 2L
A B Tempo Tempo
335
Azevedo, Rigo e Arajo
Quantidade A B C
100 R$ 200,00 R$ 525,00 R$ 5.002,00
1.000 R$ 110,00 R$ 75,00 R$ 502,00
10.000 R$ 101,00 R$ 30,00 R$ 52,00
100.000 R$ 100.10 R$ 25.50 R$ 7,00
1.000.000 R$ 100.01 R$ 25.05 R$ 2.50
Tabela 7.2. Custo final por produto levando em conta o
custo unitrio, o NRE e a quantidade produzida
diludos. A Tabela 7.2 mostra como variam os custos por produto em relao
quantidade produzida. Como exemplo, para produzir 10 mil unidades, melhor
utilizar a tecnologia B, que levar a um custo final por produto (em Reais) de
(50.000 + 10.000 25)/10.000 = 30.
336
Projeto e Desenvolvimento de Sistemas Dedicados Multiprocessados
Componentes Lgica
ASIC
avulsos Programvel
Nvel de integrao Alto Baixo Alto
Custo de desenvolvimento Alto Baixo Baixo
Custo unitrio Baixo Baixo Moderado
Flexibilidade do projeto Baixa Baixa Alta
Tempo de desenvolvimento Longo Moderado Curto
Tabela 7.3. Comparao entre as formas de desenvolvi-
mento de sistemas dedicados
337
Azevedo, Rigo e Arajo
338
Projeto e Desenvolvimento de Sistemas Dedicados Multiprocessados
339
Azevedo, Rigo e Arajo
340
Projeto e Desenvolvimento de Sistemas Dedicados Multiprocessados
7.2.3. SystemC
Na modelagem de um sistema dedicado complexo, deve-se utilizar todo
o ferramental disponvel para reduzir o overhead de projeto, garantindo mais
eficincia no desenvolvimento e menor possibilidade de erro, por no ter
que implementar caractersticas bsicas j disponveis e testadas. Sys-
temC [OSCI 2005] uma biblioteca de classes gratuita que foi criada para
projetos em nvel de sistema. Utilizando SystemC pode-se modelar, simulta-
neamente, hardware e software, com seus comportamentos distintos permi-
tindo, inclusive, refinar o cdigo durante o desenvolvimento, migrando partes
de software para hardware e vice-versa.
SystemC tornou-se o padro IEEE 1666 no incio de 2006, o que garante
que diferentes implementaes devem possuir as mesmas caractersticas fun-
cionais documentadas. A seguir, ser dada uma breve viso de SystemC; mai-
ores detalhes podem ser obtidos atravs das referncias bibliogrficas. Para
ilustrar alguns elementos bsicos de SystemC, um exemplo com trs arquivos
ser mostrado. Esse exemplo composto por um mdulo que detecta, entre
suas duas entradas, qual delas tem o maior valor e coloca esse valor na sada;
um segundo mdulo que gera entradas para o primeiro e um arquivo principal
que instncia os dois mdulos, interliga suas portas com sinais e realiza uma
simulao.
A Figura 7.2 inicia o exemplo com um mdulo em SystemC que recebe dois
inteiros sem sinal como entrada e gera como sada o maior deles. Para facilitar
341
Azevedo, Rigo e Arajo
342
Projeto e Desenvolvimento de Sistemas Dedicados Multiprocessados
343
Azevedo, Rigo e Arajo
7.2.4. O Compilador
A forma geral da frase compilar um programa significa, no fundo, passar um
cdigo-fonte pela fase de compilao, montagem (assembly ) e ligao (link ) e
exige muito mais do que apenas o cdigo-fonte do programa que ser compi-
lado. Como exemplo dos passos necessrios, a Figura 7.5 ilustra a sada do
comando gcc -v hello.c -o hello. A opo -v indica ao gcc para im-
primir todos os comandos que for executar. A primeira linha indica o arquivo
de especificao do modelo de memria e bibliotecas utilizado pelo compila-
dor. Esse arquivo indica a localizao-padro dos arquivos de biblioteca, quais
arquivos devem ser includos automaticamente na hora de ligar o executvel
344
Projeto e Desenvolvimento de Sistemas Dedicados Multiprocessados
4O arquivo executvel pode ter sua primeira instruo em qualquer lugar, mas essa ins-
truo estar dentro de um dos arquivos crt que, na seqncia de execuo, chamar
a funo main do usurio.
345
Azevedo, Rigo e Arajo
346
Projeto e Desenvolvimento de Sistemas Dedicados Multiprocessados
347
Azevedo, Rigo e Arajo
348
Projeto e Desenvolvimento de Sistemas Dedicados Multiprocessados
349
Azevedo, Rigo e Arajo
5 http://www.intel.com/cd/software/products/asmo-na/eng/compilers/219771.htm
350
Projeto e Desenvolvimento de Sistemas Dedicados Multiprocessados
351
Azevedo, Rigo e Arajo
352
Projeto e Desenvolvimento de Sistemas Dedicados Multiprocessados
353
Azevedo, Rigo e Arajo
354
Projeto e Desenvolvimento de Sistemas Dedicados Multiprocessados
355
Azevedo, Rigo e Arajo
356
Projeto e Desenvolvimento de Sistemas Dedicados Multiprocessados
357
Azevedo, Rigo e Arajo
1 AC_ARCH( mips ) {
2
3 ac_wordsize 3 2 ;
4
5 ac_mem MEM:256 k ;
6 ac_regbank RB: 3 2 ;
7 ac_reg HI , LOW;
8
9 ARCH_CTOR( mips ) {
10 ac_isa ( " mips_isa . ac " ) ;
11 set_endian ( " b i g " ) ;
12 };
13 };
358
Projeto e Desenvolvimento de Sistemas Dedicados Multiprocessados
1 AC_ARCH( sparcv8 ) {
2
3 ac_mem MEM: 5M;
4 ac_regbank RG: 8 ;
5 ac_regbank RB: 2 5 6 ;
6 ac_reg PSR, Y ;
7 ac_wordsize 3 2 ;
8
9 ARCH_CTOR( sparcv8 ) {
10 ac_isa ( " s p a r c v 8 _ i s a . ac " ) ;
11 set_endian ( " b i g " ) ;
12 };
13 };
359
Azevedo, Rigo e Arajo
1 AC_ISA ( mips ) {
2 ac_format Type_R= "%op :6 % r s :5 % r t :5 % r d : 5 0 x00 :5 % f u n c : 6 " ;
3 ac_format Type_I= "%op :6 % r s :5 % r t :5 %imm : 1 6 : s " ;
4 ac_format Type_J= "%op :6 % addr : 2 6 " ;
5
6 ac_instr <Type_R > add , addu , subu , multu , divu , s l t u ;
7 ac_instr <Type_I > lw , sw , beq , bne ;
8 ac_instr <Type_I > addi , andi , o r i , l u i , s l t i ;
9 ac_instr <Type_J > j , jal ;
10
11 ISA_CTOR ( mips ) {
12 l o a d . set_asm ( " lw %reg , % exp(%reg ) " , r t , imm , r s ) ;
13 l o a d . set_decoder ( op=0x23 ) ;
14
15 add . set_asm ( " add %reg , % reg , % reg " , rd , rs , r t ) ;
16 add . set_decoder ( op=0x00 , f u n c =0x20 ) ;
17 ...
18 };
19 };
360
Projeto e Desenvolvimento de Sistemas Dedicados Multiprocessados
1 / / I n s t r u c t i o n add b e h a v i o r method .
2 void ac_behavior ( add ) {
3 RB. w r i t e ( rd , RB. read ( r s ) + RB. read ( r t ) ) ;
4 };
361
Azevedo, Rigo e Arajo
Uma outra tcnica foi idealizada para simulao de arquiteturas. Ela con-
siste em pr-calcular algumas operaes e guardar seus resultados, evitando
repetir os mesmos clculos durante a simulao. A esta tcnica deu-se o nome
de simulao compilada. ArchC tambm oferece a possibilidade de gerao de
simuladores compilados, atravs da ferramenta accsim. Esse tipo de simula-
dor gerado, especificamente, para uma dada aplicao, mas possui uma s-
rie de otimizaes se comparado com a simulao interpretada. Por exemplo,
anular o passo de decodificao das instrues da aplicao e tirar proveito do
fato da ordem das instrues tambm ser fixa, o que permite criar um simula-
dor que escalona o comportamento de cada instruo do programa na mesma
ordem original. A aplicao dessa tcnica gera simuladores que so da ordem
de 100 vezes mais rpidos que os interpretados. Isso pode ser considerado
vlido tambm para outras ADLs, mas ArchC conta ainda com otimizaes
prprias que elevam o desempenho em at 200%, se comparado com a mdia
dos simuladores compilados tradicionais. Para fazer uso dessas otimizaes
exclusivas, o projetista precisa incluir algumas informaes extras no modelo
que esto fora do escopo deste captulo, mas o leitor interessado pode encon-
trar detalhes em [Bartholomeu et al. 2004].
Esta seo apresenta uma introduo modelagem de processadores
usando ArchC e a seus simuladores. Detalhes especficos sobre gerao de
ferramentas, tais como montadores, ligadores, interfaces de depurao podem
ser encontrados nos manuais [Team 2004, Team 2005] e na pgina da lingua-
gem na Internet (http://www.archc.org), onde se encontram disponveis as fer-
ramentas e modelos.
362
Projeto e Desenvolvimento de Sistemas Dedicados Multiprocessados
dos especificamente para fazer a converso entre esses nveis. Esses mdulos
so chamados de wrappers. Nesta seo, sero tratados apenas mdulos es-
critos nos nveis:
RTL: Sigla para Register Transfer Level, que um nvel de abstrao baixo,
composto por mapeamentos de componentes e operaes que podem
ser mapeadas diretamente para hardware. A ligao entre os componen-
tes feita atravs de sinais (abstrao para fios). Em geral, esse nvel
bem definido, tanto do ponto de vista dos projetistas, quanto do ponto
de vista de fabricante de ferramentas de projeto de hardware. Por ser de
mais baixo nvel, um simulador RTL gasta mais tempo para realizar uma
determinada tarefa que um simulador de nvel de abstrao mais alto, no
entanto, ele mais preciso em relao temporizao das operaes, o
que til nas fases mais avanadas do desenvolvimento.
TLM: Sigla para Transaction Level Model, que um nvel de abstrao mais
alto. Em geral, todos os mdulos possuem uma descrio tambm em
alto nvel e a comunicao entre eles feita atravs da chamada de m-
todos das classes, seguindo uma interface bem definida. justamente
nessa interface que reside o problema: como TLM significa to-somente
chamada de funo, necessria uma especificao bem detalhada das
interfaces e suas funcionalidades, que ser tratada nesta seo. Em ge-
ral, um simulador comportamental, com comunicao TLM, consegue
mais velocidade de simulao ao custo da perda de informaes sobre
a temporizao.
363
Azevedo, Rigo e Arajo
Initiator: Indica o mdulo que inicia a transao. Foi evitado o uso do termo
364
Projeto e Desenvolvimento de Sistemas Dedicados Multiprocessados
365
Azevedo, Rigo e Arajo
1 AC_ARCH( mips ) {
2 a c _ t l m _ p o r t DM: 5M; / / < < P o r t a TLM
3 ac_wordsize 3 2 ;
4 ac_regbank RB: 3 2 ;
5 ac_reg HI , LOW;
6
7 ARCH_CTOR( mips ) {
8 ac_isa ( " mips_isa . ac " ) ;
9 set_endian ( " b i g " ) ;
10 };
11 };
1 / / ! I n s t r u c t i o n lw b e h a v i o r method .
2 void ac_behavior ( lw )
3 {
4 RB. w r i t e ( r t , DM. read (RB. read ( r s ) + imm ) ) ;
5 };
Mais de uma porta TLM pode ser criada no modelo do processador para
permitir a comunicao direta com mais de um barramento ou dispositivo ex-
terno. Nesse caso, o projetista deve se responsabilizar por fazer as devidas
checagens de faixas de endereo e chamadas aos mtodos read e write de
cada uma das portas.
Um ponto importante a conexo do mdulo de memria externo ao pro-
cessador. Isto feito no arquivo com a funo principal do projeto, onde
normalmente so instanciados e conectados todos os mdulos. Um exem-
plo desse tipo de arquivo foi mostrado na Figura 7.4. A Figura 7.15 mostra
um trecho de cdigo onde ocorre a instanciao e a conexo de um simu-
lador gerado por ArchC a um mdulo de memria externo criado pelo proje-
6
Observe que esses dois mtodos representam a interface interna do processador (vista
pelas instrues) e no as externas do TLM que sero descritas a seguir.
366
Projeto e Desenvolvimento de Sistemas Dedicados Multiprocessados
367
Azevedo, Rigo e Arajo
1 AC_ARCH( mips ) {
2 ac_mem DM: 5M;
3 ac_wordsize 3 2 ;
4 ac_regbank RB: 3 2 ;
5 ac_reg HI , LOW;
6
7 ac_tlm_intr_port inta ; / / <<< P o r t a de i n t e r r u p c a o
8 ...
9 };
368
Projeto e Desenvolvimento de Sistemas Dedicados Multiprocessados
369
Azevedo, Rigo e Arajo
370
Projeto e Desenvolvimento de Sistemas Dedicados Multiprocessados
371
Azevedo, Rigo e Arajo
372
Projeto e Desenvolvimento de Sistemas Dedicados Multiprocessados
1 i n t sc_main ( i n t ac , char av [ ] )
2 {
3 / / I n s t a n c i a Simulador MIPS e memoria
4 mips1 mips1_proc1 ( " mips1 " ) ;
5 shr_mem mem( "mem" ) ;
6
7 # i f d e f AC_DEBUG / / Armazenamento de um t r a c e da simulacao .
8 a c _ t r a c e ( " mips1_proc1 . t r a c e " ) ;
9 #endif
10
11 / / Conecta Processador e Memoria
12 mips1_proc1 . DM_port (mem. t a r g e t _ e x p o r t ) ;
13
14 / / I n i c i a l i z a c a o do Simulador . Padrao para modelos em ArchC
15 mips1_proc1 . i n i t ( ac , av ) ;
16 c e r r < < endl ;
17
18 sc_start ( 1); / / I n i c i a simulacao
19
20 mips1_proc1 . P r i n t S t a t ( ) ;
21 c e r r < < endl ;
22
23 # i f d e f AC_DEBUG
24 ac_close_trace ( ) ;
25 #endif
26
27 r e t u r n mips1_proc1 . a c _ e x i t _ s t a t u s ;
28 }
373
Azevedo, Rigo e Arajo
374
Projeto e Desenvolvimento de Sistemas Dedicados Multiprocessados
375
Azevedo, Rigo e Arajo
0M
2M 0M
MIPS1_PROC1 shared
3M 2M
shared
3M
5M
5M
0M 7M
2M unused
shared 8M
MIPS1_PROC2 3M
10M
5M
7.6.1.1. Interfaces
376
Projeto e Desenvolvimento de Sistemas Dedicados Multiprocessados
7.6.1.2. rbitro
377
Azevedo, Rigo e Arajo
o que est sendo julgada for uma transao proveniente de um mestre que
ganhou a ltima disputa com uma transao em rajadas, as prioridades so
sobrepujadas em detrimento da rajada.
7.6.2. A Aplicao
A aplicao escolhida para executar esse exemplo foi adaptada a partir
do conhecido benchmark de aplicaes paralelas SPLASH-2 (Stanford Parallel
Applications for Shared Memory) [Woo et al. 1995], desenvolvido na Universi-
dade de Stanford7 . O SPLASH2 foi originalmente desenvolvido como testbench
para sistemas multiprocessos. Com um sistema operacional (SO) rodando na
arquitetura, uma questo de implementao a possibilidade de simular o mul-
tiprocessamento, independentemente da quantidade fsica de processadores
disponveis. Como mencionado na Seo 7.3, as alternativas de implementa-
o incluem o fork, do POSIX, e a thread, implementada por diversas bibliote-
cas, entre elas a pthreads.
Nas fases iniciais do projeto de um sistema embarcado multicore poss-
vel que a presena do sistema operacional no seja vivel, mas ainda assim
a equipe de software precisa iniciar o trabalho de desenvolvimento da aplica-
o. Nesse caso, o tratamento das complicaes inerentes ao processamento
paralelo deve ser realizado pelo desenvolvedor. Tarefas como a diviso dos
processos, sincronizao e excluso mtua, antes resolvidas genericamente
pelo SO, agora devem ser feitas caso a caso.
O cdigo do SPLASH2 possui as partes crticas em relao ao multipro-
cessamento mapeadas em macros m4, o que facilita o trabalho de portar estes
programas para diferentes implementaes. Na verdade, essa abordagem tam-
bm facilita o trabalho de um programador que deseje dividir os programas em
partes que possam ser executadas paralelamente e cuidar das tarefas de sin-
cronizao sem a presena de um sistema operacional. Essa a aboradagem
adotada para o exemplo de sistema multicore sendo montado neste captulo.
A aplicao FFT (transformada de Fourier) do SPLASH-2 uma verso
de uma dimenso do algoritmo descrito por Bailey [Bailey 1990], que otimi-
zada para minimizar a comunicao entre processos. Os dados de entrada so
representados em um vetor de n entradas a serem processadas, preenchido
aleatoriamente pelo processo pai, e outro vetor de mesma dimenso chamado
de razes nicas.
Durante a execuo, cada processador recebe uma srie contgua de li-
nhas destas matrizes e armazena-as localmente, trabalhando em seu conjunto
de dados prprio. Nos trs passos onde a tranposio das matrizes feita,
h a necessidade de comunicao interprocessador, feita atravs da memria
compartilhada e usando as estruturas de sincronizao para resolver condi-
es de disputa. Nos outros passos no h comunicao, sendo que todos
os processadores podem trabalhar concorrentemente. Uma descrio deta-
7 disponvel em http://www-flash.stanford.edu/apps/SPLASH/
378
Projeto e Desenvolvimento de Sistemas Dedicados Multiprocessados
O programa FFT foi dividido para que cada processador pudesse ser tra-
tado como uma unidade atmica, executando somente um cdigo, sem com-
partilhamento de tempo. A presena de diversos processadores caracteriza o
multiprocessamento.
Os programas do SPLASH-2 esto estruturados de forma que as rotinas
executadas nos processos-filhos se destacam claramente do fluxo de execuo
principal. O fragmento de cdigo abaixo mostra um cdigo original do programa
FFT do SPLASH2 (a partir daqui todos os exemplos tero como base este
programa).
1 / f i r e o f f P processes /
2 f o r ( i = 1 ; i <P ; i + + ) {
3 CREATE( S l a v e S t a r t ) ;
4 }
5 SlaveStart ( ) ;
379
Azevedo, Rigo e Arajo
380
Projeto e Desenvolvimento de Sistemas Dedicados Multiprocessados
7.7. Concluso
O grande crescimento na complexidade dos sistemas dedicados ao longo
dos ltimos anos, culminando com o recente surgimento das novas arquitetu-
ras multiprocessador, ou multicore, trouxe uma srie de novos desafios para
os projetistas, tanto do ponto de vista de hardware como de software. Um
dos pontos principais a necessidade de uma metodologia de projeto onde
ocorra uma forte interao entre as equipes de desenvolvimento de hardware
e software, possibilitando seu desenvolvimento simultaneamente. Com isso,
ferramentas e linguagens de auxlio ao projeto de sistemas ganham cada vez
mais fora na indstria e academia.
Este captulo abordou uma srie de problemas, apresentando algumas fer-
ramentas que vm sendo largamente utilizadas para agilizar e facilitar o tra-
balho dos projetistas. Dentre elas esto: a linguagem SystemC, cuja principal
caracterstica possibilitar o projeto em nvel de sistema, e linguagens de des-
crio de arquiteturas, que exercem papel fundamental na gerao automtica
de ferramentas de software.
O exemplo de sistema multicore pode ser facilmente ampliado colocando-
se mais processadores, ou mesmo outros IPs de hardware descritos em Sys-
temC, instanciando-os no arquivo da Figura 7.22 e interligando-os, tambm,
ao barramento. Devido ao esquema de mapeamento de endereos utilizado,
basta instanciar novos wrappers corretamente parametrizados e aumentar o
tamanho da memria global para que o novo sistema passe a funcionar com
essa quantidade maior de processadores. Isso demonstra a adaptabilidade
do sistema a novos requisitos. Outra caracterstica importante que o soft-
ware desenvolvido nesse sistema deve ter caractersticas bem similares, seno
idnticas, ao que ser executado no sistema final. Essa metodologia permite o
desenvolvimento adiantado do software de sistema e, conseqentemente, dos
381
Azevedo, Rigo e Arajo
aplicativos.
Referncias
[AMBA 1999] AMBA (1999). AMBA Specification Rev 2.0. ARM Corporation,
http://www.arm.com/products/solutions/AMBA_Spec.html.
[ArchC 2006] ArchC (2006). The ArchC Resource Center. http://www.
archc.org.
[Avalon 2005] Avalon (2005). Avalon Interface Specification. Altera Corpo-
ration, http://www.altera.com/literature/manual/mnl_avalon_
spec.pdf.
[Azevedo et al. 2005] Azevedo, R., Rigo, S., Bartholomeu, M., Arajo, G.,
Arajo, C., and Barros, E. (2005). The archc architecture description lan-
guage. International Journal of Parallel Programming, 33(5):453484.
[Bailey 1990] Bailey, D. H. (1990). FFTs in External or Hierarchical Memory.
Journal of Supercomputing, 4(1):2335.
[Baldassin et al. 2005] Baldassin, A., Centoducatte, P., and Rigo, S. (2005).
Extending the archc language for automatic generation of assemblers. In
Proceedings of the 17th International Symposium on Computer Architecture
and High Performance Computing, pages 6067.
[Bartholomeu et al. 2004] Bartholomeu, M., Azevedo, R., Rigo, S., and Araujo,
G. (2004). Optimizations for Compiled Simulation Using Instruction Type In-
formation. In Proceedings of the 16th Symposium on Computer Architecture
and High Performance Computing (SBAC04).
[Bashford et al. 1994] Bashford, S., Bieker, U., Harking, B., Leupers, R.,
Marwedel, P., Neumann, A., and Voggenauer, D. (1994). The MIMOLA Lan-
guage - Version 4.1. Technical report, Computer Science Dpt., University of
Dortmund.
[Braun et al. 2003] Braun, G., Wieferink, A., Schliebusch, O., Leupers, R.,
Meyr, H., and Nohl, A. (2003). Processor/Memory Co-Exploration on Mul-
tiple Abstraction Levels. In Proceedings of Design, Automation and Test in
Europe Conference (DATE).
[Burger et al. 1996] Burger, D., Austin, T. M., and Bennett, S. (1996). Evalu-
ating Future Microprocessors: The SimpleScalar Tool Set. Technical Re-
port CS-TR-1996-1308, University of Wisconsin. Computer Sciencies De-
partment.
[Chandra et al. 2000] Chandra, R., Menon, R., Dagum, L., Kohr, D., Maydan,
D., and McDonald, J. (2000). Parallel Programming in OpenMP. Morgan
Kaufmann.
[Cmelik and Keppel 1994] Cmelik, B. and Keppel, D. (1994). Shade: A fast
instruction-set simulator for execution profiling. ACM SIGMETRICS Perfor-
mance Evaluation Review, 22(1):128137.
382
Projeto e Desenvolvimento de Sistemas Dedicados Multiprocessados
383
Azevedo, Rigo e Arajo
384
Projeto e Desenvolvimento de Sistemas Dedicados Multiprocessados
385
Azevedo, Rigo e Arajo
386