Projeto e Desenvolvimento de Sistemas Dedicados Multiprocessados

Projeto e Desenvolvimento de Sistemas Dedicados
Multiprocessados
Rodolfo Azevedo, Sandro Rigo, Guido Arajo
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
com time-to-market exigem a reduo do tempo de prototipagem e o incio do

desenvolvimento do software o mais cedo possvel. Quanto mais baixo o n-
vel de abstrao do software desenvolvido, mais dependente ele do hardware
e, para garantir um modelo eficaz de desenvolvimento simultneo, necessrio
ter um simulador do sistema completo disponvel.
Considerando o projeto de novos processadores, pode ser visto que, devido
grande variabilidade de aplicaes, cada vez mais arquiteturas especializa-
das vm sendo propostas, tornando evidente a necessidade de modelos fle-
xveis para simulao, possibilitando ao projetista a adaptao do conjunto de
instrues de um processador a uma dada aplicao. Linguagens de Descrio
de Arquiteturas (ADLs) foram introduzidas para ajudar os projetistas a vencer
esses desafios surgidos no projeto e simulao de processadores nos ltimos
anos. Uma ferramenta para avaliar um novo conjunto de instrues deve ser
capaz de gerar, automaticamente, ferramentas de software como simuladores,
montadores, ligadores e at mesmo o backend de compiladores para ser um
instrumento aplicado rpida explorao de novas arquiteturas. Tais ferramen-
tas so comumente baseadas em modelos de processadores descritos atravs
de uma linguagem de descrio de arquiteturas.
Alm disso, no contexto dos atuais projetos de sistemas dedicados, pode-
se dizer que tais processadores sero, muito provavelmente, aplicados em sis-
temas heterogneos, pois a demanda de processamento das aplicaes aliada
complexidade do sistema aponta para um nmero cada vez maior de siste-
mas multicores ou multiprocessados. Essa tendncia pode ser verificada, por
exemplo, no roadmap do ITRS (International Technology Roadmap for Semi-
conductors) [ITRS 2005] que prev que, em breve, 70% dos projetos ASIC
(Application Specific Integrated Circuit) incluiro ao menos um processador
programvel embutido, o que significa que a maioria dos ASICs sero System-
on-chip (SoCs).
Portanto, torna-se fundamental para o aumento da capacidade de explora-
o de alternativas de projeto nesse tipo de sistemas que se possa simular no
s o processador executando um dado software, mas tambm todos os com-
ponentes envolvidos no sistema, tais como memrias, barramentos, sistemas
de interconexo e IPs de aplicao especfica projetados como mdulos indivi-
duais. Isto proporcionar a um projetista experimentar diversas alternativas de
arquitetura de um sistema como um todo, variando processadores, barramen-
tos, sistema de interconexo e at mesmo o particionamento hardware/soft-
ware, obtendo rapidamente, a cada mudana, uma especificao executvel
de seu sistema. Mais ainda, permite o reaproveitamento de mdulos desenvol-
vidos previamente para a integrao em um novo sistema. Todos esses fatores
podem ter um impacto muito positivo no tempo total de desenvolvimento do
produto, reduzindo seu time-to-market.
Essa necessidade de diminuio no tempo de projeto e a conseqente
implantao de tcnicas de hardware/software codesign [DeMicheli 1996,
Gasjki and Vahid 1995, Gupta et al. 1992], que o desenvolvimento simult-
332
Projeto e Desenvolvimento de Sistemas Dedicados Multiprocessados
neo de hardware e software, criaram um timo momento para o desenvolvi-

mento de metodologias e ferramentas baseadas no projeto em nvel de sis-
tema, ou no que hoje vem sendo chamado pela indstria de automao de pro-
jetos (EDA) de ESL (Electronic System Level) [McGrath 2005, Goering 2005].
Mais ainda, existem projees de que o mercado para ferramentas de ESL
pode chegar a mais de um bilho de dlares por ano no futuro, tornando-se a
principal rea do segmento de EDA [Krishnadas 2005].
O objetivo deste captulo tratar do desenvolvimento de simuladores de
sistemas dedicados. Ser dado foco no desenvolvimento de sistemas multipro-
cessados, que representam uma nova vertente nessa rea e que precisam de
especial ateno, tanto do ponto de vista do programador final quanto do ponto
de vista do projetista, para fornecer um conjunto mnimo aceitvel de funciona-
lidades. Sero apresentadas a linguagem de descrio de arquiteturas ArchC,
como meio de se obter rapidez e flexibilidade no projeto de simuladores de pro-
cessadores, e a biblioteca de classes SystemC (baseada em C++), que vem
surgindo como um novo padro na indstria para projeto de sistemas comple-
xos em alto nvel de abstrao. Recentemente, a especificao do SystemC foi
aprovada como padro IEEE 1666.
O captulo est dividido da seguinte forma: a Seo 7.2 aborda os prin-
cipais aspectos no projeto de um sistema dedicado; a Seo 7.3 discute os
problemas encontrados no projeto de software para sistemas multicore; a Se-
o 7.4 apresenta linguagens de descrio de arquiteturas e descreve como
modelar processadores na linguagem ArchC; a Seo 7.5 descreve como in-
terligar os processadores com os demais mdulos do sistema, definindo, in-
clusive, os nveis de abstrao possveis e formas de integrar componentes de
mais de um nvel de abstrao usando a linguagem SystemC; a Seo 7.6 faz
um apanhado de tudo o que foi descrito no captulo e descreve um exemplo
completo, que de o um simulador de um sistema multicore; finalmente, a
Seo 7.7 apresenta as concluses.
7.2. Projeto de Sistemas Dedicados

Existem vrias definies para sistemas dedicados. A definio mais geral
Sistema Dedicado todo sistema computacional que no um computa-
dor faz com que sejam contabilizados bilhes de unidades produzidas por
ano, contra milhes de computadores. Algumas das principais caractersticas
comuns a esses sistemas [Vahid and Givargis 2002]:
Propsito nico: Em geral, executam apenas um nico programa repetitiva-

mente. Essa caracterstica est mais flexibilizada em alguns dispositivos,
como os aparelhos celulares, que tiveram um grande aumento de funcio-
nalidade, servindo de agenda eletrnica, cmera fotogrfica, videogame,
etc.
Fortes restries de projeto: baixo custo, baixo consumo de energia, pe-
queno tamanho, velocidade, etc.
333
Reatividade: Em geral reagem ao que acontece ao redor deles, com pouca

interao humana na maior parte dos casos.
Tempo Real: Precisam completar as tarefas em um intervalo de tempo bem
definido, sem atrasos. Esse intervalo de tempo pode variar de nme-
ros bem pequenos (milissegundos ou menos) at horas, dependendo da
especificao do sistema.
Agrupadas a essas caractersticas e restries, diversas mtricas precisam

ser consideradas no desenvolvimento de sistemas dedicados:
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
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
(a) Volume de vendas (b) Entrada atrasada no mer-

cado
Figura 7.1. Janela de mercado
Segurana: Garantia de que o produto no causar danos imprevistos quando

utilizado.
Melhorar algumas dessas mtricas pode afetar outras delas. Alguns exem-
plos so: um aumento de desempenho pode aumentar o consumo de energia,
o NRE e o tamanho; uma diminuio do NRE pode ocasionar um aumento no
consumo de energia, no tamanho fsico e at no custo unitrio; aumento na
flexibilidade pode levar ao aumento no consumo de energia, maior facilidade
de manuteno, aumento de tempo para mercado e do tempo de prototipao.
7.2.1. Custo do Produto

Maximizar o lucro obtido pelo produto no mercado implica diminuir o custo,
o NRE, ou aumentar as vendas. O aumento de vendas est diretamente re-
lacionado com a janela de mercado (Figura 7.1), que impe restries crticas
em torno do tempo de projeto de um produto. Observe que o lucro cresce at
um pico e depois decai com o trmino da vida til do produto. A Figura 7.1(a)
indica a forma usual da janela de mercado (o intervalo de A at B pode ser visto
como uma meta de tempo de vendas pela empresa) e a Figura 7.1(b) indica o
impacto nas vendas de um produto que foi lanado atrasado. Um modelo sim-
plificado para clculo de lucro leva em considerao as reas dos tringulos
de lucros da Figura 7.1(b). Uma entrada atrasada no mercado, indicada pelo
ponto A, leva a uma reduo nas vendas e no lucro mximo que poder ser
obtido, proporcional rea destacada na figura.
Calcular o custo do produto implica medir o custo de produo e o NRE.
O NRE fortemente dependente das escolhas durante o projeto e precisa ser
diludo por todos os produtos. A Tabela 7.1 indica possveis custos para 3
tecnologias distintas de produo. Cada uma delas possui um NRE e um custo
de produto diferente. Esses dados s serviro para sustentar alguma deciso
se houver uma estimativa de produo total para que os custos do NRE sejam
335
Tecnologia NRE Custo unitrio

A R$ 10.000 R$ 100
B R$ 50.000 R$ 25
C R$ 500.000 R$ 2
Tabela 7.1. Opes de custo para trs tecnologias dis-

tintas de produo
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.
7.2.2. Tecnologias de Implementao

Conforme j visto na seo de custos, a escolha da tecnologia correta de
implementao pode significar uma diferena significativa de preos e transfor-
mar uma idia de sucesso num fracasso de projeto. As trs principais alter-
nativas de projeto so o projeto de um circuito integrado especfico (ASIC), a
utilizao de componentes avulsos (off-the-shelf ) e o uso de tecnologias pro-
gramveis (FPGA). A Tabela 7.3 descreve as principais caractersticas de cada
uma das alternativas. Embora a migrao de uma tecnologia de implementa-
o para outra no seja suave, existem solues alternativas entre essas tecno-
logias. Dois exemplos comuns so os processos HardCopy da Altera para suas
linhas de FPGA Stratix e EasyPath da Xilinx para a famlia de FPGA Virtex. Em
ambos os casos, um projeto com lgica programvel convertido num cir-
cuito de aplicao especfica pelo prprio fabricante da FPGA, utilizando como
entrada as mesmas informaes de programao das FPGAs, num processo
mais curto e mais suave que a produo de ASICs, mantendo ou melhorando
vrias das caractersticas do circuito como freqncia de operao, gasto de
rea, pinagem do componente ( possvel substituir o componente program-
vel pelo novo circuito integrado na mesma placa j projetada), consumo de
energia, etc.
336
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
O uso de componentes avulsos tem se justificado hoje em dia apenas para

projetos pequenos e que possuam flexibilidade de rea para implementao.
Em geral, muitos desses sistemas j incluem dispositivos lgicos programveis
(PLDs ou FPGAs) em suas placas, mas geralmente so componentes peque-
nos para implementao de glue logic ou substituio de componentes que
saram de linha ou que no existam em quantidade necessria (os dois ltimos
so fatores importantes contra o uso de componentes avulsos).
Em relao ao uso feito dessas tecnologias, medida em que os sistemas
dedicados crescem, maiores so as chances deles inclurem um ou mais pro-
cessadores e, nesse momento, outra escolha importante ser necessria no
projeto. A escolha prvia da tecnologia de implementao j pode ter imposto
alguma restrio nas opes de processadores disponveis, mas muito pro-
vavelmente no se restringiu ainda a apenas um processador. Sendo assim,
algumas questes devem ser consideradas:
Tamanho da palavra: Denomina-se palavra a unidade comum de manipula-
o de informaes pelo processador. Os processadores mais comuns
da atualidade tm palavras de tamanho 8, 16, 32 e 64 bits. Esse tama-
nho est intrinsecamente relacionado quantidade de dados que podem
ser manipulados de uma s vez pelo processador, ao tamanho de cada
registrador do seu banco de registradores e tambm ao espao endere-
vel. Dois exemplos bastante regulares so as arquiteturas MIPS II e
SPARC v8, que possuem palavras de 32 bits, com registradores tambm
de 32 bits, instrues de 32 bits e 32 bits de espao de endereamento.
Por outro lado, processadores atuais da famlia x86 da Intel ou AMD tm
palavras de 32 ou 64 bits (no caso do Intel EM64T e AMD64), instru-
es de tamanho variado, registradores de 8, 16, 32, 64 e 128 bits e
espao de endereamento podendo variar de 32 at 48 bits. Por ser
uma arquitetura to complexa, pouco comum ver processadores x86
em sistemas dedicados pequenos1 . O processador ARM, que domina
1At mesmo a Microsoft, grande desenvolvedora de software para a famlia x86 de pro-
cessadores, trocou o processador Pentium pelo PowerPC na segunda verso de seu
337
em quantidade o mercado de sistemas dedicados, possui palavra, re-

gistradores, instruo e espao de endereamento de 32 bits. S que,
por questes relacionadas com o tamanho do programa executvel, ele
tambm possui uma representao de um subconjunto de seu conjunto
de instrues em 16 bits, que coexiste com a verso original no mesmo
processador, mantendo todas as demais caractersticas em 32 bits.
Organizao dos bytes dentro das palavras: Existem duas formas igual-
mente comuns de organizao dos bytes dentro das palavras: Na orga-
nizao little endian, o byte menos significativo da palavra fica no ende-
reo de memria mais baixo e o byte mais significativo fica no endereo
de memria mais alto. Na organizao big endian acontece o contr-
rio. As arquiteturas SPARC e ARM so big endian. O exemplo mais
comum de arquitetura little endian a Intel x86. Existem arquiteturas
que permitem a configurao da organizao das palavras na memria;
o exemplo mais comum a arquitetura MIPS, que possui um registra-
dor de configurao especfico para essa finalidade. O conhecimento
da organizao dos bytes dentro das palavras necessrio quando dois
processadores se comunicam pois, se no houver casamento da ordem
das palavras, um processador no conseguir interpretar corretamente
as informaes que o outro enviar (ser necessrio fazer uma converso
de dados). Esse um grande problema a ser tratado em sistemas multi-
processados heterogneos. No caso de simuladores de processadores,
se o processador hospedeiro e o processador simulado no possurem
a mesma organizao de palavra, o processador hospedeiro dever re-
alizar todas as converses de endian necessrias. Um outro fator com-
plicador para o desenvolvimento de simuladores a existncia de pro-
cessadores que possuem endian diferentes para instrues e dados da
memria. Nesse caso, o simulador deve conseguir decodificar correta-
mente as instrues, a fim de simul-las e garantir, alm disso, que os
dados que o programa simulado ler da memria estejam corretos.
Espao de endereamento: Essa caracterstica, praticamente desconside-
rada no desenvolvimento de sistemas de uso geral, por serem fortemente
padronizados, extremamente importante ao se desenvolver um simula-
dor de um sistema dedicado. Questes importantes como o endereo de
incio dos programas, mapeamento de perifricos em espao global de
endereamento ou em endereos especficos para entrada/sada, uso
de tecnologias diferentes de memria (RAM, ROM, FLASH) em endere-
os distintos, quantidade de memria em cada uma dessas tecnologias,
endereo mximo disponvel para uso, endereo com e sem cache, etc.,
definem, conjuntamente, de forma praticamente nica, o processador no
sistema construdo. Por muitas vezes, alguns padres j definidos pelo
desenvolvedor da arquitetura so usados, com as adaptaes necess-
console de videogame XBox.
338
rias ao sistema em questo. A Tabela 7.4 ilustra o espao de enderea-

mento do processador Leon2, que uma implementao da arquitetura
SPARC v8. Uma propriedade importante desse mapa de memria a
disponibilidade de apenas 1Gb para software de usurio num espao
de endereamento total de 4Gb. Essa caracterstica est presente, em
maior ou menor quantidade, em todos os espaos de endereamento
de todos os processadores2 . Ainda com base nesse espao de ende-
reamento, os arquivos executveis devem ser preparados para utilizar
apenas o espao entre os endereos 0x40000000 e 0x7FFFFFFF. Outra
caracterstica importante, no mostrada no mapa de memria, que o
processador inicia sua execuo a partir do endereo 0, onde encontra
um cdigo de partida (boot) que, provavelmente, carregar um programa
para a memria RAM e transferir o controle para seu endereo de in-
cio. Cada programa pode ter um endereo de incio, que geralmente
guardado num dos campos de controle do arquivo executvel mas, num
sistema dedicado, muito comum que o endereo de incio seja rgido e
faa parte da especificao da plataforma.
Intervalo Tam. Contedo Controlador

00000000
512Mb PROM Contr. de Memria
1FFFFFFF
20000000
512Mb I/O em Memria Contr. de Memria
3FFFFFFF
40000000
1Gb SRAM e/ou SDRAM Contr. de Memria
7FFFFFFF
80000000
256Mb Registradores on-chip Barramento APB
8FFFFFFF
90000000
256Mb Unidade de depurao DSU
9FFFFFFF
Tabela 7.4. Espao de endereamento do processador
Leon2, implementao da arquitetura SPARCv8
Tratamento de interrupes: A forma mais eficaz para tratamento a eventos

externos aos processadores utilizar interrupes, tambm chamadas
de excees3 . So duas as formas mais comuns de tratamento de in-
2Nos processadores Pentium IV sem suporte a 64 bits, o espao de endereamento
tambm no chega aos 4Gb possveis para programa.
3
Algumas arquiteturas distinguem o termo interrupo de exceo, utilizando o primeiro
para eventos externos ao processador e o segundo para evento interno. Neste texto, os
dois termos sero tratados como sinnimos e ser utilizado o termo interno ou externo
quando for necessrio identificar a origem do evento.
339
terrupes: Na primeira, o processador reserva um endereo para cada

um dos diferentes tipos de eventos que possam acontecer e, quando
esse evento ocorre, transfere o fluxo de execuo para o endereo previ-
amente definido. Dessa forma, a rotina chamada sabe exatamente qual
foi o evento que a chamou e pode trat-lo diretamente. A segunda forma
de tratamento consiste no uso de apenas um endereo para todas as
interrupes e deixar para o software a tarefa de identificar com exati-
do o que aconteceu, em geral consultando registradores de estado do
processador e/ou dos perifricos.
CISC x RISC: Esses dois acrnimos criados para distinguir a complexidade do

conjunto de instrues (Complex Instruction Set Computer x Reduced
Instruction Set Computer) identificavam, inicialmente, alternativas dife-
rentes de implementao interna dos processadores. Por causa das ca-
ractersticas dos processadores RISC, como o tamanho fixo das instru-
es e sua diviso rgida em campos com poucos formatos, foi possvel
realizar implementaes com pipeline, que aumentaram a eficincia dos
processadores. No entanto, ao olhar para os conjuntos de instrues atu-
ais, v-se que olhar apenas para a quantidade de instrues pode no
ser mais suficiente para distinguir as arquiteturas. De fato, h uma con-
vergncia entre os conceitos CISC e RISC nas arquiteturas atuais. Pro-
cessadores, inicialmente projetados para conter apenas uma pequena
quantidade de instrues, foram ampliados com extenses multimdia
(MIPS, SPARC, PowerPC) e processadores com um grande conjunto de
instrues convertem-nas para um pequeno conjunto interno para faci-
litar a implementao em hardware (arquitetura x86). Outra diferenci-
ao tpica entre processadores RISC e CISC o tamanho do cdigo
executvel. Como os processadores CISC tm instrues de tamanho
varivel, em geral seus programas ocupam menos espao em mem-
ria, o que pode implicar em menor custo, menor consumo de energia e
maior desempenho para o sistema final. Para contornar essa limitao,
vrios processadores RISC possuem uma verso com codificao em
menor nmero de bits de seus conjuntos de instrues. Dois exemplos
desse caso so o MIPS16 para processadores MIPS [Kissell 1997] e o
Thumb [Turley 1995] para processadores ARM.
Barramento de Interconexo: Embora esse tem no seja, tecnicamente,

dependente do processador, na prtica poucos processadores es-
to implementados de forma independente dos barramentos de in-
terconexo. Alguns exemplos de barramentos de interconexo so:
AMBA [AMBA 1999] da ARM, Coreconnect [CoreConnect 2000] da IBM
e Avalon [Avalon 2005] da Altera. Com o crescimento dos sistemas
dedicados, comea-se a discutir o uso de NoCs [Hemani et al. 2000]
(Network-on-Chip) como forma de interligao de processadores e pe-
rifricos.
340
Ao se comparar processadores, no se deve perder de foco a aplicao

destino, principalmente se o software que ser executado possuir caractersti-
cas crticas. Um exemplo a destacar a escolha do processador para o projeto
PRISMA da Agncia Espacial Europia [Gill 2005]. Nesse exemplo foram con-
siderados trs processadores diferentes: ARM7TDMI, PowerPC823 e Leon2.
Ao executar a carga de trabalho esperada, o processador Leon2 se destacou
sendo 4-5 vezes mais rpido que o ARM que foi 2 vezes mais rpido que o
PowerPC. O nico ponto a destacar do estudo que o Leon2 o nico proces-
sador com unidade de ponto flutuante que bastante utilizada pelo software.
Esse fato no invalida o estudo, apenas serve para destacar a necessidade de
conhecer, antecipadamente, o software que ser utilizado.
Outra comparao, considerando os quesitos usabilidade, rea, fle-
xibilidade e desempenho, foi feita com os processadores MicroBlaze
da Xilinx, Leon2 da Gaisler Research e OpenRISC 1200 da OpenCo-
res [Mattsson and Christensson 2006]. Neste estudo, os autores relatam o
quo difcil chegar a resultados que possam ser comparados de forma justa,
visto que a comparao deve ser feita para cada funcionalidade, mas sempre
tentando chegar a um resultado final nico. Como o trabalho focou na compara-
o sem um software especfico, como no caso anterior, os resultados apenas
indicam uma direo de resultado, no uma escolha definitiva de processador
para todos os casos, como era de se esperar.
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
1 # i n c l u d e " systemc . h "

2
3 SC_MODULE( Maior ) / / Declaracao do modulo Maior
4 {
5 sc_in < unsigned i n t > A , B ; / / S i n a i s de e n t r a d a
6 sc_out < unsigned i n t > C; / / S i n a l de s a i d a
7
8 void do_Maior ( ) / / Uma funcao C++ comum
9 {
10 C . w r i t e ( A . read ( ) > B . read ( ) ? A . read ( ) : B . read ( ) ) ;
11 }
12
13 SC_CTOR( Maior ) / / Construtor
14 {
15 SC_METHOD( do_Maior ) ; / / R e g i s t r a do_Maior
16 sensitive < < A < < B; / / L i s t a de s e n s i b i l i d a d e
17 }
18 };
Figura 7.2. Exemplo de SystemC: Mdulo que imple-

menta uma funo maior que
a implementao em SystemC, algumas macros pre-definidas pela biblioteca

foram utilizadas no exemplo:
SC_MODULE define um mdulo, que a abstrao em SystemC
para uma unidade de hardware/software. Essa uma macro que
declara Maior como descendente do mdulo padro de SystemC, o
sc_module.
sc_in define as portas de entrada do mdulo; tambm uma macro, que
expande para instncias da classe sc_port.
sc_out similar ao sc_in, s que para portas de sada.
SC_CTOR o construtor do mdulo. Macro que expande para o cons-
trutor, iniciando tambm as demais classes da hierarquia.
SC_METHOD registra um mtodo da classe no kernel do SystemC. Isso
significa que o mtodo do_Maior ser executado diretamente pelo ker-
nel do SystemC sempre que necessrio.
sensitive declara a lista de sensibilidade de um mtodo. Toda vez que
houver uma alterao num dos sinais especificados na lista de sensibi-
lidade, o mtodo ser executado. exatamente esse o comportamento
desejado para a funo do_Maior, executar todas as vezes que uma de
suas entradas for alterada para fornecer a sada C coerente com as no-
vas entradas.
Uma vez definido o mdulo Maior, ele pode ser utilizado nos outros mdu-
los em que seja necessrio. Continuando com o exemplo, a Figura 7.3 ilus-
342

2
3 SC_MODULE( E s t i m u l o s )
4 {
5 sc_out <unsigned i n t > A , B ;
6 sc_in <bool > Clk ;
7
8 void GeraEstimulos ( )
9 {
10 A. write ( 5 ) ;
11 B. write ( 7 ) ;
12 wait ( ) ;
13 ...
14 sc_stop ( ) ;
15 }
16
17 SC_CTOR( E s t i m u l o s )
18 {
19 SC_THREAD( GeraEstimulos ) ;
20 s e n s i t i v e < < Clk . pos ( ) ;
21 }
22 };
Figura 7.3. Exemplo de SystemC: Gerador de estmulos

para o mdulo Maior
tra um mdulo que gera estmulos para o mdulo Maior. No corpo do m-

todo GeraEstimulos existem 3 seqncias de definies de valores para A
e B, seguidos de uma chamada funo wait(), que aguarda pelo prximo
evento. Observe tambm que o mtodo GeraEstimulos foi declarado dentro
do construtor como SC_THREAD, caracterstica necessria para permitir a cha-
mada de wait(). SC_THREAD declara mtodos que so considerados como
threads ao invs de processos. Ao final de GeraEstimulos existe uma cha-
mada a sc_stop, que encerra a simulao em SystemC. Outra caracterstica
desse exemplo a sensibilidade subida do sinal Clk (caracterizado pelo uso
de Clk.pos()).
Por fim, a terceira e ltima parte desse exemplo o arquivo principal, ilus-
trado na Figura 7.4. Esse um modelo-padro de arquivo principal do Sys-
temC, contendo a declarao de sinais (sinalA, sinalB, sinalC e clock),
que servem para interligar os mdulos. Logo a seguir esto as declaraes
dos dois mdulos (Estimulos e Maior) e a ligao dos sinais s portas dos
dois mdulos. Ao fim dessa seqncia existe uma chamada a sc_start(),
que inicia a simulao.
Esses so os conceitos bsicos de SystemC. Declaram-se mdulos que
podem ser compostos por sub-mdulos e assim, sucessivamente, faz-se a
interligao desses diversos componentes e gera-se um simulador do sis-
tema implementado. SystemC foi desenvolvido para modelar sistemas maiores
que o exemplo anterior, com elementos mais complexos, muitos deles j pr-
343

2 # i n c l u d e " maior . h "
3 #include " estimulos . h"
4
5 i n t sc_main ( i n t argc , char argv [ ] )
6 {
7 sc_signal <unsigned i n t > s i n a l A , s i n a l B , s i n a l C ;
8 sc_clock c l o c k ( " Clock " , 1 0 , SC_NS , 0 . 5 ) ;
9
10 Estimulos est ( " Estimulos " ) ;
11 Maior m( " Maior " ) ;
12
13 est .A( sinalA ) ;
14 est .B( sinalB ) ;
15 e s t . Clk ( c l o c k ) ;
16
17 m. A ( s i n a l A ) ;
18 m. B ( s i n a l B ) ;
19 m. C( s i n a l C ) ;
20
21 sc_start ( ) ; / / Executa o s i m u l a d o r
22
23 return 0 ;
24 }
Figura 7.4. Exemplo de SystemC: Arquivo principal que

interliga os dois mdulos
modelados como classes ou templates C++. Exemplos vo desde os sinais

(template) vistos no ltimo exemplo at filas do tipo FIFO genricas (template
para o contedo e um parmetro do construtor para a quantidade). Tudo isso
integrado a um ncleo de simulao (kernel do SystemC) padronizado e bem
documentado.
Nas prximas sees ser mostrado como utilizar a linguagem ArchC para
gerar simuladores de processadores em SystemC, como interligar componen-
tes mais complexos em SystemC utilizando uma modelagem por transao e
um exemplo de um sistema complexo passo a passo.
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
final e em que endereos de memria deve ficar cada pedao do programa

final. Criar um sistema com um processador com mapa de memria diferenci-
ado geralmente obriga o desenvolvedor a escrever um novo arquivo de specs.
Como prximo passo, o gcc indica as opes que foram usadas na sua pr-
pria compilao. A seguir, o executvel cc1, que o compilador C, chamado,
tendo entre suas diversas opes a especificao de um arquivo de sada em
assembly no diretrio /tmp. Esse arquivo assembly contm o cdigo referente
ao arquivo hello.c. Esse cdigo em assembly ento usado como entrada
do montador as que gerar como sada um arquivo-objeto, tambm no diretrio
/tmp. Chega-se ento na ltima fase do comando gcc, que consiste em ligar
o cdigo-objeto obtido pela compilao e montagem do programa-fonte forne-
cido com todos os outros arquivos necessrios para criar um executvel. O
ligador recebe vrios arquivos, em ordem, como parmetros. Apenas um des-
ses arquivos provm do hello.c fornecido como entrada para o gcc; todos os
outros so trechos de programas ou implementaes de funes necessrias
para a correta execuo de um programa C no sistema operacional e plata-
forma escolhidos. Entre esses arquivos, destacam-se os iniciados pelas letras
crt (crt1.o, crti.o, crtbegin.o para o incio do cdigo e crtend.o,
crtn.o para o final do cdigo). Os outros arquivos passados como parme-
tros indicam a biblioteca C que foi utilizada (em geral, glibc para desktops
e newlib para sistemas dedicados) e os diretrios onde os demais arquivos
que forem passados como parmetros podem ser encontrados. Outras biblio-
tecas podem ser includas dependendo do sistema operacional, da linguagem
utilizada e da verso do compilador. exatamente num dos arquivos crt de
incio que a funo main chamada garantindo, assim, um ponto de entrada
no cdigo padronizado do ponto de vista do usurio4 . Modificar a forma como
o executvel carregado na memria implica alterar um ou vrios desses ar-
quivos que so ligados ao programa principal. Apesar do gcc ser um compi-
lador nico com suporte a vrias plataformas, necessrio olhar diretamente
as implementaes desses arquivos do processador desejado para checar a
viabilidade das alteraes.
Uma caracterstica importante do compilador gcc sua portabilidade (pos-
sibilidade de executar em vrias plataformas) e capacidade de gerar cdigo
para vrias plataformas. chamado de cross-compiler o compilador que exe-
cuta numa plataforma e gera cdigo para outra. Nesse caso, a primeira pla-
taforma chamada de host ou hospedeira e a segunda de target ou destino.
No desenvolvimento de um sistema dedicado, praticamente a totalidade dos
programas gerada utilizando um cross-compiler. Uma caracterstica do gcc
para gerao de cdigo para plataformas distintas a necessidade de uma
instncia do compilador para cada plataforma-destino possvel.
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
Reading specs from /usr/lib/gcc/i686-pc-linux-gnu/3.4.5/specs

Configured with: /var/tmp/portage/gcc-3.4.5/work/gcc-3.4.5/configure
...
Thread model: posix
gcc version 3.4.5 (Gentoo 3.4.5, ssp-3.4.5-1.0, pie-8.7.9)
/usr/libexec/gcc/i686-pc-linux-gnu/3.4.5/cc1 -quiet -v hello.c -quiet
-dumpbase hello.c -mtune=pentiumpro -auxbase hello -version -o /tmp/ccEbvx6G.s
...
GNU C version 3.4.5 (Gentoo 3.4.5, ssp-3.4.5-1.0, pie-8.7.9) (i686-pc-linux-gnu)
compiled by GNU C version 3.4.4 (Gentoo 3.4.4-r1, ssp-3.4.4-1.0, pie-8.7.8).
GGC heuristics: --param ggc-min-expand=99 --param ggc-min-heapsize=129312
/usr/lib/gcc/i686-pc-linux-gnu/3.4.5/../../../../i686-pc-linux-gnu/bin/as
-V -Qy -o /tmp/ccBCTLx1.o /tmp/ccEbvx6G.s
GNU assembler version 2.16.1 (i686-pc-linux-gnu) using BFD version 2.16.1
/usr/libexec/gcc/i686-pc-linux-gnu/3.4.5/collect2 --eh-frame-hdr -m elf_i386
-dynamic-linker /lib/ld-linux.so.2 -o hello
/usr/lib/gcc/i686-pc-linux-gnu/3.4.5/../../../crt1.o
/usr/lib/gcc/i686-pc-linux-gnu/3.4.5/../../../crti.o
/usr/lib/gcc/i686-pc-linux-gnu/3.4.5/crtbegin.o
-L/usr/lib/gcc/i686-pc-linux-gnu/3.4.5 -L/usr/lib/gcc/i686-pc-linux-gnu/3.4.5
-L/usr/lib/gcc/i686-pc-linux-gnu/3.4.5/../../../../i686-pc-linux-gnu/lib
-L/usr/lib/gcc/i686-pc-linux-gnu/3.4.5/../../.. /tmp/ccBCTLx1.o -lgcc
--as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s
--no-as-needed /usr/lib/gcc/i686-pc-linux-gnu/3.4.5/crtend.o
/usr/lib/gcc/i686-pc-linux-gnu/3.4.5/../../../crtn.o
Figura 7.5. Resultado da compilao do programa hello.c
7.3. Software para Sistemas Multiprocessados

Uma aplicao em software a ponte entre o usurio e a plataforma de
hardware. Com a evoluo da tecnologia dos ltimos anos, o que vemos
uma quantidade cada vez maior de dados que precisa ser processada em um
perodo cada vez menor de tempo. Isso motiva os engenheiros de hardware a
atingir avanos em arquiteturas de microprocessadores e tecnologia de fabri-
cao visando criar plataformas capazes de suprir as necessidades de novas
aplicaes. At recentemente, principalmente no que se refere a processado-
res de propsito geral, o aumento de desempenho era perseguido atravs de
sucessivos aumentos na densidade de transistores e freqncia do clock. Isto
trouxe srios problemas de projeto, principalmente relacionados a consumo de
energia e dissipao de calor, obrigando os projetistas de grandes fabricantes
de processadores a buscar novas alternativas. Hoje em dia, os novos projetos
de processadores e sistemas utilizam multiprocessamento para atingir os requi-
sitos de desempenho sem comprometer o projeto com problemas relacionados
ao calor dissipado. Os chamados processadores multicore se tornaram os
principais produtos para computao de propsito geral de empresas como In-
tel (Pentium D e Pentium Extreme) e AMD (Opteron). No mercado de sistemas
dedicados, sistemas multicore heterogneos (CPUs e DSPs) esto sendo apli-
cados para atingir alto desempenho e um consumo razovel de potncia. Um
exemplo desse tipo de sistema o processador Cell da IBM, que ser usado
em uma gerao futura de consoles de videogame. Essas novas arquiteturas
tambm levaram para dentro da mesma pastilha de silcio os sistemas de co-
municao, como barramentos, e armazenamento, como caches. Do ponto de
vista do projetista de software, a palavra-chave atualmente paralelismo.
346
O principal problema que aplicaes seqnciais, que na literatura so

comumente chamadas de single-threaded, no conseguem tirar proveito das
caractersticas das novas arquiteturas multicore ou multiprocessadas. Em ou-
tras palavras, o desempenho de uma aplicao desse tipo no melhora sim-
plesmente por executarmos o programa em um processador multicore. Lin-
guagens como C e C++ so muito comuns no desenvolvimento de aplicao
de propsito geral e para sistemas dedicados, mas no oferecem na prpria
linguagem mecanismos para ajudar no particionamento da aplicao. Da o
surgimento de bibliotecas especiais para suportar o que conhecido como
programao paralela.
Programao paralela a explorao de paralelismo dentro de uma tarefa,
visando fazer com que ela seja executada de maneira mais eficiente para um
dado tamanho do problema. Durante anos, esse tipo de programao ficou
quase exclusivamente restrito aos domnios dos desenvolvedores de software
para computao de alto desempenho utilizando supercomputadores. Dadas
as recentes mudanas nas arquiteturas dos processadores, em breve todo de-
senvolvedor de software vai precisar ter algum conhecimento sobre esse as-
sunto. A boa notcia que durante todos esses anos os desenvolvedores da
computao de alto desempenho criaram inmeras tcnicas, interfaces de pro-
gramao (APIs) e ferramentas que podem passar a ser teis para todos os
programadores.
Atingir um ganho razovel de desempenho em sistemas multiprocessados
exige que tenhamos um software que seja capaz de explorar concorrncia,
que a habilidade de executar mais de uma tarefa simultaneamente. Alguns
pontos devem ser cuidadosamente analisados para a implementao de um
software que explore o fator concorrncia:
Identificar a concorrncia: Isto vale, tanto quando se est comeando a pen-
sar na soluo de um problema e se quer faz-lo de forma a explorar pa-
ralelismo, quanto para o processo de transformar um programa que rea-
liza tarefas de forma seqencial em um programa paralelo. Essa tarefa
pode ser simples para alguns problemas que so claramente paraleliz-
veis, mas em termos gerais uma tarefa bastante difcil, ou at mesmo
impossvel para determinados problemas.
Projeto do algoritmo: Projetar desde o incio ou alterar o projeto de um algo-
ritmo de maneira que ele se torne paralelo, isto , explicitamente con-
corrente. Muitos dos algoritmos usados em aplicaes multimdia so
paralelizveis. Um exemplo seria uma aplicao normalmente chamada
de raytracer, onde uma imagem 3D renderizada a partir de proces-
samento dos raios de luz que vo do observador, ou cmera, em dire-
o imagem. Cada raio pode ser tratado de maneira independente,
sendo o processamento de raios claramente paralelizvel. Existem algo-
ritmos onde possvel processar uma imagem dividindo-a em regies,
atribuindo o processamento de cada regio a um processador diferente.
Note que podem surgir problemas nas fronteiras das regies. Imagine
347
um algoritmo onde o valor de um pixel pode influenciar o valor de seus

vizinhos. Deve ocorrer uma comunicao entre as regies nesse caso,
implicando trocas de informao entre processadores diferentes.
Comunicao: Esse um processo que consome tempo e energia. No caso
de uma aplicao dividida entre vrios processadores, para projetar-se
um mecanismo e algoritmos de sincronizao que tornem a comunica-
o eficiente entre os vrios mdulos de software existem vrios fatores
a serem considerados, tais como: tempo para estabelecimento de uma
comunicao, quantidade de dados a serem transmitidos e previso de
tempo de resposta. A eficincia do sistema depende da infra-estrutura de
hardware que est disponvel para comunicao, mas tambm do soft-
ware de comunicao e do particionamento adotado para a aplicao,
que so fatores acessveis ao programador.
Os sistemas operacionais (SO) utilizam processos para organizar as vrias
tarefas que tm que gerenciar. Um processo contm todos os recursos ne-
cessrios execuo de um programa, como descritores para Entrada/Sada,
pilha de execuo, tratadores de sinais, identificadores de usurios e grupos
e controle de acesso e permisses. Cada processo carrega todo seu espao
de endereamento e estado de execuo consigo. Isto faz com que seja muito
custoso o trabalho de trocar o processo em execuo ou mover um processo de
um processador a outro. Threads so unidades de execuo mais simples e le-
ves do que processos que tambm so fornecidas pelos sistemas operacionais
modernos. Uma thread est associada a um processo e utiliza seus recursos.
Cada thread carrega sua prpria pilha de execuo, mas utiliza memria que
faz parte de uma regio compartilhada do espao de endereamento do pro-
cesso. Isso faz com que seja muito mais simples para o SO mover e efetuar
trocas de contexto entre threads.
Com o surgimento dos novos sistemas multicore, tornaram-se muito co-
muns arquiteturas que utilizam sistemas de memria compartilhadas entre v-
rios processadores. A unidade de execuo natural para programao nesse
tipo de sistema a thread, pois nesse tipo de arquitetura o programador con-
segue expressar a concorrncia de uma aplicao dividindo os algoritmos em
mltiplas threads associadas a um nico processo. O espao compartilhado de
memria faz com que trocas de dados e sincronizao entre as threads sejam
mais facilmente implementadas.
Alm dos problemas de projeto de um algoritmo paralelo para que atinja
o desempenho esperado, garantir a corretude de um programa paralelo pode
ser uma tarefa complicada. O fato de threads compartilharem um espao de
memria facilita a implementao dos programas, mas pode fazer com que
os dados sejam compartilhados de maneira indesejada. O programador deve
sempre ficar atento quando for necessria alguma sincronizao entre threads.
Por exemplo, isso ocorre quando uma thread produz um dado que outra preci-
sar processar ou quando duas threads precisam acessar a mesma posio de
memria e isso possa ocorrer simultaneamente. Dependendo da complexidade
348
da aplicao, as threads podem compartilhar dados de uma maneira que no

foi prevista pelo programador. Um erro muito difcil de ser detectado que pode
ocorrer em um programa multi-thread a chamada condio de corrida (race
condition). Essa uma situao onde o resultado do programa muda de acordo
com o escalonamento de execuo das threads, fazendo com que o programa
alterne entre execues corretas e errneas, dependendo da ordem com que
as threads foram escalonadas. O programador consegue garantir que a apli-
cao gera o resultado correto, no importando a ordem como as instrues
das vrias threads forem intercaladas, usando construes de sincronizao,
como as chamadas operaes atmicas. Por exemplo, uma thread pode fazer
uma leitura e escrita atmicas em uma posio de memria, significando que
nenhuma outra thread ter acesso quela mesma posio antes do trmino da
operao.
7.3.1. Alternativas de Implementao para Programao Multi-

thread
Uma vez projetado o algoritmo paralelo para a aplicao, o programador
precisa tomar uma deciso importante: como traduzir esse algoritmo para um
programa paralelo? A resposta utilizar alguma interface de programao
(API) ou biblioteca que permita expressar a concorrncia em seu programa-
fonte.
Existem bibliotecas de programao multi-thread para vrios sistemas ope-
racionais modernos como a pthreads [Stevens 1999], no ambiente Unix, e a
Windows threads. Basicamente, o cdigo que contm o processamento a ser
executado em uma thread deve ser colocado dentro de uma sub-rotina. Em
algum momento do programa essa sub-rotina passada para a funo de bi-
blioteca responsvel pela criao da thread, e a execuo divida a partir
desse ponto. Essas bibliotecas deixam muitos dos detalhes de gerenciamento
das threads a cargo do programador, o que exige um esforo de codificao e
est sujeito a erros. Em contrapartida, esse controle dos detalhes pode ser til
para atingir uma vantagem para o ajuste de seu programa a caractersticas do
sistema.
Uma API para programao multi-thread muito usada atualmente cha-
mada de OpenMP [Chandra et al. 2000] (http://www.openmp.org). OpenMP
suporta programao paralela utilizando memria compartilhada em C/C++ e
Fortran, tanto em ambiente UNIX quanto em Windows. Essa API um conjunto
de diretivas de compilao e uma biblioteca de rotinas para tempo de execuo
para possibilitar a programao multi-thread. Os programadores utilizam as di-
retivas de OpenMP tipicamente para paralelizao de laos em seus progra-
mas, apesar de tambm possuir recursos para programao multi-thread mais
geral. Laos normalmente representam os pontos de maior gasto de tempo de
execuo. Basicamente, essas diretivas instruem o compilador a paralelizar as
iteraes desses laos.
A principal vantagem de OpenMP em relao s bibliotecas explcitas de
349
suporte a threads a sua simplicidade. O programador precisa utilizar um con-

junto pequeno de diretivas que so includas no programa-fonte, geralmente
se ocasionar mudanas semnticas. Essa API tambm possibilita que o pro-
gramador converta gradativamente programas seqenciais em paralelos, tra-
balhando em pontos separados do programa a cada etapa. A principal desvan-
tagem est em exigir suporte do compilador, fazendo com que apenas compila-
dores preparados para trabalhar com OpenMP possam ser utilizados. Isto no
acontece com as bibliotecas de suporte explcito, pois basta apenas ter acesso
interface da biblioteca, possibilitando trabalhar com uma maior quantidade de
compiladores e linguagens. A Intel disponibiliza gratuitamente em sua pgina
na Internet5 um compilador habilitado a trabalhar com OpenMP.
7.4. Modelagem de Processadores

O surgimento de um grande nmero de arquiteturas especializadas leva a
uma grande quantidade de alternativas de projeto para um sistema multiproces-
sado, seja ele heterogneo ou no. Esse fator torna evidente a necessidade
de modelos flexveis para simulao do sistema, onde alguns dos principais
mdulos so os simuladores dos processadores.
Dado esse contexto, simuladores de conjunto de instrues (ISS) se tor-
naram parte integrante do conjunto de ferramentas utilizado atualmente du-
rante o processo de desenvolvimento. Essa grande variedade de arquiteturas
que vem surgindo nos ltimos anos tornou a capacidade de redirecionamento
uma caracterstica essencial em uma ferramenta de simulao de processa-
dores. Simuladores so utilizados na fase de explorao da nova arquitetura
para avaliar decises de projeto como tambm para validao do software e de
compiladores.
Alguns simuladores de processadores
como Shade [Cmelik and Keppel 1994], Fast-
Sim [Eric Schnarr and James Larus 1998] e Em-
bra [Witchel and Rosenblum 1996] se baseiam em uma traduo binria
dinmica associada a uma cache de resultados para melhorar o desempenho
de simulao. Outro ambiente de simulao popular o chamado SimpleSca-
lar [Burger et al. 1996], que capaz de emular os conjuntos de instrues de
algumas arquiteturas, como PISA (um conjunto de instrues RISC baseado
no MIPS), Alpha e ARM. Esses so simuladores baseados no conjunto de
instrues de arquiteturas bem conhecidas no mercado e que atingem um bom
desempenho, porm, fixam as possibilidades de arquiteturas-alvo, portanto,
no so facilmente redirecionveis. Isto faz com que esses simuladores no
sejam apropriados para explorao de novas arquiteturas.
Linguagens de Descrio de Arquiteturas (ADL) foram introduzidas para
ajudar os projetistas a vencer esses desafios. Isto fez com que ADLs tenham
atrado um grande interesse nos ltimos anos, tanto na academia quanto na
5 http://www.intel.com/cd/software/products/asmo-na/eng/compilers/219771.htm
350
indstria. Hoje em dia, ADLs so utilizadas para gerao de simuladores de

conjunto de instrues e microarquitetura, montadores, ligadores, compilado-
res, e at mesmo para sntese de implementao de circuitos em linguagens
como VHDL. Essa grande diversidade de aplicaes faz com que surjam os
mais diversos requisitos de sintaxe e semntica em tais linguagens. Para a
maioria dos projetistas de ADLs, os fatores mais importantes so a flexibilidade
e a analisabilidade. Flexibilidade a capacidade de uma linguagem descrever
precisamente uma grande variedade de arquiteturas de processadores, como
RISC, CISC, superescalares, etc. Esta uma caracterstica importante para
propiciar ao usurio alternativas de explorao de espao de projeto. Ana-
lisabilidade a capacidade de extrao de informaes da descrio de um
processador, no nvel de abstrao adequado, para que propriedades de alto
nvel da arquitetura sejam possveis de ser analisadas. Esta uma caracters-
tica importante para ADLs que visam a gerao de compiladores, por exemplo.
O ponto importante a ser destacado aqui que esses dois fatores so muitas
vezes conflitantes, pois uma maior analisabilidade pode exigir uma semntica
de um nvel de abstrao bastante alto, enquanto a flexibilidade normalmente
melhor com uma semntica de mais baixo nvel, que contenha mais deta-
lhes da microarquitetura. O correto balanceamento desses dois aspectos um
grande desafio aos projetistas de ADLs.
Existem classificaes de ADLs que visam um melhor entendimento da
flexibilidade e analisabilidade de cada uma. Um tipo de classificao que en-
contramos na literatura a diviso de ADLs em trs classes:
1. ADLs baseadas em comportamento: So linguagens que se baseiam
somente na descrio dos comportamentos relativos ao conjunto de ins-
trues de um processador para obteno de informaes sobre a arqui-
tetura, visando gerar ferramentas de software automaticamente. Devido
ao nvel de abstrao extremamente alto, linguagens dessa classe ten-
dem a ter deficincias em descries com preciso de ciclos de arquite-
turas complexas.
2. ADLs baseadas em estrutura: So linguagens que se baseiam em
informaes de mais baixo nvel sobre o hardware do processador, po-
dendo conter diagramas de blocos ou net-lists no nvel de transferncia
de registradores (RTL).
3. ADLs hbridas: So linguagens que se baseiam, tanto em informaes
sobre o conjunto de instrues, como em informaes sobre a estrutura
interna do processador, normalmente fornecidas em nvel de abstrao
mais alto do que em linguagens exclusivamente baseadas em estruturas.
nML [Fauth et al. 1995, Fauth and Knoll 1993, Freericks 1993] uma ADL
que foi desenvolvida baseada na informao que est tipicamente disponvel
no manual do programador de um processador, que consiste de uma lista de
instrues e suas respectivas operaes de transferncias entre registradores,
codificao binria e sintaxe assembly. nML foi criada na Technical University
351
of Berlim (TUB). Utilizando nML, um grupo dessa universidade projetou um si-

mulador de conjunto de instrues chamado SIGH/SIM [Lohr et al. 1993] e um
gerador de cdigo chamado CBC [Fauth and Knoll 1993]. Independentemente,
pesquisadores do IMEC (Interuniversity MicroElectronics Center) desenvolve-
ram um simulador chamado CHECKERS e um gerador de cdigo denominado
CHESS [Lanneer et al. 1995]. Hoje, ambos so produtos da companhia TAR-
GET Compiler Technologies (http://www.retarget.com).
A linguagem ISDL (Instruction Set Description Language for Retargetability)
foi desenvolvida no MIT (Massachussets Institute of Technology). Hadjiyiannis
et al [Hadjiyiannis et al. 1997] introduziram essa linguagem juntamente com um
gerador automtico de montadores. ISDL foi projetada como uma linguagem de
descrio de arquiteturas voltada para redirecionamento automtico de compi-
ladores, visando possibilitar a descrio de vrios tipos de arquiteturas, em-
bora seja especialmente voltada a arquiteturas VLIW. ISDL uma linguagem
comportamental que utiliza uma abordagem sinttica muito similar nML. A
maneira como so tratadas restries a principal diferena entre nML e ISDL.
Em ISDL possvel descrever combinaes invlidas de instrues, o que pre-
cisa ser contornado via regras adicionais na gramtica em nML. nML e ISDL
so exemplos de linguagens pertencentes primeira classe, sendo baseadas
no conjunto de instrues de uma arquitetura. Suas sintaxes so baseadas em
gramticas com atributos. No caso geral, esse no um estilo de sintaxe intui-
tivo para projetistas de hardware, alm de poder acarretar algumas restries
nas descries de comportamentos. Por exemplo, em [Hartoog et al. 1997] os
autores apontam como dois pontos desfavorveis na linguagem nML os fatos
de no oferecer flexibilidade, como declarao de variveis locais, na descrio
dos comportamentos e de possuir um contador de programa implcito, dificul-
tando a modelagem de instrues de tamanho varivel. Restrio similar se
aplica ISDL, uma vez que no capaz de descrever instrues multi-ciclo de
tamanho varivel [Hadjiyiannis and Devadas 2002].
Linguagens baseadas na estrutura do processador no so adequadas
para projetos em nvel de sistema e explorao de arquiteturas, pois suas des-
cries acabam sendo em um nvel de abstrao demasiadamente baixo para
extrao de informaes sobre o conjunto de instrues. Um vantagem de lin-
guagens dessa classe, como MIMOLA [Bashford et al. 1994], a aplicao de
seus modelos em ferramentas de sntese, dada a proximidade com linguagens
de descrio de hardware.
Seguindo a classificao apresentada acima, a maioria das linguagens
existentes hoje se enquadra na terceira classe, linguagens hbridas, contendo
informaes tanto de estrutura como do conjunto de instrues. Entre essas
linguagens encontram-se EXPRESSION, LISA e ArchC.
EXPRESSION [Halambi et al. 1999] uma ADL voltada para explorao
de arquiteturas para SoCs e gerao automtica de um conjunto de ferramen-
tas com simulador e compilador. EXPRESSION suporta a especificao de
sistemas de memrias, sendo essa o seu principal diferencial em relao s
352
outras linguagens j citadas na poca de sua criao. Os autores justificam

o investimento nessa caracterstica com o argumento de que SoCs permi-
tem a introduo de novas organizaes de memria no sistema. Grun et
al [Grun et al. 1999] introduziram um algoritmo para extrair as informaes ne-
cessrias construo de tabelas de reserva a partir de descries de arquite-
turas feitas em EXPRESSION. Esse um recurso importante para possibilitar a
gerao automtica do compilador [Halambi et al. 1999]. Como destacado em
[Qin and Malik 2005], a primeira verso de EXPRESSION continha um meca-
nismo implcito de descrio de mecanismos de pipeline, como stall e flush, o
que limita a flexibilidade da linguagem. Mishra et al [Mishra et al. 2001] apre-
sentaram uma metodologia de projeto baseada em abstrao funcional, que
visa dar a EXPRESSION mecanismos para uma modelagem mais explcita do
controle do pipeline.
Vojin Zivojnovic et al [Zivojnovic et al. 1996a, Zivojnovic et al. 1996b] intro-
duziram a linguagem LISA. Em um primeiro momento, LISA foi desenvolvida
para permitir a gerao automtica de simuladores rpidos, utilizando a tcnica
de simulao compilada, e com preciso de bit e de ciclos. Quando introdu-
zida, a principal contribuio de LISA foi a sua descrio do pipeline em nvel
de operao e modelo de seqenciamento. Essa primeira verso da lingua-
gem no era apropriada para gerao de geradores de cdigo e montadores.
Para modelar um seqenciador de operaes, LISA seguiu as idias bsicas de
tabelas de reserva e Gantt charts [Zivojnovic et al. 1996a], estendendo Gantt
charts para permitir a modelagem de hazards de dados e controle e flushes
de pipeline. A unidade de funcionalidade em LISA so as chamadas opera-
es, que podem ser entendidas como o comportamento de uma instruo
dentro de um estgio de pipeline. Nos simuladores com preciso de ciclos ge-
rados por LISA, podemos considerar cada estgio de pipeline como um buffer
de operaes, que preenchido medida que as instrues so decodifica-
das e decompostas. Esse modelo est limitado modelagem de execuo em
ordem.
LISA foi inicialmente proposta na Aachen University of Technology, na Ale-
manha. O desenvolvimento de extenses e ferramentas para a linguagem LISA
esteve inicialmente ligado s empresas AXYS (http://www.axysdesign.com) e
LISATek, que foi adquirida pela CoWare (http://www.coware.com), a proprie-
tria do maior nmero de ferramentas baseadas em LISA atualmente. Esse
investimento gerou vrias extenses ao conjunto de ferramentas nos ltimos
anos. Hoffmann et al [Hoffmann et al. 2001] utilizaram a linguagem LISA para
criar um framework para co-simulao hardware/software. No lado de soft-
ware, modelos descritos em LISA so aplicados na criao de um conjunto
de ferramentas, como os descritos acima, composto de simulador, montador,
compilador e uma interface de co-simulao. No lado de hardware, modelos
em SystemC RTL so conectados a simuladores externos utilizando-se a inter-
face de simulao, com o objetivo de propiciar a co-simulao de modelos em
nveis de abstrao diferentes.
353
Braun et al [Braun et al. 2003] apresentaram uma extenso lingua-

gem LISA para a simulao de hierarquias de memrias em conjunto
com modelos de processadores escritos nessa linguagem, e Hohenauer
et al [Hohenauer et al. 2004] introduziram uma metodologia semi-automtica
para gerao de back-end de compiladores a partir de modelos em LISA.
Na verdade, os autores utilizaram a ferramenta CoSy, da companhia ACE
(http://www.ace.nl), para gerar o compilador C. Essa uma ferramenta especia-
lizada para a gerao de compiladores a partir de uma descrio de processa-
dor em um formato prprio, chamado Compiler Generator Description (CGD),
especializado para compiladores e muito diferente de uma ADL. Os autores cri-
aram uma ferramenta para extrair informaes de modelos em LISA para gerar
uma descrio no formato CGD, sendo que os dados que no podem ser en-
contrados no modelo precisam ser preenchidos pelo usurio manualmente na
descrio CGD.
Wieferink et al [Wieferink et al. 2004] propem um fluxo de projeto top-down
baseado nos modelos de processadores da ADL LISA, utilizando as ferramen-
tas CoWare/LISATek. Mesmo sem o suporte direto da ADL, o grupo conseguiu
com sucesso uma integrao com o TLM do SystemC, fazendo-se necess-
ria uma codificao intensiva para tal. Os resultados mostram uma acentuada
queda quanto ao desempenho de simulao quando comparados com a simu-
lao do processador isolado, justificado pela adio do cdigo de comunica-
o externa.
A linguagem RADL [Siska 1998] voltada para simuladores com preciso
de ciclos e suporta explicitamente mltiplos pipelines, incluindo delay slots, in-
terrupes, laos em hardware e hazards de dados. RADL foi desenvolvida
na Rockwell Inc. com base em uma verso preliminar de LISA, sendo que ne-
nhum resultado sobre modelos de processadores reais elaborados com essa
linguagem foi publicado.
ArchC [Azevedo et al. 2005, Rigo et al. 2004, Team 2004] uma lingua-
gem de descrio de arquiteturas que usa, tanto informaes estruturais,
quanto do conjunto de instrues para gerao automtica de ferramentas de
software; para permitir aos usurios explorar e verificar uma nova arquitetura.
ArchC foi inicialmente desenvolvida no Instituto de Computao da UNICAMP,
porm, o grupo de desenvolvedores atual conta com colaboradores na Univer-
sidade Federal de Pernambuco e na Universidade Federal de Santa Catarina.
Ferramentas de software e modelos de processadores em ArchC esto publi-
cados em domnio pblico e podem ser obtidos na Internet (www.archc.org).
ArchC tambm uma linguagem hbrida. Sua sintaxe totalmente ba-
seada nas sintaxes de SystemC e C++. Ela foi projetada visando usurios
de SystemC, isto , visando fazer com que esses usurios no tivessem que
aprender uma sintaxe diferente da que eles j esto acostumados a utilizar. O
usurio tem apenas que se acostumar a um conjunto de palavras-chave, po-
rm, a maior parte de uma descrio de processador em ArchC consiste em
cdigo C++. Dentre as linguagens mencionadas acima, a nica que chega a
354
permitir uma sintaxe semelhante C++ em alguns aspectos LISA.

As descries de comportamentos em ArchC so divididas por instruo,
isto , existe um mtodo de comportamento para cada instruo. Este m-
todo pode estar descrito em diferentes nveis de abstrao, podendo conter um
comportamento mono-ciclo (como em modelos funcionais), multi-ciclo ou ainda
dividido em estgios de pipeline. Como os comportamentos so descritos em
um arquivo que puramente C++, o usurio tem a flexibilidade de poder usar
qualquer cdigo C++ vlido na sua descrio de comportamentos, inclusive
podendo adicionar funes auxiliares, ligar um conjunto prprio de classes que
deseje reaproveitar ou usar qualquer tipo de dado ou mtodo fornecido por Sys-
temC. Essa possibilidade de incluso de cdigo SystemC, aparece pois ArchC
gera simuladores descritos em SystemC.
A partir de modelos de processadores em ArchC possvel a gerao de
simuladores interpretados e compilados [Azevedo et al. 2005, Rigo et al. 2004,
Bartholomeu et al. 2004], montadores [Baldassin et al. 2005] e ligadores, inter-
faces entre os simuladores e o depurador GDB, interfaces de comunicao en-
tre os simuladores e mdulos de hardware escritos em SystemC e a descrio
de hierarquias de memria [Viana et al. 2004] e bibliotecas de emulao de
chamadas de sistema operacional.
Uma desvantagem desse sistema de classificao para as ADLs que mui-
tas linguagens so enquadradas na categoria de hbridas, tornando difcil uma
clara diferenciao entre a maioria das linguagens existentes. Uma classifica-
o alternativa para ADLs seria com relao ao modelo de computao ado-
tado por cada uma. Essa classificao foi recentemente proposta pelos autores
da linguagem MADL (Mescal Architecture Description Language) [Qin 2004]. O
diferencial dessa linguagem est exatamente no modelo de computao ado-
tado, que os autores definiram em uma tentativa de alcanar um bom compro-
misso entre flexibilidade e analisabilidade, e trazer uma fundamentao terica
para ADLs. Os modelos de computao definidos para essa nova classificao
para as linguagens mencionadas acima so:
Modelo de Eventos Discretos: Este o modelo padro para modelagem
de circuitos digitais, tendo sido usado na linguagem estrutural MI-
MOLA [Bashford et al. 1994].
Modelos de Domnio Especfico: Nesta classe se encaixam as ADLs que
centralizam a descrio do processador na especificao do compor-
tamento das instrues, isto , abstraem estgios de pipeline de ma-
neira que estes se tornam apenas entidades de armazenamento pelas
quais passam as instrues. A descrio das operaes realizadas em
cada estgio est diluda dentro da especificao dos comportamentos
de instrues. Essas caractersticas englobam a maioria das linguagens
hbridas, como LISA, ArchC e RADL. Como vimos anteriormente, o mo-
delo de execuo de LISA baseado em operaes e em Gantt-Charts.
RADL idntica a LISA nesse aspecto. ArchC, devido ao fato dos com-
portamentos de instruo serem descritos em C++/SystemC, tem a flexi-
355
bilidade de incorporar funcionalidades oferecidas por SystemC. Por ou-

tro lado, ArchC tambm concentra a descrio das funcionalidades do
processador nos comportamentos de instruo. Como SystemC base-
ada no modelo de eventos discretos, podemos considerar o modelo de
computao de ArchC como uma combinao desse modelo com Gantt-
Charts.
Modelo de Mquina de Estados de Operao (OSM): Esse modelo foi de-
senvolvido por pesquisadores da Universidade de Princeton no es-
foro de desenvolver fundamentos tericos para ADLs. O modelo
OSM [Qin and Malik 2003] foi utilizado no desenvolvimento da linguagem
MADL, cujo objetivo dar suporte gerao automtica de simuladores
e compiladores. Esse modelo observa o processador em dois nveis,
o de operao e o de hardware. O primeiro contm o conjunto de ins-
trues e o comportamento de execuo das operaes. O segundo
representa simplificadamente a microarquitetura. Um modelo de pro-
cessador que baseado em OSM usa uma mquina de estados finitos
estendida (EFSM) para modelar a execuo das operaes. Cada EFSM
representa uma operao, da o nome OSM (Operation State Machine),
onde seus estados so os possveis estados de execuo da operao
e as arestas indicam passos vlidos na execuo. A linguagem MADL
somente utiliza o nvel de operao do modelo OSM [Qin 2004].
O objetivo neste captulo a construo de modelos para a simulao de
plataformas multiprocessadas usando SystemC. As duas ADLs que mostraram
algum desenvolvimento nesse sentido at o momento foram LISA e ArchC. Por
ser totalmente baseada em ferramentas de domnio pblico, e por ter incorpo-
rado facilidades de comunicao com mdulos externos de hardware escritos
em SystemC, ArchC ser a ADL escolhida para como base para os exemplos
no decorrer desse texto.
7.4.1. A Linguagem ArchC

Uma descrio de processador em ArchC dividida em duas partes: a
descrio do conjunto de instrues (AC_ISA) e a descrio dos recursos da
arquitetura (AC_ARCH). Na descrio AC_ISA, o projetista fornece os detalhes
sobre formatos, tamanhos e nomes de instrues combinados com toda a in-
formao necessria para a decodificao e o comportamento das instrues.
A descrio AC_ARCH informa a ArchC quais so os dispositivos de armazena-
mento, estrutura de pipeline e alguns outros detalhes da estrutura da arquite-
tura. Baseando-se nessas duas descries, so gerados simuladores interpre-
tados, escritos em SystemC, simuladores compilados, escritos em C++, alm
de montadores e ligadores redirecionados para a arquitetura descrita.
Uma descrio de processador pode ser iniciada em dois nveis de abstra-
o: funcional ou com preciso de ciclos. Uma descrio funcional no leva
em conta detalhes estruturais do processador e temporizao, como pipeline
e instrues multiciclo, consistindo basicamente em uma descrio de alto n-
356
vel do conjunto de instrues, que pode ser instrumentada com interfaces de

comunicao, depurao e hierarquia de memria, se assim desejado. Uma
descrio com preciso de ciclos envolve detalhes de estrutura do processa-
dor, como, por exemplo, declarao de um pipeline incluindo seus estgios e
registradores. Desta forma, o comportamento das instrues tambm deve ser
codificado de maneira bem mais detalhada, para refletir uma eventual diviso
das operaes em estgios de pipeline ou multi-ciclos. aconselhvel que os
usurios iniciem o projeto de uma arquitetura em ArchC atravs de um mo-
delo funcional e, posteriormente, se necessrio, desenvolvam o modelo com
preciso de ciclos.
Um modelo funcional capaz de executar todo o conjunto de instrues de
uma dada arquitetura, portanto, consegue rodar qualquer aplicao compilada
para a mesma, executando todo o comportamento de uma instruo em um
nico ciclo. Mesmo quando um modelo mais detalhado, possivelmente com
preciso de ciclos, necessrio ao projeto, a experincia e o conhecimento
sobre o conjunto de instrues adquiridos pelo projetista durante a elabora-
o de um modelo funcional so muito importantes para que ele seja capaz
de desenvolver o modelo mais refinado mais rapidamente. Alm disso, erros
de modelagem geralmente so mais fceis de ser identificados e corrigidos
no modelo de mais alto nvel (funcional). Um modelo funcional bem verificado
evita que muitos desses erros sejam propagados para o modelo de mais baixo
nvel, onde sua depurao pode ser bem mais complexa. Nesta seo apre-
sentamos uma introduo modelagem de processadores usando ArchC, utili-
zando como exemplo modelos funcionais. Para detalhes sobre descries com
preciso de ciclos o leitor pode se referir ao manual de referncia da lingua-
gem [Team 2004].
7.4.1.1. Descrevendo os Recursos do Processador
ArchC necessita de informaes estruturais sobre os recursos disponveis

na arquitetura para que possa gerar, automaticamente, as ferramentas de soft-
ware. Em ArchC, o projetista fornece tais informaes atravs da descrio
chamada AC_ARCH.
Uma descrio de arquitetura no nvel funcional requer uma descrio de
comportamento de instrues razoavelmente simples, como ser mostrado na
Seo 7.4.1.2, e tambm no necessita de muitos detalhes estruturais da ar-
quitetura, como mostra o exemplo da Figura 7.6. Este exemplo ilustra o mnimo
de informao estrutural necessria para se construir um modelo da arquite-
tura MIPS em ArchC, que consiste em declarar uma memria para dados e
programa, um banco de 32 registradores e dois registradores especiais cha-
mados HI e LOW. Esses dois ltimos registradores so utilizados pela arqui-
tetura MIPS [Kane and Heinrich 1992] para a realizao de operaes de mul-
tiplicao e diviso. Uma descrio AC_ARCH para um modelo funcional da
arquitetura SPARC [SPARC 1992] tambm conta com apenas esses elemen-
357
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 };
Figura 7.6. MIPS funcional: Declarao de memria e de

banco de registradores
tos bsicos de estrutura, como visto na Figura 7.7. A seguir so mostrados os

detalhes da sintaxe de cada uma dessas declaraes:
AC_ARCH: Uma descrio dos recursos da arquitetura sempre comea com
essa palavra-chave, como na primeira linha da Figura 7.6. O projetista
deve informar, entre parnteses, um nome para o projeto, assim como
feito para declaraes de mdulos em SystemC.
ac_wordsize: Declara o tamanho da palavra da arquitetura.
ac_mem: Declara uma memria. Esta palavra-chave sempre seguida do
nome do dispositivo, dois pontos e o tamanho da memria. O tamanho
pode ser expresso em bytes (nenhuma unidade precisa ser declarada),
em kilobytes (K ou k), em megabytes (M or m), ou ainda em gigabytes
(G or g). Na Figura 7.6, uma memria de 256 kilobytes declarada.
ac_regbank: Declara um banco de registradores. sempre seguida do nome
do objeto, dois pontos e a quantidade de registradores disponveis no
mesmo. Nos exemplos, um banco de 32 registradores declarado.
ac_reg [<fmt>]: Declara um registrador. sempre seguida pelo nome do re-
gistrador. possvel associar-se um formato a um registrador, dividindo-
o em campos. Esta associao feita atravs do argumento fmt e
seguindo-se uma sintaxe similar de templates da linguagem C++. Se
nenhum formato for associado, o registrador ter o mesmo tamanho da
palavra da arquitetura.
ARCH_CTOR: Inicia a declarao do construtor de AC_ARCH.
ac_isa: Informa o nome do arquivo que contm a declarao AC_ISA a ser
usada para compor o modelo.
set_endian: Configura o endianness da arquitetura. Pode receber os valo-
res big ou little. Tanto MIPS quanto SPARC so declarados como big
endian.
358
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 " ) ;
12 };
13 };
Figura 7.7. SPARC funcional: Declarao de registradores
7.4.1.2. Especificando o Conjunto de Instrues
A descrio AC_ISA fornece ArchC toda a informao necessria para

a gerao automtica de um decodificador, um montador, um ligador, assim
como o comportamento de cada instruo na arquitetura. Essa descrio
dividida em dois arquivos: um contendo as declaraes de instrues, seus
respectivos formatos e seqncia de decodificao atravs de palavras-chave
de linguagem ArchC e outro contendo o comportamento das instrues descri-
tos em C++/SystemC.
A Figura 7.8 mostra um exemplo de uma descrio AC_ISA extrado do
modelo MIPS. A arquitetura MIPS do tipo RISC, onde no existem muitos
formatos diferentes para as instrues e todas so do mesmo tamanho. En-
tretanto, em arquiteturas mais complexas como CISC, DSPs e VLIW, o mesmo
pode no ocorrer. Baseado neste exemplo, vejamos algumas das palavras-
chaves de ArchC que podem aparecer numa descrio AC_ISA:
AC_ISA: Uma descrio de conjunto de instrues sempre comea por essa
palavra-chave. O projetista precisa informar o nome do projeto, en-
tre parnteses, assim como foi feito para a descrio AC_ARCH (Se-
o 7.4.1.1).
ac_format: Declara um formato e seus campos. A string atribuda ao formato
representa sua subdiviso em campos. A declarao de um campo
iniciada pelo caractere %, seguido de um identificador que se torna o
nome do campo. O nmero aps os dois pontos (:) indica o tamanho,
em bits, do campo. Por exemplo, a string %rs:5 declara um campo de
largura 5 bits com nome rs, como mostra a Figura 7.8.
ac_instr <fmt>: Declara uma instruo. Toda instruo deve ser associada
a um formato previamente declarado. Formatos so associados a instru-
es usando uma sintaxe similar de templates em C++. Na Figura 7.8,
o formato Type_R associado instruo add.
359
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 };
Figura 7.8. MIPS com preciso de ciclos: Declarao de

registradores formatados e pipeline
ISA_CTOR: Inicializa a declarao do construtor de AC_ISA.

set_asm: Atribui uma sintaxe assembly a uma dada instruo. As informa-
es codificadas por set_asm so geralmente dinmicas, como valores
de registradores e referncias simblicas encontradas na linguagem de
montagem. A sintaxe e semntica desse mtodo relembram muito a fun-
o scanf() da linguagem C.
set_decoder: Especifica a seqncia de decodificao de uma instruo,
que o elemento-chave para a gerao automtica de um deco-
dificador de instrues. A seqncia deve ser composta de pares
<nome_do_campo = valor>. Na Figura 7.8, observe o exemplo para
a instruo add. A chamada ao mtodo add.set_decoder determina
que uma cadeia de bits vindos da memria uma instruo add se, e
somente se, os campos op e func contiverem os valores 0x00 e 0x20,
respectivamente. Exatamente os mesmos passos so seguidos para a
instruo load. Note que load usa um formato diferente e que somente
um campo necessrio para sua decodificao.
7.4.1.3. Descrevendo os Comportamentos das Instrues
A descrio de quais operaes so executadas por quais instrues em

uma dada arquitetura fornecida em um arquivo especial em ArchC. Ao forne-
cer os dois arquivos de descrio apresentados at agora, AC_ARCH e AC_ISA,
para o gerador de simuladores ArchC (acsim), o projetista obter um modelo
360
(template) do arquivo da descrio de comportamentos. Este arquivo um

esqueleto de um arquivo fonte C++/SystemC onde o projetista preencher os
mtodos de comportamento para todas as instrues que foram declaradas na
arquitetura. Esse arquivo modelo nomeado como project_name-isa.cpp.tmpl.
A Figura 7.9 mostra o comportamento para a instruo add da arquite-
tura MIPS. O conjunto de instrues MIPS-I bastante simples, de maneira
que muitas de suas instrues podem ser descritas to facilmente quanto
apresentado nesse exemplo. importante notar que os dispositivos de arma-
zenamento declarados pelo projetista na descrio AC_ARCH so acessados
diretamente atravs de mtodos de leitura (read) e escrita (write) em descri-
es de comportamentos. Memrias so sempre endereadas a byte e esses
mtodos sempre retornam uma palavra.
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 };
Figura 7.9. MIPS: Comportamento de uma instruo
7.4.1.4. Gerao de Simuladores
O objetivo de se descrever um processador em uma ADL como ArchC

a gerao automtica de ferramentas de software para esse modelo. A Fi-
gura 7.10 mostra o fluxo natural de projeto utilizando essas ferramentas, onde
acsim e accsim so, respectivamente, geradores de simuladores interpreta-
dos e compilados, acasm o gerador de montadores e aclink o gerador de
ligadores.
A ferramenta acsim responsvel pela gerao do simuladores interpreta-
dos escritos em SystemC. O processo de gerao e compilao dos simulado-
res bastante simples. Os passos abaixo ilustram a construo do simulador
do modelo MIPS e a execuo do programa PROG1.
1 $ acsim mips . ac a b i
2 $ make f M a k e f i l e . archc
3 $ . / mips l o a d =PROG1
Os primeiros simuladores gerados automaticamente com a ajuda de ADLs

usaram uma tcnica de simulao chamada interpretada, que imita o compor-
tamento do hardware: primeiro busca bytes na memria, depois decodifica a
seqncia de bytes como uma instruo e s ento a executa. Com a cres-
cente complexidade dos sistemas, esta tcnica passou a ter um desempenho
aqum do esperado, o que fez crescer a pesquisa nesta rea para encontrar
um mtodo mais rpido de simulao.
361
Figura 7.10. Gerao de ferramentas
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.
7.5. Integrao de Componentes

Esta seo descreve uma forma de integrar componentes diversos escritos
em SystemC. Como SystemC permite que os componentes sejam modelados
em diversos nveis de abstrao, geralmente necessrio incluir mdulos cria-
362
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.
7.5.1. O Padro TLM 1.0 do SystemC

O padro OSCI TLM 1.0 [SystemC TLM Working Group 2005] tem por fina-
lidade especificar as interfaces para comunicao TLM. As principais motiva-
es relacionadas com a proposta do padro so:
Adiantar a disponibilidade de uma plataforma para desenvolvimento de
software;
Explorao do projeto como um todo;
Fornecer um modelo completo do sistema para verificao.
Os trs principais conceitos relacionados com o padro TLM so:
Interfaces: O padro d nfase nas interfaces ao invs da implementa-
o dos mtodos. Todas as interfaces definidas devem ser descendentes
da classe sc_interface. O foco nas interfaces advm do fato de Sys-
temC ser uma biblioteca de classes e C++ ser uma linguagem orientada
a objetos. Apenas aps a definio rgida das interfaces que questes
relacionadas implementao devem ser tratadas.
Bloqueantes X No-Bloqueantes: Como em SystemC existem dois
tipos bsicos de processos, SC_THREAD e SC_METHOD, e somente o
363
1 template <REQ, RSP>

2 class t l m _ t r a n s p o r t _ i f : public s c _ i n t e r f a c e
3 {
4 public :
5 v i r t u a l RSP t r a n s p o r t ( const REQ& ) = 0 ;
6 };
Figura 7.11. Interface TLM bidirecional bloqueante
SC_THREAD pode fazer uma chamada funo wait, todos os mto-

dos de todas as interfaces devem deixar claro se eles so bloqueantes
ou no. Um mtodo bloqueante definido como um mtodo que pode
chamar a funo wait, enquanto um mtodo no bloqueante um m-
todo que certamente no chama a funo wait. Isso permite que os
mtodos no-bloqueantes possam ser usados dentro de SC_THREAD e
SC_METHOD enquanto os bloqueantes s possam ser usados dentro de
SC_THREAD.
Unidirecional X Bidirecional: Do ponto de vista da transferncia de da-
dos, toda transao pode ser classificada como unidirecional (somente
envia ou somente recebe dados) ou bidirecional (envia e recebe dados).
Para essa classificao, sinais de controle que possam aparecer nas im-
plementaes de baixo nvel so desconsiderados. Transaes comple-
xas podem ser quebradas em seqncias de transaes unidirecionais
ou bidirecionais.
Com base nesses conceitos, 4 tipos diferentes de interfaces podem ser

definidas: unidirecionais bloqueantes, unidirecionais no-bloqueantes, bidire-
cionais bloqueantes e bidirecionais no-bloqueantes. Sempre que possvel,
um mdulo do sistema deve fornecer mais de uma interface, diminuindo as
restries sobre os mdulos que podem ser conectados a ele diretamente. A
Figura 7.11 contm a declarao da interface tlm_transport_if que bi-
direcional e bloqueante. Nessa interface so usados templates para fornecer
os tipos que so enviados e recebidos. Outra caracterstica importante a
padronizao do mtodo transport para a funcionalidade de transmisso e
recepo de dados.
A Figura 7.12 mostra uma possvel implementao para o mtodo
transport (fornecida por [SystemC TLM Working Group 2005]), conside-
rando que os dados so transferidos atravs de duas FIFOs unidirecionais
(request_fifo) e (response_fifo) e utilizando um mutex para controlar
a concorrncia no acesso s FIFOs.
Para evitar confuso com as nomenclaturas dos elementos modelados, o
padro TLM define os termos:
Initiator: Indica o mdulo que inicia a transao. Foi evitado o uso do termo
364
1 RSP t r a n s p o r t ( const REQ & req )

2 {
3 RSP r s p ;
4 mutex . l o c k ( ) ;
5 r e q u e s t _ f i f o . p u t ( req ) ;
6 response_fifo . get ( rsp ) ;
7 mutex . u n l o c k ( ) ;
8 return rsp ;
9 }
Figura 7.12. Uma implementao de mtodo de transporte
master para no confundir com a nomenclatura utilizada em barramen-

tos.
Target: Indica o mdulo que recebe a transao. Foi evitado o termo slave
tambm para no confundir com a nomenclatura utilizada em barramen-
tos.
Put: Indica que a transao est sendo enviada do initiator para o target. A
nomenclatura alternativa aos mtodos write e read foi criada para evi-
tar conflito com as outras implementaes de interface j existentes.
As interfaces bloqueantes possuem mtodos chamados put e as no-
bloqueantes, nb_put.
Get: Indica que a transao est sendo enviada do target para o initiator. Os
demais comentrios so similares ao item anterior.
Peek: um mtodo de uma interface que permite a inspeo do valor a ser
lido sem, no entanto, consumi-lo.
Nas prximas subsees ser visto como processadores ArchC fazem uso
do padro TLM para comunicao com outros mdulos, bem como exemplo de
outros mdulos com implementao TLM.
7.5.2. A Interface Padro AC_TLM

A verso 2.0 dos simuladores gerados por ArchC fornece a possibilidade
de adicionar-se uma TLM initiator port bidirecional para seu processador, per-
mitindo a comunicao com mdulos externos. O projetista deve declarar essa
nova porta TLM no arquivo de descrio de recursos da arquitetura (veja Se-
o 7.4.1.1). A Figura 7.13 ilustra essa declarao usando o modelo MIPS
descrito anteriormente. Note que essa porta substitui a memria declarada na
Figura 7.6, pois a memria agora ser um mdulo externo ao simulador. Para
evitar alteraes nos comportamentos das instrues, recomenda-se que uma
das portas criadas tenha o mesmo nome dado memria na descrio sem
TLM do processador.
O prximo passo executar a ferramenta acsim para gerar o simulador,
que j conter o cdigo necessrio para essa nova porta. Um fator importante
365
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 ;
5 ac_reg HI , LOW;
6
7 ARCH_CTOR( mips ) {
8 ac_isa ( " mips_isa . ac " ) ;
10 };
11 };
Figura 7.13. MIPS: Declarao de uma porta TLM para

comunicao externa
a se notar nesse caso que o antigo indicador de tamanho da memria (5M no

exemplo) agora indica a faixa de endereos que estaro acessveis para essa
porta, a partir do zero (0x0).
O acesso a essa nova porta na descrio de comportamentos de instru-
es feito da mesma maneira que o acesso a elementos de armazenamento
comuns, atravs de mtodos de read e write6 , como mostra o mtodo de
comportamento da instruo lw (load word) na Figura 7.14.
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 };
Figura 7.14. MIPS: Comportamento da instruo lw
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

2 # i n c l u d e " mips . h "
3 # i n c l u d e " memory . h "
4
5 i n t sc_main ( i n t argc , char argv [ ] ) {
6 ...
7 mips MIPS ( " MIPS " ) ;
8 memory ext_memory ( "MEM" ) ;
9 MIPS . DM_port ( ext_memory ) ;
10 ...
11 sc_start ( ) ; / / i n i c i a a execucao
12 return 0 ;
13 }
Figura 7.15. Exemplo de SystemC: Arquivo principal que

interliga os dois mdulos
tista (ext_memory). Enquanto os acessos internos ao processador so feitos

atravs do nome DM, os acessos externos so feitos atravs da porta TLM
DM_port, que criada automaticamente pelo acsim durante a gerao do si-
mulador (o mapeamento da porta feito na linha 11 da figura). Observe, na
linha 2 da figura, que apenas utilizada uma diretiva #include para permitir o
uso do simulador gerado por ArchC, que pode ser instanciado como qualquer
outro mdulo SystemC (veja linha 8). Instanciar um sistema multiprocessado
passa, ento, a ser to simples quanto instanciar vrios objetos de uma mesma
classe, ou de classes diferentes se for desejado um sistema multiprocessado
heterogneo.
Falta agora verificar como deve ser a implementao desse mdulo externo
para que essa comunicao seja possvel. O projetista precisa seguir um pro-
tocolo baseado no padro TLM de SystemC que foi chamado de ArchC TLM
protocol. O protocolo pode ser resumido como: uma ac_tlm_port estende
uma sc_port<ac_tlm_transport_if>, onde ac_tlm_transport_if
o mesmo que tlm_transport_if<ac_tlm_req, ac_tlm_rsp>.
Basicamente, isso significa que o projetista somente pode conectar uma
ac_tlm_port a um mdulo que estenda a ac_tlm_transport_if, que tec-
nicamente um canal, ou a uma sc_export<ac_tlm_transport_if> que
seja pertencente a um objeto desse tipo. Ento, o primeiro requisito que o m-
dulo externo, responsvel pela comunicao com o processador, deve herdar
a classe ac_tlm_transport_if. Nesse exemplo, isso obrigaria o mdulo
ext_memory a implementar o mtodo:
1 a c _ t l m _ r s p Memory : : t r a n s p o r t ( const ac_tlm_req & req ) ;
Esse mtodo declarado pela tlm_transport_if<> e recebe uma refe-

rncia a um ArchC TLM transaction request packet, que o tipo usado para os
pacotes de comunicao pelo protocolo de ArchC para requisies, faz o seu
367
processamento e retorna um ArchC TLM transaction response packet, um pa-

cote de resposta informando o requisitante do status da transao, indicando
se houve uma falha ou sucesso.
Fazendo isso no mdulo externo, que seria o escravo no protocolo de comu-
nicao, o projetista est pronto para acessar seu mdulo da maneira descrita
acima, seja dentro dos comportamentos das instrues ou fora do simulador.
Outro tipo de porta disponvel a de Interrupo Externa. Com ela, os si-
muladores gerados por ArchC podem ser interrompidos por um dispositivo (ou
vrios) e tomar as devidas providncias. O processo parecido com o proto-
colo descrito acima, mas usa um tipo de porta diferente: ac_tlm_intr_port.
A declarao ocorre da mesma maneira que com o tipo ac_tlm_port. O
exemplo do MIPS com uma porta de interrupo, chamada inta, fica como na
Figura 7.16.
1 AC_ARCH( mips ) {
2 ac_mem DM: 5M;
3 ac_wordsize 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 };
Figura 7.16. MIPS: Declarao de uma porta TLM para

interrupo externa
Desta maneira, a ferramenta acsim criar um conjunto extra de arquivos

nos arquivos-fontes do simulador gerado. Um deles ser editado pelo projetista
para a incluso do cdigo do tratador de interrupes. Esse arquivo chamado
de modelname_intr_handlers.cpp. O comportamento do tratador de uma
interrupo codificado de maneira idntica ao comportamento de instrues,
atravs de um mtodo C++ que descreve as operaes necessrias, conforme
Figura 7.17.
1 / / Comportamento a s e r executado no caso de uma

2 / / interrupcao inta
3 void ac_behavior ( i n t a , v a l u e ) {
4 / / I n s i r a o codigo a q u i ! ! !
5 }
Figura 7.17. Comportamento do tratador de interrupes
Dentro desse mtodo, o projetista tem liberdade para alterar contedo de

registradores, memria, contador de programa, etc. Esse cdigo deve descre-
368
ver as operaes que so realizadas pelo hardware quando uma interrupo

recebida. Note que esse mtodo recebe um valor como parmetro que pode
ser usado na codificao do tratamento. Outra possibilidade a declarao
de mais de uma ac_tlm_intr_port em uma descrio, o que faria com que
cada um tivesse seu prprio mtodo de tratamento.
Tudo o que o projetista tem que fazer para que seu mdulo externo consiga
interromper o processador conectar uma porta de sada de seu mdulo
porta de interrupo. Algo como a linha abaixo no arquivo principal de seu
projeto:
1 ext_module . o u t _ p o r t ( MIPS . i n t a ) ;
Note que a porta de interrupo usada pelo nome declarado na des-

crio do processador. Essa porta de sada do mdulo externo deve ser
do tipo sc_port<ac_tlm_transport_if>. Essa porta ter um mtodo
chamado transport(), que ser chamado passando-se um pacote do tipo
ac_tlm_req quando uma interrupo precisar ser gerada. O valor contido no
campo de dado desse pacote ser o valor que chegar como argumento na
chamada do tratador de interrupo.
7.5.3. Exemplo de um Mdulo Compatvel com AC_TLM

Nesta seo ser analisado um exemplo completo de um mdulo de me-
mria que pode ser conectado diretamente a um simulador de processador
gerado por ArchC 2.0. Escrever dispositivos que falam este protocolo bem
simples, dado que a maior parte do trabalho feita pela interface de transporte
TLM do SystemC.
Como visto anteriormente, existem alguma exigncias a serem satisfeitas
para que o protocolo de comunicao TLM possa ser utilizado. A Figura 7.18
mostra o arquivo de definio desse mdulo (o arquivo .h). A memria bas-
tante simples, basicamente um vetor de bytes alocado dinamicamente com o
tamanho declarado no momento da instanciao. Para operar o vetor, a me-
mria usa duas rotinas, readm e writem, ambas publicadas pela classe.
Para implementar a interface de comunicao deve-se incluir uma porta.
Nesse caso foi escolhida uma sc_export para poder lig-la diretamente
porta do processador (sem barramentos ou canais). Independentemente do
tipo de porta escolhido, esta dever utilizar a interface fornecida pelo ArchC
2.0, chamada de ac_tlm_transport_if.
Pontos importantes a serem observados:
Note a incluso da clusula using na linha 4, para poder utilizar o tipo
de dados da interface TLM do SystemC no mdulo sendo definido;
A definio da classe shr_mem herdando as classes sc_module e
ac_tlm_transport_if;
A implementao do mtodo de transporte, obrigatrio segundo o pa-
dro TLM do SystemC. Ele se encarrega de executar o mtodo corres-
pondente a uma leitura ou escrita de acordo com a informao que chega
369
no pacote TLM. No final, ele retorna o pacote de resposta com o status

da transao.
A Figura 7.19 mostra o arquivo de implementao desse mdulo de mem-
ria (o arquivo .cpp). Nesse arquivo pode-se ver a implementao dos mtodos
readm e writem, que realizam a leitura ou escrita e retornam um cdigo de
status da transao.
A Figura 7.20 o arquivo principal desse sistema composto por um proces-
sador MIPS1 e uma memria externa. Cabe destacar:
Instanciao dos dois mdulos (linhas 4 e 5);
Opo para armazenamento de um trace de simulao por parte do pro-
cessador. O trace consiste em uma lista de todos os endereos das
instrues executadas pelo simulador;
Conexo entre o simulador e a memria atravs das portas TLM (linha
12);
Inicializao do simulador. Padro em ArchC (linha 15);
Controle de incio de simulao (linha 18);
Impresso de estatsticas no final (linha 20).
Finalmente, o modelo de simulao do sistema est completo e usando o
padro TLM de ArchC para a conexo dos dois mdulos.
7.6. Colocando tudo junto: Exemplo passo-a-passo

Esta seo agrupa todos os conceitos descritos anteriormente num nico
exemplo de um sistema multicore. Todo o cdigo-fonte necessrio para com-
pilar e executar o exemplo est disponvel diretamente da pgina do Ar-
chC [ArchC 2006]. A Figura 7.21 indica o diagrama final do sistema multi-
core, que composto por dois processadores MIPS1, gerados automatica-
mente atravs do ArchC, um barramento e uma memria externa, interligada
pelo barramento aos processadores. Como complicador do modelo, cada um
dos processadores possui um wrapper para fazer a converso do protocolo
AC_TLM para o nvel utilizado pelo barramento, demonstrando as facilidades
de comunicao entre diferentes nveis de abstrao que uma implementao
TLM pode fornecer. Outra caracterstica implementada dentro dos wrappers
foi o gerenciamento do espao de memria de cada processador, que ser
comentado mais adiante.
Na Figura 7.21, os dois processadores e o rbitro foram implementados
com SC_THREAD, o que permite que eles chamem diretamente ou indireta-
mente a funo wait. Os mdulos SIMPLE BUS (que um barramento sim-
ples) e MEM so SC_METHOD e os wrappers esto implementados apenas
como chamadas de funes de converso (que podem executar wait por se-
rem chamadas pelos processadores apenas).
A Figura 7.22 contm o arquivo principal com a instanciao dos compo-
nentes do sistema. As linhas 14 e 15 instanciam os dois processadores MIPS1,
370
1 # i n c l u d e < systemc >

2 # i n c l u d e " a c _ t l m _ p r o t o c o l .H"
3 using t l m : : t l m _ t r a n s p o r t _ i f ;
4
5 namespace user
6 {
7 / / / Uma memoria TLM usando a i n t e r f a c e TLM do ArchC
8 class shr_mem : public sc_module ,
9 public a c _ t l m _ t r a n s p o r t _ i f
10 {
11 public :
12 sc_export < a c _ t l m _ t r a n s p o r t _i f > target_export ;
13 a c _ t l m _ r s p _ s t a t u s writem ( const u i n t 3 2 _ t & ,
14 const u i n t 3 2 _ t & ) ;
15 a c _ t l m _ r s p _ s t a t u s readm ( const u i n t 3 2 _ t & , u i n t 3 2 _ t & ) ;
16
17 a c _ t l m _ r s p t r a n s p o r t ( const ac_tlm_req & r e q u e s t )
18 {
19 a c _ t l m _ r s p response ;
20
21 switch ( r e q u e s t . t y p e ) {
22 case READ : / / Pacote de READ
23 response . s t a t u s = readm ( r e q u e s t . addr ,
24 response . data ) ;
25 break ;
26 case WRITE : / / Pacote de WRITE
27 response . s t a t u s = writem ( r e q u e s t . addr ,
28 r e q u e s t . data ) ;
29 break ;
30 default :
31 response . s t a t u s = ERROR;
32 break ;
33 }
34 r e t u r n response ;
35 }
36 / / Construtor
37 shr_mem ( sc_module_name module_name , i n t k = 5 2 4 2 8 8 0 ) ;
38 / / Destrutor
39 ~shr_mem ( ) ;
40 private :
41 u i n t 8 _ t memory ;
42 };
43 };
Figura 7.18. Definio de um mdulo de memria com-

patvel com o protocolo AC_TLM
371
1 # i n c l u d e " shr_mem . h "

2
3 using user : : shr_mem ;
4 shr_mem : : shr_mem ( sc_module_name module_name , i n t k ) :
5 sc_module ( module_name ) ,
6 target_export ( " iport " )
7 {
8 t a r g e t _ e x p o r t ( t h i s ) ;
9 memory = new u i n t 8 _ t [ k ] ;
10 f o r ( k = k 1 ; k > 0 ; k ) memory [ k ] = 0 ;
11 }
12 shr_mem : : ~ shr_mem ( ) {
13 d e l e t e [ ] memory ;
14 }
15 a c _ t l m _ r s p _ s t a t u s shr_mem : : writem ( const u i n t 3 2 _ t & a ,
16 const u i n t 3 2 _ t & d )
17 {
18 memory [ a ] = ( ( ( u i n t 8 _ t ) &d ) [ 0 ] ) ;
19 memory [ a + 1 ] = ( ( ( u i n t 8 _ t ) & d ) [ 1 ] ) ;
20 memory [ a + 2 ] = ( ( ( u i n t 8 _ t ) & d ) [ 2 ] ) ;
21 memory [ a + 3 ] = ( ( ( u i n t 8 _ t ) & d ) [ 3 ] ) ;
22 r e t u r n SUCCESS;
23 }
24 a c _ t l m _ r s p _ s t a t u s shr_mem : : readm ( const u i n t 3 2 _ t &a ,
25 uint32_t &d )
26 {
27 ( ( ( u i n t 8 _ t ) & d ) [ 0 ] ) = memory [ a ] ;
28 ( ( ( u i n t 8 _ t ) & d ) [ 1 ] ) = memory [ a + 1 ] ;
29 ( ( ( u i n t 8 _ t ) & d ) [ 2 ] ) = memory [ a + 2 ] ;
30 ( ( ( u i n t 8 _ t ) & d ) [ 3 ] ) = memory [ a + 3 ] ;
31 r e t u r n SUCCESS;
32 }
Figura 7.19. Implementao de um mdulo de memria

compatvel com o protocolo AC_TLM
declarados em mips1.H. Como esses processadores so idnticos, necess-

rio tomar providncias para que eles no iniciem e executem exatamente o
mesmo programa da mesma forma. Existem 4 formas para gerenciar esse
nvel de concorrncia no incio da execuo dos processadores:
1. Garantir que apenas um processador inicie junto com o sistema e faz-lo
iniciar o outro processador algum tempo depois. Isso daria tempo para
que o primeiro processador realizasse uma preparao da memria para
que o segundo execute diretamente seu cdigo sem se preocupar com
cdigo de partida do sistema. Essa alternativa requer sinais e/ou APIs
especficas para suspender a execuo de um processador, que no
esto disponveis nos processadores gerados pelo ArchC.
2. Implementar uma instruo atmica test-and-set no processador, na in-
terface TLM e nos demais dispositivos envolvidos. Escrever apenas um
programa que ser executado nos dois processadores e, em um dado
372
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 }
Figura 7.20. Instanciao e conexo do mdulo de me-

mria ao processador
momento, atravs do uso da instruo test-and-set, separar os dois pro-

cessadores em dois fluxos diferentes de execuo. Aps essa separa-
o, cada processador pode executar um cdigo diferente, implemen-
tando o comportamento desejado do sistema. Essa uma implemen-
tao prxima da realidade de desenvolvedores de hardware, mas com
implementao no to simples, pois requer suporte a operaes atmi-
cas em todos os dispositivos envolvidos.
3. Compilar os programas de cada processador para um espao de ende-
reamento diferente e fazer com que os processadores carreguem essa
informao diretamente dos arquivos executveis (ELF). Essa alternativa
plenamente vivel, s que nem sempre possvel de implementar, como
no caso em que o programa esteja armazenado numa memria ROM
externa e no exista uma cpia do arquivo com o cdigo executvel para
iniciar o processador.
4. Forar, na descrio do sistema, que cada processador s visualize um
pedao da memria global, atravs do mapeamento dos endereos en-
viados pelos processadores para posies distintas da memria. Essa
373
Figura 7.21. Diagrama de bloco do exemplo multicore
alternativa a mais simples de ser implementada nesse sistema e foi

a escolhida. A implementao foi totalmente feita dentro dos wrappers
que passaram a ser responsveis tambm por implementar o modelo de
memria final do sistema. Dessa forma, a memria externa foi declarada
como tendo 10Mb (linha 21) e 5 Mb foram mapeados para cada proces-
sador, sendo o endereo entre 2Mb e 3Mb compartilhado entre os dois
processadores conforme indicado na Figura 7.23. A configurao dos
wrappers feita nas linhas 25 e 26 e a carga dos programas de cada um
dos processadores feita nas linhas 38 e 39.
De uma forma geral, na Figura 7.22, da linha 14 at a 20 so instancia-
dos os componentes do sistema, da linha 23 at a 29 so feitas as ligaes
(bindings) entre os componentes, da linha 32 at a 37 os processadores so
configurados e a simulao executada atravs da chamada sc_start da
linha 39. Aps o trmino da simulao, as estatsticas de execuo dos simu-
ladores so impressas na tela e a simulao retorna o resultado da execuo
dos dois simuladores de processadores.
A Figura 7.24 mostra a implementao do mtodo transport utilizado pe-
los wrappers. O campo m_address iniciado no construtor com o endereo-
base a ser utilizado pelo processador que est interligado a esse wrapper. A
varivel local toff contm o deslocamento na memria que ser adicionado
ao endereo enviado pelo processador e, conforme a deciso tomada nas li-
nhas 89, seu valor pode ser 0 ou m_address. essa deciso que faz com
que o espao de endereamento entre 2Mb e 3Mb seja compartilhado pelos
dois processadores. Logo a seguir, nas linhas 11 at 21, o tipo de requisio
enviado decodificado e o mtodo relativo requisio (readm para leitura
ou writem para escrita) executado. Os mtodos readm e writem tambm
esto implementados na classe w_sb.
374
1 #include < systemc . h>

2 #include " mips1 . H"
3 #include " w_sb . h "
4 #include " loader . h"
5 #include " simple_bus . h "
6 #include " simple_bus_fast_mem . h "
7 #include " simple_bus_arbiter . h"
8
9 i n t sc_main ( i n t ac , char av [ ] )
10 {
11 / / Bus c l o c k
12 sc_clock bus_clock ;
13
16 simple_bus bus ( " bus " , f a l s e ) ;
17 simple_bus_fast_mem mem_fast ( " mem_fast " , 0 x00 , 0 x9FFFFF ) ;
18 simple_bus_arbiter a r b i t e r ( " a r b i t e r " ) ;
19 w_sb wrap1 ( " wrapper1 " , 1 , 0 x000000 , f a l s e , 3 ) ;
20 w_sb wrap2 ( " wrapper2 " , 2 , 0 x500000 , f a l s e , 3 ) ;
21
22 / / Bindings
23 bus . c l o c k ( bus_clock ) ;
24 bus . a r b i t e r _ p o r t ( a r b i t e r ) ;
25 bus . s l a v e _ p o r t ( mem_fast ) ;
26 wrap1 . b u s _ p o r t ( bus ) ;
27 wrap2 . b u s _ p o r t ( bus ) ;
28 mips1_proc1 . DM_port ( wrap1 . t a r g e t _ e x p o r t ) ;
29 mips1_proc2 . DM_port ( wrap2 . t a r g e t _ e x p o r t ) ;
30
31 / / Carrega os programas antes de i n i c i a r
32 l o a d _ e l f ( mips1_proc1 , mem_fast , " t e s t 1 " ,0 x000000 ) ;
33 l o a d _ e l f ( mips1_proc2 , mem_fast , " t e s t 2 " ,0 x500000 ) ;
34
35 / / Prepara os processadores
36 mips1_proc1 . i n i t ( ) ;
37 mips1_proc2 . i n i t ( ) ;
38
39 sc_start ( 1);
40
43
44 r e t u r n mips1_proc1 . a c _ e x i t _ s t a t u s | |
45 mips1_proc2 . a c _ e x i t _ s t a t u s ;
46 }
Figura 7.22. Arquivo principal do exemplo multicore com

dois processadores MIPS1, um barramento e uma me-
mria externa
375
0M
2M 0M
MIPS1_PROC1 shared
3M 2M
shared
3M
5M
5M
0M 7M
2M unused
shared 8M
MIPS1_PROC2 3M
10M
5M
Figura 7.23. Diagrama de memria do sistema completo
7.6.1. O Barramento Simple Bus

O SIMPLE BUS um barramento modelado em nvel TLM com sincroniza-
o por ciclos. A sincronizao por ciclos modela o comportamento do sistema
ciclo por ciclo, mas sem se preocupar com o que acontece em cada subciclo.
Todas as transferncias de dados so feitas via TLM. Este esquema permite
uma preciso de simulao razovel, mas com velocidade muito maior que
as descries puramente RTL. Este barramento distribudo como exemplo
nos pacotes de SystemC (www.systemc.org). A seguir os principais aspectos
desse barramento so analisados.
7.6.1.1. Interfaces
A interface define o modo como acontece a comunicao entre os mestres

e os escravos ligados ao barramento. O Simple Bus permite que mais de um
mestre seja ligado ao barramento, desde que atribua-se uma prioridade nica
para cada um deles. H trs tipos de interface descritas no Simple Bus: blo-
queante, no-bloqueante e direta.
A interface bloqueante foi especialmente projetada para permitir escritas e
leituras em rajadas. Este comportamento comum em transferncias longas
e permite que um mestre utilize o barramento por um tempo maior que uma
transao simples.
A interface no-bloqueante permite a transmisso apenas de um pacote,
limitando a transao a somente uma palavra. As funes no bloqueantes
retornam no instante da chamada, cabendo ao mestre observar o estado do
barramento para descobrir se e quando a transao foi completada. Se uma
transao for iniciada por um mestre que ainda possui uma transao pendente
no barramento, ambas sero descartadas e um erro de barramento sinalizado.
A interface direta utiliza o barramento para a transmisso de dados, mas
no utiliza o protocolo definido pelo mesmo. A requisio atendida imediata-
376
1 a c _ t l m _ r s p w_sb : : t r a n s p o r t ( const ac_tlm_req & r e q u e s t ) {

2
3 a c _ t l m _ r s p response ;
4 unsigned i n t t o f f ;
5 t o f f = m_address ;
6
7 / / Area de memoria comum .
8 i f ( ( r e q u e s t . addr > = 0 x200000 )&&( r e q u e s t . addr <=0x300000 ) )
9 t o f f = 0 x0 ;
10
11 switch ( r e q u e s t . t y p e ) {
12 case READ : / / Packet i s a READ one
13 response . s t a t u s = readm ( r e q u e s t . addr + t o f f ,
14 response . data ) ;
15 break ;
16 case WRITE : / / Packet i s a WRITE
17 response . s t a t u s = writem ( r e q u e s t . addr + t o f f ,
18 r e q u e s t . data ) ;
19 break ;
20 default :
21 response . s t a t u s = ERROR;
22 break ;
23 }
24 r e t u r n response ;
25 }
Figura 7.24. Implementao do mtodo transport dos wrappers
mente, com prioridade sobre todas as transaes em curso. No h erro para

este tipo de chamada, apenas um valor de retorno binrio indicando uma falha
(que s acontece em casos em que o endereo solicitado no existe ou na
realizao de uma escrita em um escravo somente de leitura). Esta interface
muito til na depurao e monitoramento do barramento, mas desaconse-
lhada para uso normal.
H ainda uma uma quarta interface, que na verdade um modelo de inter-
face para os escravos. Todos os escravos devem implement-la, pois o Simple
Bus trata todos eles como sendo algum tipo de memria. Esta interface possui
funes de leitura, escrita e propriedades, como o endereo inicial e final do
mapeamento entre o escravo e o barramento.
7.6.1.2. rbitro
O Simple Bus possui um rbitro interno conectado ao barramento por uma

porta dedicada. Este rbitro responsvel por escolher a transao que ser
atendida se mais de uma ocorrer no mesmo ciclo. Como todos os mestres so
independentes e possuem uma prioridade nica, o rbitro utiliza-se da mesma
para julgar a ordem das transaes.
H ainda um esquema de requisio em rajadas. Cada transao possui
um campo dizendo se aquela ou no uma transao em rajadas. Se a transa-
377
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
lhada do funcionamento deste algoritmo e da diviso em seis passos, que

aproveita caractersticas da FFT para efetuar a paralelizao, pode ser encon-
trada em [Woo et al. 1994]. Essa a aplicao escolhida para ser executada
no sistema de exemplo.
7.6.2.1. Alocao de processos
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 ( ) ;
Neste fragmento destaca-se a estrutura em macros. O cdigo respons-

vel por disparar os diversos fluxos de execuo filhos chamado pela macro
CREATE, que por si chama uma funo definida, a SlaveStart. Todo o pro-
cessamento dos filhos est contido nesta funo, o que facilita a diviso entre
os processadores.
Nesse caso, o processador-pai segue o fluxo normal de execuo do pro-
grama, mas no responsvel por disparar outros processadores. Todos os
processadores-filhos executam a funo SlaveStart, mas aguardam at o
que o pai chegue ao ponto de disparo dos filhos para iniciar o processa-
mento. Com este dispositivo, temos um comportamento similar criao de
processos-filhos em um sistema baseado em multiprocessos controlados por
um SO.
7.6.2.2. Compartilhamento de memria
Como descrito acima, o compartilhamento de memria foi implementado

atravs de um wrapper que mapeia a memria atravs de um offset. Os pro-
cessadores sempre buscam o endereo inicial zero da memria, porm,cada
processador possui sua prpria instncia de wrapper, fazendo com que o pri-
meiro processador enxerge como endereo zero realmente o endereo zero da
memria, mas o que o segundo processador enxerga como endereo zero
na realidade o endereo 0x500000; reveja a Figura 7.23.
379
No cdigo original do SPLASH-2, os endereos compartilhados eram alo-

cados dinamicamente, com os ponteiros armazenados em variveis globais
dentro do escopo de todos os processos-filhos. Como esse mecanismo no
est disponvel no sistema de exemplo, a soluo alocar estaticamente todos
os espaos de memria compartilhados.
1 Global = ( struct GlobalMemory ) 0 x250000 ;

2 x = ( double ) 0 x250100 ;
3 trans = ( double ) 0 x260000 ;
4 umain = ( double ) 0 x270000 ;
5 umain2 = ( double ) 0 x280000 ;
6
7 Global >t r a n s t i m e s = ( i n t ) 0 x290000 ;
8 Global > t o t a l t i m e s = ( i n t ) 0 x290010 ;
Figura 7.25. Mapeamento das variveis compartilhadas

pelo programa-exemplo
O cdigo da Figura 7.25 ilustra os mapeamentos das variveis comparti-

lhadas pelo programa-exemplo. Repare que os endereos so estaticamente
atribudos aos ponteiros declarados. Cada processador possui uma verso
local do ponteiro, mas todos eles apontam para o mesmo local, tornando-se
assim uma rea compartilhada de memria.
A grande desvantagem a m utilizao dos recursos de armazenamento,
j que a quantidade de memria ocupada fixa. Outro cuidado que deve ser
tomado quanto s bordas dos vetores. Se uma escrita for feita em um local
muito afastado do incio do vetor, corre-se o risco de sobrescrever o incio de
outro vetor. Isto chamado de memory overlapping e tambm uma questo
tratada pelo SO.
Com a diferenciao via hardware, todos os processadores podem rodar
exatamente o mesmo cdigo e enxergar o mesmo espao de endereamento,
sendo que o cdigo inicial um lao nulo. O primeiro processador a ser inter-
rompido por um agente externo (um gerador cclico de sinais - Real Time Clock
- RTC) sai do lao e se declara o processador-pai, preparando todos os outros
processadores. Suas tarefas incluem a configurao dos parmetros comuns,
como endereo da pilha e da rea de heap corretamente para cada um dos
processadores-filhos, o endereo inicial de cada um e a alocao e inicializa-
o das reas compartilhadas. Ao redirecionar os processadores-filhos para
suas respectivas tarefas, nenhum deles sobrescrever reas pertencentes a
outros processadores, devido ao cuidado tomado pelo primeiro processador.
7.6.2.3. Sincronizao e excluso mtua
A sincronizao foi feita utilizando um semforo de dekker [Stevens 1999].

Este tipo de semforo baseado em turnos, com precedncia similar ao Round
380
Robin. Cada processador recebe uma identificao esttica, embutida no c-

digo que rodar no mesmo, que utilizada para definir de quem o turno atual,
resolvendo as condies de disputa.
Com um semforo deste tipo, pode-se derivar a sincronizao como uma
espera por uma matriz de semforos onde todos os processadores devem obri-
gatoriamente manter o prprio semforo travado at que a condio de sincro-
nizao ocorra. Este mtodo est implementado para dois processadores no
nosso sistema e pode ser visualizado no fragmento abaixo.
1 MtxLock ( t _ p i d , Global > i d l o c k ) ;
2 i f ( Global > s t a r t . b a r _ t e l l e r ==10)
3 Global > s t a r t . b a r _ t e l l e r = t _ p i d ;
4 else
5 Global > s t a r t . b a r _ t e l l e r =10;
6 MtxUnLock ( t _ p i d , Global > i d l o c k ) ;
7 while ( Global > s t a r t . b a r _ t e l l e r ! = 1 0 ) ;
A excluso mtua direta, dado que o semforo de dekker inerentemente

um mutex.
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
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
[CoreConnect 2000] CoreConnect (2000). The CoreConnect Bus Archi-

tecture. IBM Corporation, http://www.chips.ibm.com/products/
coreconnect.
[DeMicheli 1996] DeMicheli, G. (1996). Hardware/Software Co-design, chap-
ter Hardware/Software Co-design: Application Domains and Design Techno-
logies, pages 128. Kluwer Academic Publishers.
[Eric Schnarr and James Larus 1998] Eric Schnarr and James Larus (1998).
Fast Out-Of-Order Processor Simulation Using Memoization. In Eighth Inter-
national Conference on Architectural Support for Programming Languages
and Operating Systems (ASPLOS-VIII), San Jose, California.
[Fauth and Knoll 1993] Fauth, A. and Knoll, A. (1993). Automated generation
of DSP program development tools using a machine description formalism. In
Proc. IEEE Int. Conf. Acoustics, Speech, Signal, Minneapolis (Minn., U.S.A.),
pages 457460.
[Fauth et al. 1995] Fauth, A., Praet, J. V., and Freericks, M. (1995). Describing
Instruction Set Processors using nML. In in Proc. European Design and Test
Conf., Paris, pages 503507.
[Freericks 1993] Freericks, M. (1993). The nML Machine Description Forma-
lism. Technical report, Technische Universitt Berlin, Fachbereich Informa-
tiky. Updated and Revised Version 1.5(Draft).
[Gasjki and Vahid 1995] Gasjki, D. and Vahid, F. (1995). Specification and De-
sign of Embedded Hardware-Software Systems. IEEE Design and Test of
Computers, pages 5367.
[Gill 2005] Gill, E. (2005). Comparison of the performance of microprocessors
for space-based navigation applications. Technical report, Space Flight Te-
chnology, German Space Operations Center. Version 1.1.
[Goering 2005] Goering, R. (2005). Tools Missing as ESL Rolls.
In http://www.eet.com/news/latest/showArticle.jhtml?
articleID=164900841.
[Grun et al. 1999] Grun, P., Halambi, A., Dutt, N., and Nicolau, A. (1999). RT-
GEN: An Algorithm for Automatic Generation of Reservation Tables from Ar-
chitectural Descriptions. In in Proceedings of International Symposium on
System Synthesis (ISSS).
[Gupta et al. 1992] Gupta, R. K., Coelho, C. N., and Micheli, G. D. (1992).
Synthesis and Simulation of Digital Systems Containing Interacting Hardware
and Software Components. In Proceedings of the 29th Design Automation
Conference.
[Hadjiyiannis and Devadas 2002] Hadjiyiannis, G. and Devadas, S. (2002). Te-
chniques for Accurate Performance Evaluation in Architecture Exploration.
IEEE Transactions on VLSI Systems.
383
[Hadjiyiannis et al. 1997] Hadjiyiannis, G., Hanono, S., and Devadas, S.

(1997). ISDL: An instruction set description language for retargetability. In
Design Automation Conference, pages 299302.
[Halambi et al. 1999] Halambi, A., P.Grun, V.Ganesh, A.Khare, N.Dutt, and
A.Nicolau (1999). EXPRESSION: A language for architecture exploration
through compiler/simulator retargetability. In in Proc. European Conference
on Design, Automation and Test(DATE).
[Hartoog et al. 1997] Hartoog, M. R., Rowson, J. A., Reddy, P., Desai, S., Dun-
lop, D. D., Harcourt, E. A., and Khullar, N. (1997). Generation of Software
Tools from Processor Descriptions for Hardware/Software Codesign. In in
Proc. Design Automation Conference, pages 303306.
[Hemani et al. 2000] Hemani, A., Jantsch, A., Kumar, S., Postula, A., berg,
J., Millberg, M., and Lindqvist, D. (2000). Network on chip: An architecture
for billion transistor era. In Proceeding of the IEEE NorChip Conference.
[Hoffmann et al. 2001] Hoffmann, A., Kogel, T., and Meyr, H. (2001). A fra-
mework for fast hardware-software co-simulation. In Proceedings of Design,
Automation and Test in Europe Conference (DATE).
[Hohenauer et al. 2004] Hohenauer, M., Scharwaechter, H., Karuri, K., Wah-
len, O., Kogel, T., Leupers, R., Ascheid, G., Meyr, H., Braun, G., and van
Someren, H. (2004). A Methodology and Tool Suite for C Compiler Genera-
tion from ADL Processor Models. In Proceedings of Design, Automation and
Test in Europe Conference (DATE).
[ITRS 2005] ITRS (2005). The international technology roadmap for semi-
conductors. Technical report, Semiconductor Industry Association. http:
//public.itrs.net.
[Kane and Heinrich 1992] Kane, G. and Heinrich, J. (1992). MIPS RISC Archi-
tecture. Prentice Hall, New Jersey.
[Kissell 1997] Kissell, K. (1997). MIPS16: High-density MIPS for the Embed-
ded Market. Silicon Graphics MIPS Group.
[Krishnadas 2005] Krishnadas, K. (2005). India Gearing for Outsourced ESL
Design. In http://www.eetimes.com/news/design/showArticle.
jhtml?articleID=17120051%5.
[Lanneer et al. 1995] Lanneer, D., Praet, J. V., Kifli, A., Schoofs, K., Geurts,
W., Thoen, F., and Goossens, G. (1995). Code Generation for Embedded
Processors, chapter Chess: Retargetable Code Generation for Embedded
DSP Processors, pages 85102. Kluwer Academic Publishers, Boston.
[Lohr et al. 1993] Lohr, F., Fauth, A., and Freericks, M. (1993). SiGH/SIM -
An Environment for Retargetable Instruction Set Simulation. Technical Re-
port 43, Comp. Science Dept., T.U. Berlin, Berlin (Germany).
384
[Mattsson and Christensson 2006] Mattsson, D. and Christensson, M. (2006).

Evaluation of synthesizable cpu cores. Masters thesis, Chalmers University
of Technology.
[McGrath 2005] McGrath, D. (2005). Survey says: ESL Methodologies
Can Improve Productivity. In http://www.eetimes.com/news/design/
technology/showArticle.jhtml?article%ID=166403876.
[Mishra et al. 2001] Mishra, P., Dutt, N. D., and Nicolau, A. (2001). Functional
abstraction driven design space exploration of heterogeneous programma-
ble architectures. In in Proceedings of International Symposium on System
Synthesis (ISSS), pages 256261.
[OSCI 2005] OSCI (2005). SystemC Version 2.1 Users Guide.
[Qin 2004] Qin, W. (2004). Modeling and Description of Embedded Processors
for the Development of Software Tools. PhD thesis, Department of Electrical
Engeneering, Princeton University.
[Qin and Malik 2003] Qin, W. and Malik, S. (2003). Flexible and formal mode-
ling of microprocessors with application to retargetable simulation. In Pro-
ceedings of Conference on Design, Automation and Test in Europe, pages
556561. IEEE Xplore.
[Qin and Malik 2005] Qin, W. and Malik, S. (2005). A Study of Architecture
Description Languages from a Model-based Perspective (invited). In Pro-
ceedings of the 6th International Workshop on Microprocessor Testing and
Verification.
[Rigo et al. 2004] Rigo, S., Araujo, G., Bartholomeu, M., and Azevedo, R.
(2004). ArchC: A SystemC-Based Architecture Description Language. In
Proceedings of the 16th Symposium on Computer Architecture and High Per-
formance Computing, pages 6673.
[Siska 1998] Siska, C. (1998). A processor description language supporting
retargetable multi-pipeline dsp program development tools. In in Proceedings
of International Symposium on System Synthesis (ISSS).
[SPARC 1992] SPARC (1992). The SPARC architecture manual - Version 8.
SPARC International, Inc. Revision SAV080SI9308.
[Stevens 1999] Stevens, W. R. (1999). UNIX Network Programming - Interpro-
cess Communication. Prentice Hall.
[SystemC TLM Working Group 2005] SystemC TLM Working Group
(2005). SystemC Transaction-level Modeling Standard Version 1.0.
http://www.systemc.org.
[Team 2004] Team, T. A. (2004). The ArchC Architecture Description Language
Reference Manual. Computer Systems Laboratory (LSC) - Institute of Com-
puting, University of Campinas, http://www.archc.org.
385
[Team 2005] Team, T. A. (2005). The ArchC Assembler Generator Manual.

Computer Systems Laboratory (LSC) - Institute of Computing, University of
Campinas, http://www.archc.org.
[Turley 1995] Turley, J. (1995). Thumb squeezes ARM code size. Microproces-
sor Report, 9(4).
[Vahid and Givargis 2002] Vahid, F. and Givargis, T. (2002). Embedded System
Design: A Unified Hardware/Software Introduction. John Wiley & Sons.
[Viana et al. 2004] Viana, P., Barros, E., Rigo, S., Azevedo, R., and Arajo, G.
(2004). Modeling and Simulating Memory Hierarchies in a Platform-Based
Design Methodology. In Proc. of the Design, Automation and Test in Europe
(DATE04), Paris.
[Wieferink et al. 2004] Wieferink, A., Kogel, T., Leupers, R., Ascheid, G., Meyr,
H., and et al. (2004). A System Level Processor/Communication Co-
Exploration Methodology for Multi-Processor System-on-Chip Platforms. In
Proc. Int. Conf. on Design, Automation and Test in Europe(DATE).
[Witchel and Rosenblum 1996] Witchel, E. and Rosenblum, M. (1996). Embra:
Fast and flexible machine simulation. In Measurement and Modeling of Com-
puter Systems, pages 6879.
[Woo et al. 1995] Woo, S. C., Ohara, M., Torrie, E., Singh, J. P., and Gupta,
A. (1995). The SPLASH-2 Programs: Characterization and Methodological
Considerations. In Proceedigs of the 22nd International Symposium on Com-
puter Architecture (ISCA), pages 2436.
[Woo et al. 1994] Woo, S. C., Singh, J. P., and Hennessy, J. L. (1994). The Per-
formance Advantages of Integrating Block Data Transfer in Cache-Coherent
Multiprocessors. In Proceedings of the Sixth International Conference on
Architectural Support for Programming Languages and Operating Systems
(ASPLOS-VI), pages 219229.
[Zivojnovic et al. 1996a] Zivojnovic, V., Pees, S., and Meyr, H. (1996a). Lisa
- machine description language and generic machine model for hw/sw co-
design. In Proceedings of the IEEE Workshop on VLSI Signal Processing,
San Francisco.
[Zivojnovic et al. 1996b] Zivojnovic, V., Pees, S., Schalger, C., Willems, M.,
Schoenen, R., and Meyr, H. (1996b). DSP Processor/Compiler Co-Design:
A Quantitative Approach. In International Symposium on System Synthesis
(ISSS).
386

Projeto e Desenvolvimento de Sistemas Dedicados Multiprocessados

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Projeto e Desenvolvimento de Sistemas Dedicados Multiprocessados

Enviado por

Direitos autorais:

Formatos disponíveis

Projeto e Desenvolvimento de Sistemas Dedicados

Rodolfo Azevedo, Sandro Rigo, Guido Arajo

com time-to-market exigem a reduo do tempo de prototipagem e o incio do

neo de hardware e software, criaram um timo momento para o desenvolvi-

7.2. Projeto de Sistemas Dedicados

Propsito nico: Em geral, executam apenas um nico programa repetitiva-

Reatividade: Em geral reagem ao que acontece ao redor deles, com pouca

Agrupadas a essas caractersticas e restries, diversas mtricas precisam

(a) Volume de vendas (b) Entrada atrasada no mer-

Figura 7.1. Janela de mercado

Segurana: Garantia de que o produto no causar danos imprevistos quando

7.2.1. Custo do Produto

Tecnologia NRE Custo unitrio

Tabela 7.1. Opes de custo para trs tecnologias dis-

7.2.2. Tecnologias de Implementao

O uso de componentes avulsos tem se justificado hoje em dia apenas para

em quantidade o mercado de sistemas dedicados, possui palavra, re-

rias ao sistema em questo. A Tabela 7.4 ilustra o espao de enderea-

Intervalo Tam. Contedo Controlador

Tratamento de interrupes: A forma mais eficaz para tratamento a eventos

terrupes: Na primeira, o processador reserva um endereo para cada

CISC x RISC: Esses dois acrnimos criados para distinguir a complexidade do

Barramento de Interconexo: Embora esse tem no seja, tecnicamente,

Ao se comparar processadores, no se deve perder de foco a aplicao

1 # i n c l u d e " systemc . h "

Figura 7.2. Exemplo de SystemC: Mdulo que imple-

a implementao em SystemC, algumas macros pre-definidas pela biblioteca

1 # i n c l u d e " systemc . h "

Figura 7.3. Exemplo de SystemC: Gerador de estmulos

tra um mdulo que gera estmulos para o mdulo Maior. No corpo do m-

1 # i n c l u d e " systemc . h "

Figura 7.4. Exemplo de SystemC: Arquivo principal que

modelados como classes ou templates C++. Exemplos vo desde os sinais

final e em que endereos de memria deve ficar cada pedao do programa

Reading specs from /usr/lib/gcc/i686-pc-linux-gnu/3.4.5/specs

Figura 7.5. Resultado da compilao do programa hello.c

7.3. Software para Sistemas Multiprocessados

O principal problema que aplicaes seqnciais, que na literatura so

um algoritmo onde o valor de um pixel pode influenciar o valor de seus

da aplicao, as threads podem compartilhar dados de uma maneira que no

7.3.1. Alternativas de Implementao para Programao Multi-

suporte a threads a sua simplicidade. O programador precisa utilizar um con-

7.4. Modelagem de Processadores

indstria. Hoje em dia, ADLs so utilizadas para gerao de simuladores de

of Berlim (TUB). Utilizando nML, um grupo dessa universidade projetou um si-

outras linguagens j citadas na poca de sua criao. Os autores justificam

Braun et al [Braun et al. 2003] apresentaram uma extenso lingua-

permitir uma sintaxe semelhante C++ em alguns aspectos LISA.

bilidade de incorporar funcionalidades oferecidas por SystemC. Por ou-

7.4.1. A Linguagem ArchC

vel do conjunto de instrues, que pode ser instrumentada com interfaces de

7.4.1.1. Descrevendo os Recursos do Processador

ArchC necessita de informaes estruturais sobre os recursos disponveis

Figura 7.6. MIPS funcional: Declarao de memria e de

tos bsicos de estrutura, como visto na Figura 7.7. A seguir so mostrados os

Figura 7.7. SPARC funcional: Declarao de registradores

7.4.1.2. Especificando o Conjunto de Instrues

A descrio AC_ISA fornece ArchC toda a informao necessria para

Figura 7.8. MIPS com preciso de ciclos: Declarao de

ISA_CTOR: Inicializa a declarao do construtor de AC_ISA.

7.4.1.3. Descrevendo os Comportamentos das Instrues

A descrio de quais operaes so executadas por quais instrues em

(template) do arquivo da descrio de comportamentos. Este arquivo um

Figura 7.9. MIPS: Comportamento de uma instruo