Através do profiling de um codificador de imagens JPEG e da análise de potencial reuso no contexto de um projeto baseado em plataforma, implementou-se um acelerador em hardware (IP) para a Transformada Discreta do Cosseno (DCT). O modelo funcional do IP foi integrado em uma plataforma para a compressão de bitmaps para o formato JPEG. Trabalho de Conclusão de Curso em Ciências da Computação na Universidade Federal de Santa Catarina. Originalmente publicado em: https://projetos.inf.ufsc.br/arquivos_projetos/projeto_666/monografia.pdf

1. Daniel Pereira Volpato e Leonardo Luiz Ecco
¸˜
Projeto e Validacao de um IP para o Padr˜ o JPEG
a
¸˜
e sua Integracao a uma Plataforma descrita no
estilo TLM
Florian´ polis – SC
o
Outubro / 2007

2. Daniel Pereira Volpato e Leonardo Luiz Ecco
¸˜
Projeto e Validacao de um IP para o Padr˜ o JPEG
a
¸˜
e sua Integracao a uma Plataforma descrita no
estilo TLM
Monografia apresentada ao curso de Bachare-
¸˜
lado em Ciˆ ncias da Computacao da Universi-
e
dade Federal de Santa Catarina como requisito
¸˜
parcial para obtencao do grau de Bacharel em
¸˜
Ciˆ ncias da Computacao.
e
Orientador:
Prof. Dr. Luiz Cl´ udio Villar dos Santos
a
U NIVERSIDADE F EDERAL DE S ANTA C ATARINA
´
C ENTRO T ECNOL OGICO
Florian´ polis – SC
o
Outubro / 2007

3. ¸˜
Monografia de graduacao sob o t´tulo “Projeto e validacao de um IP para o padr˜ o JPEG e
ı ¸˜ a
sua integracao numa plataforma descrita no estilo TLM”, defendida por Daniel Pereira Volpato
¸˜
e Leonardo Luiz Ecco e aprovada em 30 de outubro de 2007, em Florian´ polis , Santa Catarina,
o
pela banca examinadora constitu´da pelos professores:
ı
Prof. Dr. Luiz Cl´ udio Villar dos Santos
a
Universidade Federal de Santa Catarina
Orientador
Prof. Dr. Jos´ Lu´s Almada G¨ ntzel
e ı u
Universidade Federal de Santa Catarina
Membro da Banca
Prof. Dr. Olinto Jos´ Varela Furtado
e
Universidade Federal de Santa Catarina
Membro da Banca

4. RESUMO
Para a ind´ stria de sistemas, o re´ so de IPs e a engenharia baseada em modelos s˜ o mecanis-
u u a
mos fundamentais para alcancar ganhos de produtividade significativos no projeto de sistemas
¸
integrados (SoCs) complexos. Nesse contexto, duas t´ cnicas tˆ m se mostrado promissoras: o
e e
¸˜
projeto baseado em plataforma (PBD) e a modelagem baseada em transacoes (TLM).
¸˜
Este trabalho explora conteitos de PBD e TLM para a concepcao de um acelerador em
hardware, projetado na forma de um bloco de propriedade intelectual (IP), para potencial reuso
em plataformas multim´dia.
ı
e ¸˜
Atrav´ s do “profiling“ de um programa de codificacao no formato JPEG e da an´ lise de
a
¸˜
potencial reuso, escolheu-se implementar em hardware a funcao “Discrete Cosine Transform“
(DCT). O modelo funcional do IP selecionado foi integrado em uma plataforma, descrita no
´
estilo TLM, a qual e capaz de realizar a compress˜ o de “bitmaps“ para o formato JPEG. A
a
plataforma adotada comp˜ e-se de um processador PowerPC, uma mem´ ria, um barramento e o
o o
IP sob projeto.
` ¸˜
Validou-se o modelo funcional do IP integrado a plataforma, atrav´ s de comparacao dos
e
¸˜
resultados nela obtidos com os resultados esperados produzidos pelo programa de codificacao
JPEG (modelo de referˆ ncia).
e
¸˜
Assim, o resultado principal deste trabalho foi a caracterizacao do comportamento funci-
`
onal da interface do IP, definido por um conjunto de est´mulos aplicado as suas entradas e o
ı
` ¸˜ ´
respectivo conjunto de resultados as suas sa´das. Tal caracterizacao e crucial para o projeto de
ı
¸˜ ` ¸˜
validacao de IP em n´vel RT com vistas a sua prototipacao em FPGA e em sil´cio, as quais s˜ o
ı ı a
objeto de trabalho em andamento.

5. LISTA DE FIGURAS
1 ¸˜
Metodologia de validacao utilizada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 16
2 Diagrama em blocos da plataforma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 17
3 M´ dulo forward DCT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 23
o
4 A interface simple bus slave if . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 25
5 ¸˜ ¸˜
Implementacao da funcao read . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 26
6 ¸˜ ¸˜
Implementacao da funcao write . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 27
7 A interface simple bus blocking if . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 28
8 Trecho do c´ digo de main.cpp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 29
o
9 Arquitetura RTL do IP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 30
10 ¸˜ ¸˜
Distribuicao do tempo gasto na execucao da plataforma . . . . . . . . . . . . . . . . . . . . . . p. 34
11 Imagem “boy“, em tons de cinza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 39
12 Imagem “jpeg testimg“ (que acompanha o software cjpeg) . . . . . . . . . . . . . . . . . . . p. 39
13 Imagem “mibench small“ (contida no benchmark MiBench) . . . . . . . . . . . . . . . . . p. 40
14 Imagem “mibench large“ (contida no benchmark MiBench) . . . . . . . . . . . . . . . . . . p. 40
15 Imagem “mediabench“ (contida no benchmark MediaBench) . . . . . . . . . . . . . . . . . p. 41
16 Imagem “nasa“. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 41
17 Imagem “ufsc ctc“ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 42

6. LISTA DE TABELAS
1 ¸˜
Conte´ do do arquivo de f s.arp mostrando a configuracao da plataforma . . . . . . p. 18
u
2 “Profiling“ do aplicativo cjpeg para a figura 13, 192Kb . . . . . . . . . . . . . . . . . . . . . . . p. 21
3 “Profiling“ do aplicativo cjpeg para a figura 14, 768Kb . . . . . . . . . . . . . . . . . . . . . . . p. 21
4 “Profiling“ do aplicativo cjpeg para a figura 16, 20Mb . . . . . . . . . . . . . . . . . . . . . . . . p. 21
5 “Profiling“ do aplicativo cjpeg para a figura 16, 183Mb . . . . . . . . . . . . . . . . . . . . . . p. 21
6 Sum´ rio dos “profilings“ realizados sobre o aplicativo cjpeg . . . . . . . . . . . . . . . . . . p. 21
a
7 Entradas e sa´das do m´ dulo forward DCT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 23
ı o
8 ¸˜
Registradores do IP - “Offsets“ com relacao ao endereco-base e tipo . . . . . . . . . . p. 24
¸
9 ¸˜ ¸˜
Comparacao de tempos de execucao: plataforma x software . . . . . . . . . . . . . . . . . . p. 32
10 ¸˜
Sum´ rio dos “profilings“realizados durante execucao da plataforma. . . . . . . . . . . p. 33
a
11 ¸˜ ¸˜
Configuracao das figuras utilizadas para “profiling“ e validacao . . . . . . . . . . . . . . . p. 38

7. ´
SUMARIO
1 ¸˜
MOTIVACAO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 8
2 ˜ ´
BREVE REVISAO BIBLIOGRAFICA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 10
2.1 PROJETO BASEADO EM PLATAFORMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 10
2.2 MODELAGEM EM N´ ¸˜
IVEL DE TRANSACAO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 11
2.3 SYSTEMC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 12
2.4 ˜
COMPRESSAO JPEG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 14
3 METODOLOGIA E INFRAESTRUTURA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 15
3.1 ¸˜
METODOLOGIA DE PROJETO E VALIDACAO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 15
3.2 INFRA-ESTRUTURA DE MODELAGEM DA PLATAFORMA . . . . . . . . . . . . . . . . . p. 16
3.2.1 ARCHC REFERENCE PLATFORM - ARP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 16
3.2.2 ¸˜ ˜
MAPEAMENTO DA APLICACAO DE COMPRESSAO JPEG PARA UMA
PLATAFORMA ARP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 17
4 PROJETO DO IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 19
4.1 ¸˜
SELECAO DO IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 19
4.1.1 ¸˜ ˜
IMPLEMENTACAO DE COMPRESSAO JPEG NO MIBENCH . . . . . . . . . . . . . . p. 19
4.1.2 A FERRAMENTA GPROF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 19
4.1.3 ¸˜
“PROFILING“ E SELECAO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 20
4.2 MODELAGEM FUNCIONAL DO IP NA PLATAFORMA TLM . . . . . . . . . . . . . . . . p. 22
4.2.1 ENTRADAS E SA´ ´
IDAS DO MODULO FORWARD DCT . . . . . . . . . . . . . . . . . . . . p. 22

8. 4.2.2 ´ ´
MAPEAMENTO DE E/S EM MEMORIA DO MODULO
FORWARD DCT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 23
4.2.3 ¸˜
MODELAGEM DAS TRANSACOES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 25
4.3 ¸˜
A INSTANCIACAO DE COMPONENTES NA PLATAFORMA . . . . . . . . . . . . . . . . p. 28
4.4 MODELAGEM RTL DO IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 30
5 RESULTADOS EXPERIMENTAIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 31
5.1 ¸˜
CONFIGURACAO EXPERIMENTAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 31
5.2 ¸˜
VALIDACAO DO IP FUNCIONAL NA PLATAFORMA . . . . . . . . . . . . . . . . . . . . . . . . p. 32
5.3 ¸˜ ¸˜
COMPARACAO DE TEMPOS DE EXECUCAO ENTRE PLATAFORMA E
SOFTWARE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 32
6 ˜
CONCLUSAO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 35
6.1 TRABALHOS FUTUROS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 35
ˆ
REFERENCIAS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 37
¸˜
ANEXO A -- IMAGENS UTILIZADAS PARA “PROFILING“ E VALIDACAO . . . p. 38
ˆ
APENDICE A -- MANUAL DO IP FORWARD DCT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 43
ˆ ´
APENDICE A -- CODIGO-FONTE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 48

9. 8
1 ¸ ˜
MOTIVACAO
u a e ¸˜
A ind´ stria de semicondutores vem vivendo h´ cerca de uma d´ cada a revolucao dos siste-
´
mas integrados (SoCs) (MARTIN; CHANG, 2003). Um SoC e um sistema eletrˆ nico completo
o
´
em um unico chip, integrando componentes de hardware e de software (GHENASSIA, 2005,
p. 2). Os blocos fundamentais de um SoC s˜ o denominados propriedades intelectuais (IPs),
a
ı e ¸˜
blocos que realizam tarefas espec´ficas, tais como a de perif´ ricos ou aceleradores de funcoes
cr´ticas.
ı
Os SoCs foram viabilizados com o adento das tecnologicas CMOS nanom´ tricas, permi-
e
¸˜ ¸˜
tindo a realizacao de computadores embarcados, “sistemas de processamento de informacao
embutidos em um produto maior e geralmente n˜ o diretamente vis´veis ao usu´ rio“ (MARWE-
a ı a
¸˜ ¸˜
DEL, 2006, p. 1). Exemplos de aplicacoes que utilizam SoCs para computacao embarcada
s˜ o: telefones celulares, cˆ meras digitais, video-games, controladores de freio ABS, sistemas
a a
de GPS, sistemas anti-colis˜ o em avi˜ es, sistemas m´ dicos, entre outros.
a o e
A crescente complexidade dos SoCs, o alto custo das m´ scaras de circuitos integrados
a
para tecnologias CMOS nanom´ tricas e o crescente custo de engenharia n˜ o recorrente de-
e a
`
ram origem a um novo paradigma de projeto denominado “Projeto baseado em Plataforma“
(SANGIOVANNI-VINCENTELLI; MARTIN, 2001). Essencialmente, uma plataforma con-
e ı ¸˜
siste de um projeto gen´ rico para um determinado dom´nio de aplicacao, que pode ser persona-
¸˜ ¸˜
lizado pela selecao de IPs apropriados e estendido com a concepcao de componentes adicionais.
¸˜
O projeto baseado em plataforma pode ser simplificado, ent˜ o, como a utilizacao desta arqui-
a
e ı ¸˜
tetura de referˆ ncia para um certo dom´nio associada com o reuso de IPs para composicao e
¸˜
customizacao da mesma.
Os blocos que comp˜ em uma plataforma podem ser descritos em diferentes n´veis de
o ı
¸˜
abstracao como, por exemplo: n´vel de transistores, n´vel de portas l´ gicas e n´vel de trans-
ı ı o ı
e ´
ferˆ ncia entre registradores (RTL). Este ultimo vinha sendo o mais usado pela ind´ stria como
u
ponto de partida para o projeto de circuitos integrados e descreve um componente como sendo
formado geralmente por um datapath comandado por uma unidade de controle.

10. 9
e u ı ¸˜
Al´ m disso, a crescente necessidade da ind´ stria de SoCs por um n´vel de abstracao mais
elevado levou ao surgimento da modelagem em n´vel de sistema eletrˆ nico (ESL), que possibi-
ı o
¸˜
lita a descricao de m´ dulos em diversos estilos, entre os quais est´ a modelagem em n´vel de
o a ı
¸˜
transacoes (TLM).
´ ¸˜ ¸˜
TLM e a abstracao dos detalhes de comunicacao atrav´ s dos meios de conex˜ o para viabili-
e a
¸˜
zar a simulacao de toda a plataforma, al´ m de I/O mapeado em mem´ ria, o que facilita o uso do
e o
m´ dulo pelo software rodando na plataforma. Desta forma, o TLM permite que a funcionali-
o
¸˜
dade de um m´ dulo seja separada da comunicacao, o que implica no favorecimento do reuso. E
o
¸˜ ¸˜
traz vantagens ainda na implementacao da comunicacao, trazendo o foco para a funcionalidade
¸˜
da comunicacao - quais dados, de onde e para onde s˜ o transmitidos -, e n˜ o nos detalhes do
a a
¸˜
protocolo de comunicacao, que s˜ o abstra´dos (GHENASSIA, 2005).
a ı
No presente trabalho, realizamos um estudo sobre estas duas t´ cnicas contemporˆ neas na
e a
´
area de projeto de SoCs: o projeto baseado em plataforma (PBD) e a modelagem transacional
(TLM). A importˆ ncia das t´ cnicas mencionadas na atual conjuntura vivida pela ind´ stria de
a e u
SoCs foi o fator que nos motivou a estud´ -las nesse trabalho.
a
O produto desse estudo foi uma plataforma descrita no estilo TLM, composta por um pro-
cessador PowerPC, um bloco de mem´ ria e um IP interconectados atrav´ s de um barramento,
o e
´
a qual e capaz de realizar compress˜ o de “bitmaps“ para o formato JPEG. As atividades aqui
a
ˆ ¸˜
descritas est˜ o no ambito do projeto APISCE: AUTOMACAO, PROJETO E INTEGRACAO DE
a ¸˜
¸˜ ¸˜
SISTEMAS COMPUTACIONAIS EMBARCADOS, em execucao no Laborat´ rio de Automacao
o
de Projeto de Sistemas (LAPS)1 da UFSC.
´
Este trabalho e organizado da seguinte maneira: no cap´tulo 2, uma breve revis˜ o bibli-
ı a
ogr´ fica abordando os t´ picos de projeto baseado em plataforma, modelagem em n´vel de
a o ı
¸˜
transacao, SystemC e a compress˜ o em formato JPEG. No cap´tulo 3, descrevemos a meto-
a ı
dologia para desenvolvimento de IPs e a infra-estrutura de modelagem de plataformas utilizada
neste trabalho. J´ no cap´tulo 4, falamos do projeto do IP desenvolvido, dos crit´ rios para
a ı e
¸˜
selecao do mesmo (que fizeram uso da t´ cnica de “profiling“) e do processo de modelagem
e
¸˜
funcional do IP e sua integracao na plataforma TLM utilizada. No cap´tulo 5, apresentamos
ı
¸˜ ¸˜
os resultados experimentais obtidos, bem como a configuracao utilizada para sua geracao, e
uma an´ lise dos mesmos a partir dos conhecimentos adquiridos ao longo deste trabalho. Final-
a
mente, no cap´tulo 6, demonstramos as conclus˜ es as quais chegamos e os trabalhos futuros no
ı o
contexto deste trabalho.
1 Saiba ¸˜
mais sobre o Laborat´ rio de Automacao de Projeto de Sistemas em: http://www.laps.inf.ufsc.
o
br/

11. 10
2 ˜
BREVE REVISAO
´
BIBLIOGRAFICA
Este cap´tulo faz uma an´ lise dos principais trabalhos que abordam t´ cnicas utilizadas na
ı a e
¸˜ a ´
concepcao de IPs. O objetivo dessa breve revis˜ o e a de amparar conceitualmente o trabalho,
atrav´ s do reuso de t´ cnicas consagradas ou promissoras. A revis˜ o em profundidade da vasta
e e a
literatura s´ faria sentido se a pretens˜ o fosse a de desenvolver novas t´ cnicas.
o a e
2.1 PROJETO BASEADO EM PLATAFORMA
O projeto baseado em plataforma surgiu como uma alternativa para lidar com trˆ s grandes
e
problemas que a ind´ stria microeletrˆ nica vem enfrentando (SANGIOVANNI-VINCENTELLI
u o
et al., 2004):
• Horizontalizacao do modelo de neg´ cios. Acostumadas a manter o controle sobre todo
¸˜ o
o processo de desenvolvimento do produto, as companhias viram-se forcadas a focar
¸
esforcos em suas competˆ ncias principais devido ao aumento da complexidade dos sis-
¸ e
temas e ao n´ mero de tecnologias envolvidas. Assim, para continuar no mercado com
u
produtos de boa qualidade, passaram a terceirizar partes do processo para outras empre-
¸˜
sas. H´ , portanto, a necessidade de um mecanismo formal para a integracao de toda a
a
cadeia de projeto.
• Para garantir uma boa margem de lucros, o “time-to-market“ deve ser reduzido - apesar
u ´
do crescimento exponencial da complexidade dos projetos. Por conseg¨ inte, e necess´ rio
a
¸˜
aumentar o reuso dos componentes em todos os n´veis de abstracao, e possibilitar uma
ı
´
certa flexibilidade de modo que mudancas de ultima hora possam ser tratadas.
¸
• Aumento dos custos em engenharia n˜ o-recorrente, devido ao alto custo associado ao
a
¸˜
processo. Por exemplo, a fabricacao de uma m´ scara pode custar milh˜ es de d´ lares e a
a o o
¸˜ ¸˜
construcao de unidades de producao envolve custos da ordem de bilh˜ es de d´ lares. Isso
o o

12. 11
torna crucial que se obtenha um projeto funcional na primeira tentativa - construir um
“chip“ que n˜ o funciona causaria preju´zos inaceit´ veis.
a ı a
´
Segundo Sangiovanni-Vincentelli e Martin (2001, p. 410), uma plataforma e uma “bibli-
¸˜
oteca de componentes junto com suas regras de composicao“. Essa biblioteca cont´ m tanto
e
¸˜ ¸˜
blocos que realizam a computacao em si, como blocos de comunicacao utilizados para interco-
nex˜ o. Assim, um projetista pode escolher um conjunto de componentes da biblioteca ou ajustar
a
parˆ metros de componentes reconfigur´ veis e derivar, desse modo, sua instˆ ncia da plataforma.
a a a
Dado que os blocos da biblioteca de uma plataforma podem estar em diferentes n´veis de
ı
¸˜
abstracao, um bloco de alto n´vel pode ser refinado para um n´vel mais baixo e substitu´do na
ı ı ı
plataforma j´ existente e previamente validada. O bloco refinado ser´ validado nesse ambiente
a a
j´ certificado, permitindo que os erros eventualmente encontrados sejam facilmente localizados
a
¸˜
e corrigidos, pois s´ podem estar no novo bloco. Execucoes desses passos para todos os blocos
o
visam o refinamento da plataforma como um todo para uma instˆ ncia em n´vel mais baixo, e
a ı
a o e ¸˜
que servir´ de base para os pr´ ximos passos at´ a fabricacao do “chip“.
¸˜ ´
Al´ m disso, a exploracao do espaco de projeto (design-space exploration) e favorecida
e ¸
numa plataforma de alto n´vel pois componentes podem ser substitu´dos e simulados mais rapi-
ı ı
damente. Isso permite, por exemplo, testar diferentes modelos de processador e verificar qual
¸˜
atenderia melhor as restricoes do sistema.
2.2 ´ ¸˜
MODELAGEM EM NIVEL DE TRANSACAO
Como j´ foi mencionado, a ind´ stria de SoCs vˆ m enfrentando press˜ es para reduzir o
a u e o
“time-to-market“, al´ m de ter de lidar com a crescente complexidade e custo dos sistemas pro-
e
´
jetados. Para tanto, uma estrat´ gia promissora e a de antecipar os ciclos de desenvolvimento de
e
¸˜
software e de exploracao de arquitetura durante o projeto. Isso culmina na necessidade de um
¸˜ ¸˜ ¸˜
aumento no n´vel de abstracao utilizado para descricao dos sistemas, para viabilizar a simulacao
ı
de sistemas complexos completos.
De acordo com (GHENASSIA, 2005, p. 25), trˆ s crit´ rios precisam ser levados em consi-
e e
¸˜ ¸˜ ¸˜
deracao quando se procura uma solucao intermedi´ ria entre uma descricao algor´tmica (onde
a ı
¸˜ ¸˜
n˜ o existe uma nocao de particionamento de hardware e software) e uma descricao RTL (uma
a
¸˜ ¸˜
descricao precisa do hardware que, entretanto, torna as simulacoes mais lentas). S˜ o eles:
a
• Velocidade: Em simulacoes de modelos muito detalhados, o tempo acaba se tornando
¸˜
um fator proibitivo.

13. 12
• Precis˜ o: A simulacao precisa fornecer resultados confi´ veis.
a ¸˜ a
• Pequeno custo de modelagem: O esforco de modelagem gasto precisa ser pequeno para
¸
n˜ o aumentar o custo total do projeto..
a
a ´
Assim, utilizar modelagem “bit-true“ com precis˜ o de ciclos n˜ o e uma boa alternativa da-
a
¸˜
dos os prop´ sitos mencionados anteriormente, uma vez que a velocidade de simulacao desse
o
¸˜
tipo de modelo nos d´ somente um ganho de cerca de uma ordem de magnitude em relacao
a
` ¸˜ ¸˜
a simulacao RTL. Ademais, os detalhes envolvidos na construcao do modelo precisam ser ex-
¸˜ ´
tra´dos da descricao RTL - um processo lento. Tampouco e interessante utilizar modelagem
ı
´ a ´
temporal, dado que apesar de ser bastante util para an´ lise de desempenho, n˜ o e preciso o
a
suficiente para que se possa iniciar a etapa de desenvolvimento de software.
¸˜
Nesse contexto surge a modelagem em n´vel transacional (TLM) - um estilo de descricao
ı
¸˜ a ¸˜ ´
onde os detalhes da comunicacao s˜ o abstra´dos em transacoes. O estilo TLM e um meio-termo
ı
a ¸˜
entre o modelo “bit-true“ com precis˜ o de ciclos e uma descricao algor´tmica (n˜ o temporizada).
ı a
¸˜ ´ a ´
A simulacao TLM e r´ pida, a interface dos componentes e “bit-true“ e o esforco de modelagem
¸
´
e razoavelmente pequeno.
´
A caracter´stica mais interessante de se utilizar um modelo TLM e que ele funciona como
ı
um modelo de referˆ ncia tanto para as equipes que desenvolvem software quanto para as equipes
e
que desenvolvem hardware de um sistema.
T˜ o logo o modelo esteja dispon´vel, o software pode comecar a ser desenvolvido (dada
a ı ¸
a interface “bit-true“ dos componentes do modelo) - ou seja, o ciclo de desenvolvimento de
´
software e trazido para as etapas iniciais do projeto.
Ao mesmo tempo que o software est´ sendo desenvolvido, a equipe de hardware pode
a
¸˜
trabalhar em uma descricao RTL do hardware. Quando ela finalmente for obtida, basta con-
a a ¸˜
front´ -la com o modelo TLM para valid´ -la. Ou seja, a utilizacao de uma plataforma TLM de
referˆ ncia torna poss´vel o co-projeto de software e hardware, reduzindo o tempo necess´ rio
e ı a
para disponibilizar o produto no mercado.
2.3 SYSTEMC
¸˜
O uso de linguagens de programacao convencionais para modelar componentes tanto de
hardware como de software tornaria poss´vel um ganho significativo de produtividade. Algumas
ı
das vantagens dessa abordagem s˜ o((BLACK; DONOVAN, 2004):
a

14. 13
• Exploracao de particionamento software/hardware
¸˜
• Verificacao funcional desde os primeiros est´ gios do projeto
¸˜ a
• Especificacao execut´ vel do sistema que se est´ projetanto
¸˜ a a
e o ¸˜
Entretanto, existem trˆ s raz˜ es principais pelas quais linguagens de programacao conven-
cionais s˜ o inadequadas para modelagem de componentes de hardware:
a
• Nocao de eventos sequenciados no tempo: N˜ o h´ uma nocao de tempo.
¸˜ a a ¸˜
• Concorrˆ ncia: Componentes de hardware s˜ o inerentemente concorrentes. Em geral,
e a
¸˜ a a
as linguagens de programacao n˜ o d˜ o suporte nativo a concorrˆ ncia.
e
• Tipos de dados inadequados de hardware: Faltam tipos de dados adequados para a
modelagem de hardware.
¸˜
Uma solucao encontrada para lidar com esses problemas foi extender a linguagem C++
¸˜ ¸˜
com uma biblioteca de classes e um “kernel“ de simulacao. O “kernel“ de simulacao introduz
¸˜ ¸˜
a nocao de tempo e a biblioteca possui os tipos de dados necess´ rios para a descricao de com-
a
e `
ponentes de hardware, al´ m de dar suporte a concorrˆ ncia. A essa estrutura de modelagem foi
e
dado o nome de SystemC.
SystemC foi anunciado em setembro de 1999 por um conjunto de companhias l´deres nos
ı
¸˜
setores de Automacao Eletrˆ nica de Projetos (EDA), propriedade intelectual (IP) e semicondu-
o
¸˜
tores. Por ser aberto, as empresas de EDA tem total acesso a sua implementacao, de modo que
¸˜
a construcao de ferramentas que operem sobre modelos funcionais descritos em SystemC fica
e ¸ ´ a `
f´ cil. Al´ m disso, nenhum tipo de licenca para uso e necess´ ria, tornando-o atrativo a ind´ stria.
a u
SystemC tem se mostrado uma boa alternativa para a modelagem em n´vel de sistema
ı
(ESL). Em especial, o estilo TLM foi recentemente padronizado e tem se mostrado bastante
¸˜
promissor para a diminuicao do “time-to-market“ e para o projeto concorrente de hardware e
software, conforme relatos da ind´ stria (GHENASSIA, 2005).
u
`
Para desenvolver um modelo, a infra-estrutura necess´ ria resume-se as ferramentas e ambi-
a
ente de desenvolvimento C++ da preferˆ ncia do projetista. Durante a escrita do modelo, basta
e
¸˜
incluir os headers (cabecalhos contendo a declaracao das classes que modelam os componen-
¸
¸˜ ´
tes) da biblioteca de SystemC nos arquivos-fonte. Na hora da compilacao e necess´ rio linkar o
a
¸˜
projeto com as classes pr´ -compiladas da biblioteca e com o kernel de simulacao do SystemC.
e

15. 14
Vale salientar a possibilidade de descrever diferentes componentes do sistema em diferentes
ı ¸˜ e
n´veis de abstracao (´ poss´vel ter componentes descritos em n´vel funcional, que especificam
ı ı
o que o componente deve fazer, cooperando com componentes descritos em n´vel RTL, que
ı
especificam como um componente realiza uma tarefa).
2.4 ˜
COMPRESSAO JPEG
O padr˜ o JPEG foi definido pelo Joint Photographic Experts Group no ano de 1992 e
a
rapidamente tornou-se uma referˆ ncia compress˜ o de imagens fotogr´ ficas. De acordo com
e a a
´
(AGOSTINI; SILVA; BAMPI, 2001), a compress˜ o de uma imagem para o formato JPEG e um
a
processo de cinco etapas:
• Convers˜ o do o espaco de cores:
a ¸ Convers˜ o do espaco de cores RGB (que possui
a ¸
apenas componentes de cor) para um espaco de cores do tipo luminˆ ncia e crominˆ ncia.
¸ a a
´ ¸˜
Isso e necess´ rio porque existe um grau elevado de correlacao entre as componentes R, G
a
e B, dificultando o processamento individual delas.
• Downsampling: O olho humano e menos sens´vel as informacoes de crominˆ ncia do
´ ı ` ¸˜ a
¸˜ ´
que de luminˆ ncia. Na etapa de downsampling, parte da informacao de crominˆ ncia e
a a
eliminada, com o intuito de aumentar a taxa de compress˜ o da imagem.
a
• DCT 2D: A transformada discreta do cosseno em duas dimens˜ es e utilizada para trans-
o ´
¸˜ ¸˜
formar a representacao da informacao do dom´nio espacial para o dom´nio das frequˆ ncias.
ı ı e
• Quantizacao: Nessa etapa, as frequˆ ncias mais elevadas s˜ o atenuadas ou at´ mesmo
¸˜ e a e
¸˜
eliminadas, uma vez que elas tendem a contribuir menos com a informacao da imagem.
• Codificacao de entropia: Consiste na aplicacao de um conjunto de t´ cnicas para com-
¸˜ ¸˜ e
press˜ o sem perdas nas matrizes de coeficientes j´ quantizados (resultado do passo an-
a a
¸˜
terior), de modo que seja obtida uma representacao com o menor n´ mero poss´vel de
u ı
bits.
Os dois primeiros passos n˜ o s˜ o necess´ rios quando se comprime imagens em preto e
a a a
branco.

16. 15
3 METODOLOGIA E
INFRAESTRUTURA
Neste cap´tulo trataremos da metodologia para desenvolvimento de IPs e tamb´ m da infra-
ı e
estrutura para plataformas TLM utilizadas nesse trabalho.
3.1 ¸˜
METODOLOGIA DE PROJETO E VALIDACAO
¸˜
Depois que se obt´ m a descricao de um componente de hardware, o passo seguinte - inde-
e
¸˜ ´
pendentemente do n´vel da descricao - e verificar que as funcionalidades e requisitos est˜ o de
ı a
acordo com o esperado. Gerar manualmente um conjunto de est´mulos e resultados - para ve-
ı
´
rificar a corretude do modelo - e extremamente trabalhoso e pouco produtivo, al´ m de bastante
e
prop´cio a erros.
ı
Para lidar com esse problema, usaremos o conceito de “golden model“. Um “golden mo-
´
del“ e um modelo de referˆ ncia que, garantidamente, possui as funcionalidades e cumpre os
e
requisitos previamente especificados.
´ ´ ¸˜
Portanto, no projeto de um componente de hardware, e util partir de uma descricao al-
ı a ¸˜
gor´tmica n˜ o temporizada - que modela funcionalidade. Essa descricao servir´ , posterior-
a
¸˜
mente, como “golden model“ para a verificacao funcional de modelos descritos em outros n´veis
ı
¸˜
de abstracao, como por exemplo TLM e RTL.
A figura 1 ajuda a explicar a metodologia apresentada. Est´mulos s˜ o utilizados para excitar
ı a
o modelo de referˆ ncia (“golden model“) e a plataforma. Uma vez que os resultados do pro-
e
´ ¸˜
cessamento est˜ o dispon´veis, e feita uma comparacao. Caso os resultados obtidos, tanto para a
a ı
plataforma quanto para o “golden model“ sejam iguais, significa que, para um dado est´mulo, a
ı
plataforma implementa as mesmas funcionalidades que o “golden model“. Caso contr´ rio, exis-
a
tem um ou mais erros na implementacao da plataforma. Assim que os erros forem corrigidos,
¸˜ ´ ¸˜
uma nova rodada de execucoes acontece e novamente e feita uma comparacao. Esse processo
´ e e ´
e repetido at´ que os resultados sejam idˆ nticos. E uma boa pr´ tica testar diferentes est´mulos
a ı

17. 16
¸˜
Figura 1: Metodologia de validacao utilizada
com grande variabilidade, ou seja, aumentar a abrangˆ ncia dos casos de teste.
e
3.2 INFRA-ESTRUTURA DE MODELAGEM DA PLATA-
FORMA
¸˜
Segundo (GHENASSIA, 2005, p. 63), o primeiro passo para um fluxo de projeto e verificacao
` ı ´ ¸˜ ¸˜
a n´vel de sistema e o uso de modelos cuja comunicacao foi modelada usando transacoes (TLM)
- uma vez que essa abordagem fomenta a reusabilidade.
Para facilitar o reuso, deve ser fornecida uma infraestrutura respons´ vel por organizar o
a
o ´
c´ digo-fonte e o gerenciamento de diferentes tipos de componentes. E recomend´ vel que cada
a
projeto seja organizado em uma hierarquia definida por diret´ rios, de modo que componentes
o
de tipos diferentes sejam alocados em diret´ rios diferentes.
o
Neste trabalho foi usada como base para a plataforma a infraestrutura fornecida pela ArchC
Reference Platform (ARP) 1 .
3.2.1 ARCHC REFERENCE PLATFORM - ARP
´ ¸˜
A ARP e um framework para a construcao de modelos de plataformas que usam simulado-
res ArchC 2.02 (AZEVEDO et al., 2005). Para tanto, e fornecida uma estrutura b´ sica composta
´ a
de espacos reservados para componentes comuns em modelos de plataformas heterogˆ neas e
¸ e
scripts pra construir e simular essas plataformas.
1 Mais ¸˜ ¸˜
informacoes em http://www.archc.org na secao Platforms.
2 Mais ¸˜
informacoes em: http://www.archc.org/

18. 17
IPs descritos em SystemC podem ser plugados na ARP e observados interagindo com outros
componentes (processadores, mem´ rias, outros IPs).
o
Plataformas seguindo o framework ARP s˜ o organizadas em diret´ rios, separando os di-
a o
ferentes tipos de componentes. Existem tamb´ m diret´ rios de apoio, como para os scripts da
e o
¸˜
ARP e documentacao. Os principais s˜ o:
a
• platforms Armazena as configuracoes das plataformas criadas pelo usu´ rio, incluindo
¸˜ a
seu arquivo execut´ vel.
a
• processors Para os simuladores gerados pelo ArchC.
• is Para estruturas de interconex˜ o, como barramentos.
a
• ip Blocos de propriedade intelectual.
• sw Cont´ m o c´ digo dos software embutido que rodar´ na plataforma.
e o a
• wrappers Armazena adaptadores entre os mais diversos tipos de componentes, e at´
e
¸˜
mesmo, diferentes n´veis de abstracao.
ı
3.2.2 ¸˜ ˜
MAPEAMENTO DA APLICACAO DE COMPRESSAO JPEG
PARA UMA PLATAFORMA ARP
Como j´ foi mencionado no cap´tulo 1, foi desenvolvida uma plataforma (descrita em
a ı
TLM) que realiza compress˜ o de “bitmaps“ para arquivos no formato JPEG. O mapeamento
a
¸˜ ´
da aplicacao compressora em uma plataforma ARP e ilustrado na figura 2.
Figura 2: Diagrama em blocos da plataforma
´
A plataforma e composta de um processador PowerPC (cujo simulador foi obtido a partir
`
de um modelo descrito em ArchC) interconectado pelo barramento SimpleBus a um bloco de

19. 18
mem´ ria simples bus fast mem, no qual o software de compress˜ o JPEG compilado para esse
o a
¸˜
processador, foi carregado. A descricao do processador n˜ o suporta a interface TLM do barra-
a
a a ¸˜
mento SimpleBus, portanto, foi necess´ rio um “wrapper“ que faz a convers˜ o das transacoes.
`
Tamb´ m foi plugado a plataforma um IP que implementa parte da funcionalidade do soft-
e
ware (mais detalhes no cap´tulo 4), cujos registradores s˜ o mapeados em mem´ ria. O software
ı a o
foi modificado para utilizar a funcionalidade do IP.
¸˜ ´
A configuracao da plataforma descrita acima e especificada atrav´ s do arquivo defs.arp
e
dentro do diret´ rio da plataforma na hierarquia da ARP, cujo conte´ do apresenta-se na tabela 1.
o u
IP := sb forward DCT
IS := simple bus ua
PROCESSOR := powerpc
SW := cjpeg
WRAPPER := ac.simple bus ua.01
¸˜
Tabela 1: Conte´ do do arquivo de f s.arp mostrando a configuracao da plataforma
u

20. 19
4 PROJETO DO IP
Nesse cap´tulo trataremos do “profiling“ realizado no algoritmo de compress˜ o JPEG, bem
ı a
¸˜ ¸˜
como da selecao da funcionalidade do IP que foi implementado, al´ m da integracao do mesmo
e
numa plataforma TLM.
4.1 ¸˜
SELECAO DO IP
Para definirmos a funcionalidade do software que o IP implementaria realizamos um “pro-
filing“ do software de compress˜ o JPEG inclu´do no benchmark MiBench usando a ferramenta
a ı
gprof.
4.1.1 ¸˜ ˜
IMPLEMENTACAO DE COMPRESSAO JPEG NO MIBENCH
O MiBench1 (GUTHAUS et al., 2001) e um benchmark gratuito organizado em grupos
´
de programas (automotivo, rede, consumidor e outros). Dentro do grupo consumidor est´ a
a
¸˜
implementacao do compressor JPEG (release 6a, de 07 de fevereiro de 1996, do “The Indepen-
¸˜ ¸˜
dent JPEG Group”). Essa implementacao foi utilizada tanto para a definicao do IP quanto para
¸˜
a validacao (“golden model“).
4.1.2 A FERRAMENTA GPROF
´ ¸˜
O gprof e o profiler que comp˜ e o GNU Binary Utilities (colecao de ferramentas utilizadas
o
¸˜ o a ´
para manipulacao de c´ digo em v´ rios formatos mantido pela GNU). Com ele e poss´vel veri-
ı
¸˜
ficar quantas vezes e quais funcoes est˜ o sendo chamadas, al´ m do tempo gasto em cada uma
a e
¸˜ ¸˜
e a porcentagem correspondente ao total do tempo de execucao, facilitando a identificacao de
gargalos de processamento no c´ digo.
o
1 Mais ¸˜
informacoes em http://www.eecs.umich.edu/mibench/

21. 20
4.1.3 ¸˜
“PROFILING“ E SELECAO
¸˜
O “profiling“ da aplicacao de compress˜ o JPEG foi realizado principalmente em cima das
a
¸˜
figuras 13, 14, 15 e 16, apresentadas no anexo A, p´ g. 38. As figuras possuem grande variacao
a
¸˜
de tamanho e configuracao (conforme tabela 11, do mesmo anexo), de modo a garantir que
a a ¸˜
os resultados da an´ lise n˜ o sejam facilmente influenciados por condicoes criadas a partir das
caracter´sticas de uma determinada imagem.
ı
¸˜ ¸˜
As tabelas 2, 3, 4 e 5 mostram as funcoes mais chamadas durante a execucao do aplicativo
para algumas das figuras, resultado este extra´do do “profiling“ realizado com o gprof. J´ a
ı a
tabela 6 mostra um sum´ rio de todos os profilings realizados, e tamb´ m foi gerado pelo gprof.
a e
´
O significado de cada coluna da tabela e mostrado a seguir:
• % time: A porcentagem de tempo usada pela funcao com relacao ao tempo total.
¸˜ ¸˜
• self seconds: O tempo que a funcao levou para executar.
¸˜
• calls: O n´ mero de vezes que a funcao foi chamada.
u ¸˜
• self {s, ms, us}/call: A m´ dia de tempo (em segundos, milissegundos ou microsegun-
e
¸˜
dos) gasta em cada chamada da funcao, n˜ o levando em conta o tempo gasto por seus
a
¸˜
descendentes (as funcoes chamadas por esta).
• total {s, ms, us}/call: A m´ dia de tempo (em segundos, milissegundos ou microsegun-
e
¸˜
dos) gasta em cada chamada da funcao, incluindo seus descendentes.
• name: O nome da funcao.
¸˜
¸˜ `
Analisando as tabelas, percebem-se quatro funcoes que se destacam como candidatas a te-
rem suas funcionalidades implementadas em um IP. S˜ o elas: rgb ycc convert, encode mcu hu f f ,
a
f orward DCT e jpeg f dct islow. As duas primeiras s˜ o, a priori, boas candidatas, por´ m,
a e
¸˜ ¸˜
analisando-se o fluxo de execucao, percebe-se que as funcoes f orward DCT e jpeg f dct islow
a a ¸˜ ´
s˜ o, respectivamente, m˜ e e filha, e ainda que a funcao jpeg f dct islow e ’folha’, ou seja, n˜ o
a
´
e chamada por mais ningu´ m.
e
¸˜
Embutindo o c´ digo da funcao jpeg f dct islow dentro de f orward DCT obtemos uma
o
¸˜
funcao que consome aproximadamente 36% do tempo de processamento, o que a torna uma
¸˜ ´ ¸˜ ´ ´
melhor candidata do que as duas funcoes anteriores. O unico problema desta funcao e que ela e
chamada muitas vezes, o que pode gerar um gargalo dependendo da velocidade do barramento,

22. 21
Tabela 2: “Profiling“ do aplicativo cjpeg para a figura 13, 192Kb
% self self total
time seconds calls ms/call ms/call name
0.00 0.00 1536 0.00 0.00 jpeg fdct islow
0.00 0.00 1024 0.00 0.00 forward DCT
0.00 0.00 625 0.00 0.00 emit byte
0.00 0.00 384 0.00 0.00 expand right edge
0.00 0.00 271 0.00 0.00 pre process data
Tabela 3: “Profiling“ do aplicativo cjpeg para a figura 14, 768Kb
% self self total
time seconds calls us/call us/call name
50.00 0.01 6144 1.63 1.63 jpeg fdct islow
50.00 0.01 512 19.53 19.53 rcc ycc convert
0.00 0.00 4096 0.00 0.00 forward DCT
0.00 0.00 1024 0.00 0.00 encode mcu huff
0.00 0.00 768 0.00 0.00 expand right edge
Tabela 4: “Profiling“ do aplicativo cjpeg para a figura 16, 20Mb
% self self total
time seconds calls ms/call ms/call name
38.99 0.23 3000 0.08 0.08 rgb ycc convert
27.12 0.16 28200 0.01 0.01 encode mcu huff
18.65 0.11 112650 0.00 0.00 forward DCT
6.78 0.04 168900 0.00 0.00 jpeg fdct islow
5.09 0.03 3000 0.01 0.01 h2v2 downsample
Tabela 5: “Profiling“ do aplicativo cjpeg para a figura 16, 183Mb
% self self total
time seconds calls ms/call ms/call name
29.94 1.44 1000000 0.00 0.00 forward DCT
27.86 1.34 250000 0.01 0.01 encode mcu huff
20.58 0.99 8000 0.12 0.12 rgb ycc convert
17.26 0.83 1500000 0.00 0.00 jpeg fdct islow
3.53 0.17 8000 0.02 0.02 h2v2 downsample
Tabela 6: Sum´ rio dos “profilings“ realizados sobre o aplicativo cjpeg
a
% self self total
time seconds calls ms/call ms/call name
31.19 2.96 22844 0.13 0.13 rgb ycc convert
28.03 2.66 501213 0.01 0.01 encode mcu huff
24.76 2.35 2004420 0.00 0.00 forward DCT
11.59 1.10 3005851 0.00 0.00 jpeg fdct islow
3.48 0.33 22844 0.01 0.01 h2v2 downsample

23. 22
a u ¸˜ ´ a e ´
j´ que um grande n´ mero de transacoes e necess´ rio. Essa potencial desvantagem, por´ m, e su-
¸˜
perada pela maior perspectiva de reuso, pois esta funcao implementa uma transformada discreta
´ ¸˜
do cosseno bi-dimensional - DCT-2D -, que e usada para v´ rias aplicacoes, principalmente do
a
¸˜
tipo multim´dia, o que aumenta as chances de reusabilidade do IP. Por isso, escolheu-se a funcao
ı
f orward DCT e sua filha jpeg f dct islow para serem aceleradas em hardware, na forma de um
bloco de propriedade intelectual.
4.2 MODELAGEM FUNCIONAL DO IP NA PLATA-
FORMA TLM
¸˜ ¸˜ ¸˜
Como mencionado na secao 4.1.3, a funcao f orward DCT foi escolhida para implementacao.
¸˜
Esta funcao faz um pr´ -processamento nos valores de entrada, chama o m´ todo jpeg f dct islow,
e e
¸˜ ¸˜
para efetivamente realizar a DCT, e finalmente faz a quantizacao e diminuicao de escala dos co-
¸˜ ´
eficientes da DCT. O prot´ tipo da funcao e o seguinte:
o
forward DCT (j compress ptr cinfo, jpeg component info
*compptr, SAMPARRAY sample data, JBLOCKROW coef blocks,
JDIMENSION start row, JDIMENSION start col, JDIMENSION
num blocks);
Os parˆ metros recebidos s˜ o, em geral, ponteiros para estruturas de dados nas quais os da-
a a
¸˜
dos a serem processados se encontram. Uma explicacao mais detalhada sobre estes se encontra
¸˜
na secao 4.2.2.
¸˜
A funcao f orward DCT foi transformada num m´ dulo SystemC, conforme mostra a figura
o
3. A figura mostra as entradas e sa´das e tamb´ m o mapeamento de E/S em mem´ ria do m´ dulo,
ı e o o
¸˜
que ser˜ o mostrados em detalhes nas secoes 4.2.1 e 4.2.2, respectivamente. O bloco FDCT-2D,
a
a a ¸˜
que ser´ transformado em IP ser´ demonstrado na secao 4.4, p´ g. 30.
a
4.2.1 ´ ´
ENTRADAS E SAIDAS DO MODULO FORWARD DCT
O m´ dulo f orward DCT possui um total de 64 pinos. Todos s˜ o utilizados tanto para
o a
entrada como para sa´da, e s˜ o divididos em dois sinais de 32 pinos cada, conforme demonstram
ı a
a tabela 7 e a figura 3.

24. 23
Figura 3: M´ dulo forward DCT
o
Tabela 7: Entradas e sa´das do m´ dulo forward DCT
ı o
Sinal Pinos ¸˜
Descricao
DATA 32 Um valor lido da mem´ ria ou
o
um valor a ser escrito nela
ADDRESS 32 O endereco que dever´ ser
¸ a
lido ou escrito na mem´ ria
o
´ ´
4.2.2 MAPEAMENTO DE E/S EM MEMORIA DO MODULO
FORWARD DCT
o e ¸˜
O m´ dulo f orward DCT possui oito registradores de 32 bits cada. Sete destes tˆ m relacao
¸˜
direta com a funcao f orward DCT , apresentada acima, pois representam os parˆ metros da
a
a ´ ´
mesma. J´ o ultimo e um registrador de controle do m´ dulo. Segue abaixo o nome de cada
o
registrador, seu respectivo tipo - (E) para entrada, (S) para sa´da e (E/S) para entrada e sa´da -,
ı ı
¸˜
e uma breve descricao:
• cinfo (E): Ponteiro para uma “struct“ do tipo j compress ptr que cont´ m diversas
e
¸˜
informacoes utilizadas durante a compress˜ o da imagem, como: largura e altura da ima-
a
` ¸˜
gem, n´ mero de componentes de cor, parˆ metros relacionados a otimizacao e qual o
u a
e ´
m´ todo de DCT desejado, que e o dado que realmente importa para n´ s.
o
• compptr (E): Ponteiro do tipo jpeg component info* para uma estrutura que cont´ m
e
¸˜ `
informacoes relacionadas a um componente (canal de cor) da imagem tais como: identi-
ficador do componente, n´ mero de amostras de um bloco de DCT e um ponteiro para a
u
¸˜
tabela de quantizacao que ser´ utilizada ap´ s o c´ lculo da DCT.
a o a

25. 24
• sample data (E): Ponteiro para array bidimensional, tipo JSAMPARRAY, com as amos-
tras de entrada.
• coef blocks (E/S): Ponteiro do tipo JBLOCKROW para um bloco de coeficientes. Tamb´ m
e
´
e usado como sa´da do m´ dulo, onde os coeficientes de resultado da transformada discreta
ı o
do cosseno j´ quantizados e em sua escala normal s˜ o colocados.
a a
• start row (E): Inteiro que representa a linha inicial, na matriz sample data, do bloco
de valores para os quais ser´ calculado a DCT.
a
• start col (E): Inteiro que representa a coluna inicial, na matriz sample data, do bloco
de valores para os quais ser´ calculado a DCT.
a
• num blocks (E): N´ mero de elementos que comp˜ em a linha de um bloco.
u o
• control (E/S): Vari´ vel inteira de controle. Deve valer 1 quando o processamento deve
a
iniciar. Ap´ s o t´ rmino do processamento, o pr´ prio m´ dulo ir´ set´ -la com valor 0,
o e o o a a
indicando o fim do processamento.
Como os registradores s˜ o mapeados em mem´ ria, para cada registrador foi alocado um
a o
determinado endereco. Os “offsets“ podem ser observados na tabela 8. Tendo em vista que s˜ o
¸ a
¸ ¸ ´
8 registradores de 32 bits cada, a faixa de enderecos (o endereco do ultimo registrador menos o
endereco-base) reservada para o IP n˜ o pode ser menor do que 0x20.
¸ a
¸˜
Tabela 8: Registradores do IP - “Offsets“ com relacao ao endereco-base e tipo
¸
Endereco Registrador
¸
0x00 cinfo
0x04 compptr
0x08 sample data
0x0C coef blocks
0x10 start row
0x14 start col
0x18 num blocks
0x1C control
o a ¸˜
O funcionamento do m´ dulo se d´ da seguinte forma: todos os registradores (com excecao
do registrador control) s˜ o carregados com seus respectivos valores. A carga d´ -se colocando
a a
escrevendo o valor desejado no respectivo endereco (o que se traduz em colocar o valor no sinal
¸
DATA e o endereco no sinal ADDRESS), e geralmente ser´ feita pelo software que chamar´
¸ a a
o o ´
o m´ dulo. Ap´ s a carga de todos os registradores, o registrador control e setado com valor 1
´
e o m´ dulo inicia o processamento. Assim que ele terminar seu trabalho, o valor de control e
o

26. 25
setado pelo pr´ prio m´ dulo para 0, e o software que ficava aguardando este valor via “pooling“
o o
pode continuar.
¸ ˜
4.2.3 MODELAGEM DAS TRANSACOES
O IP desenvolvido precisa atuar tanto como mestre quanto como escravo do barramento ao
qual est´ conectado (SimpleBus). Isso porque o processador escrever´ valores nos registradores
a a
do IP (IP atua como escravo) e o IP ler´ e escrever´ valores na mem´ ria como resultado de seu
a a o
processamento (IP atua como mestre).
IP COMO ESCRAVO DO BARRAMENTO
Para que o IP atue como escravo do barramento, o modelo foi declarado como uma sub-
classe de simple bus slave if, cuja declaracao aparece na figura 4.
Figura 4: A interface simple bus slave if
¸˜
A classe simple bus slave if cont´ m um conjunto de funcoes puramente virtuais que preci-
e
sam ser implementadas por componentes que devem atuar como escravos do barramento Sim-
pleBus.
¸˜
As funcoes start address e end address retornam o endereco base e o endereco final, res-
¸ ¸
pectivamente, da faixa de mem´ ria aonde os registradores do IP foram mapeados.
o
¸˜
As funcoes read e write s˜ o utilizadas pelo barramento SimpleBus para ler e escrever dados
a
´
nos registradores do IP. Elas recebem como parˆ metros um ponteiro para uma area de dados e
a
um endereco de mem´ ria.
¸ o
¸˜ ¸˜ e ´
A implementacao feita para o IP da funcao read pode ser vista na figura 5. A id´ ia e
simples, primeiro se descobre de qual registrador de dados os dados devem ser lidos (atrav´ s
e

27. 26
´
do argumento address) e depois copia-se o valor desse registrador para a area apontada pelo
ponteiro data.
¸˜ ¸˜
Figura 5: Implementacao da funcao read
¸˜ ¸˜ ´
No caso da funcao write (cuja implementacao e mostrada na figura 6, os dados s˜ o copia-
a
´
dos da area apontada pelo ponteiro data para o registrador (selecionado atrav´ s do argumento
e
´
address). Al´ m disso, caso o registrador de controle receba o valor 1, o evento wakeup e notifi-
e
cado, o que faz com que o IP inicie o seu processamento.

28. 27
¸˜ ¸˜
Figura 6: Implementacao da funcao write
IP COMO MESTRE DO BARRAMENTO
´
Para que o IP atue como mestre do barramento, e necess´ rio adicionar ao modelo um atri-
a
buto do tipo sc port<simple bus blocking if>.
Posteriormente, na hora de instanciar a plataforma, esse atributo precisa ser ’ligado’ a um
¸˜
canal de comunicacao (que no caso ser´ o barramento SimpleBus) que implemente as funci-
a

29. 28
´
onalidades descritas pela interface simple bus blocking if - cujo c´ digo e mostrada na figura
o
7.
Figura 7: A interface simple bus blocking if
4.3 ¸˜
A INSTANCIACAO DE COMPONENTES NA PLATA-
FORMA
a o ´
Parte do arquivo main.cpp - onde est´ o c´ digo para instanciar a plataforma TLM, e mos-
trado na figura 8.
Nas linhas 7 e 10 s˜ o instanciados o processador PowerPC e o “wrapper“ que torna poss´vel
a ı
a conex˜ o com o barramento SimpleBus, respectivamente.
a
a e ´
Nas linhas 13 e 14 s˜ o instanciados o barramento SimpleBus e tamb´ m o arbitro do mesmo.
Nas linhas 17, 18 e 19 s˜ o instanciados dois blocos de mem´ ria e tamb´ m o IP que im-
a o e
¸˜
plementa a funcao f orward DCT . Dentre os argumentos passados para os construtores est˜ o o
a
nome dos componentes e tamb´ m as faixa de enderecos reservados no espaco de enderecamento.
e ¸ ¸ ¸
A partir da linha 22, s˜ o feitas as conex˜ es entre os componentes da plataforma. O clock
a o
´
e o arbitro s˜ o atribu´dos ao barramento. Os dois blocos de mem´ ria e o IP s˜ o conectados em
a ı o a
portas de escravo do barramento.
´
Na linha 28, o atributo do tipo sc port<simple bus blocking if> do IP(que e utilizado para
´
que ele atue como mestre do barramento) e conectado ao barramento.
´
Na linha 32, o software (previamente compilado) e carregado na mem´ ria. Depois o pro-
o
´ ´ ¸˜
cessador e inicializado. A linha 39 e respons´ vel pelo in´cio da simulacao.
a ı

30. 29
Figura 8: Trecho do c´ digo de main.cpp
o

31. 30
4.4 MODELAGEM RTL DO IP
Ap´ s an´ lise mais detalhada do IP em n´vel funcional, percebemos que o mesmo era es-
o a ı
pec´fico demais. Todos os registradores de entrada est˜ o intimamente relacionados com o
ı a
c´ digo do JPEG, e al´ m disso as funcionalidades do IP v˜ o al´ m do c´ lculo da DCT, devido ao
o e a e a
e ¸˜
pr´ -processamento e a quantizacao tamb´ m realizados. A parte do IP que realmente implementa
e
´ ¸˜
uma DCT-2D gen´ rica e a parte equivalente ao c´ digo da funcao jpeg f dct islow.
e o
¸˜
Ap´ s pesquisa sobre o funcionamento de uma DCT bi-dimensional e comparacao de algu-
o
mas arquiteturas propostas na literatura (BHASKARAN; KONSTANTINIDES, 1999), optamos
pela arquitetura apresentada na figura 9, proposta por (AGOSTINI, 2002). Esta baseia-se numa
propriedade desta transformada, o princ´pio da separabilidade, que mostra que o c´ lculo pode
ı a
ser realizado atrav´ s de duas 2 DCTs unidimensionais, a primeira sobre as linhas da matrix
e
8x8 e a segunda sobre as colunas da matriz resultante da primeira. O componente denominado
¸˜ ´
“buffer de transposicao“ e quem permitir´ que a segunda transformada opere sobre as colunas
a
da matriz.
Figura 9: Arquitetura RTL do IP.
Fonte: (AGOSTINI, 2002)
¸˜
A modelagem em RTL da DCT-2D est´ em andamento. Mais informacoes podem ser en-
a
¸˜
contradas na secao 6.1.

32. 31
5 RESULTADOS EXPERIMENTAIS
ı ¸˜
Este cap´tulo apresenta os resultados experimentais e a configuracao necess´ ria para repro-
a
duz´-los.
ı
5.1 ¸˜
CONFIGURACAO EXPERIMENTAL
¸˜
O computador utilizado para a obtencao dos resultados aqui demonstrados possui a se-
¸˜
guinte configuracao: processador Intel Core Duo, 1.66GHz de frequˆ ncia, cache L2 de 2 MB e
e
667MHz de FSB; mem´ ria principal de 2 GB; e roda sistema operacional GNU/Linux Ubuntu
o
7.04, kernel 2.6.20 SMP.
As ferramentas usadas durante o processo, e suas respectivas vers˜ es, est˜ o listadas abaixo:
o a
• ArchC , vers˜ o 2.0;
a
• SystemC , vers˜ o 2.2.0;
a
• SystemC TLM , vers˜ o 1.0 (2005-04-08);
a
• Compilador GCC , vers˜ o 4.1.2;
a
• Cross-compiler GCC para PowerPC , vers˜ o 3.1;
a
• cjpeg , vers˜ o 6a (07 de fevereiro de 1996), do The Independent JPEG Group - IJG.
a
¸˜
Al´ m disso, o modelo funcional de PowerPC integrado na plataforma, conforme secao
e
´
3.2.2 e a vers˜ o 0.7.3, para o ArchC 2.0. O software de compress˜ o JPEG que roda em cima
a a
deste modelo foi compilado com o “cross-compiler“. Tanto o modelo do processador quanto o
compilador cruzado est˜ o dispon´veis na p´ gina do projeto ArchC.
a ı a

33. 32
5.2 ¸˜
VALIDACAO DO IP FUNCIONAL NA PLATAFORMA
¸˜ ¸˜
A metodologia utilizada para a validacao do IP foi descrita na secao 3.1. Os seguintes
insumos foram utilizados:
• Est´mulos : Figuras 11, 12, 13, 14, 15, 17.
ı
• “golden model“ : Implementacao para compress˜ o JPEG do benchmark MiBench.
¸˜ a
• Utilit´ rio diff : Utilit´ rio que compara dois arquivos bit a bit.
a a
Para cada uma das figuras listadas, a plataforma e o “golden model“ foram executados. Os
arquivos de sa´da (imagens comprimidas em JPEG) foram comparados com o utilit´ rio diff -
ı a
o que garante que as sa´das s˜ o rigorosamente iguais. V´ rias imagens foram utilizadas para
ı a a
garantir uma certa variabilidade dos vetores de entrada, aumentando, assim, a confiabilidade do
¸˜
processo de validacao.
5.3 ¸˜ ¸˜
COMPARACAO DE TEMPOS DE EXECUCAO ENTRE
PLATAFORMA E SOFTWARE
¸˜
Naturalmente, a execucao da plataforma para comprimir imagens leva muito mais tempo
¸˜ ¸˜
do que a execucao de um software qualquer que realiza a mesma funcao. Entretanto, achamos
´
interessante mensurar de quantas ordens de grandeza e essa diferenca.
¸
¸˜
A tabela 9 compara os tempos de execucao da plataforma desenvolvida com os tempos
¸˜
do software cjpeg. Por exemplo, para a figura mibench large, a execucao da plataforma levou
¸˜
132,94 segundos, enquanto que a execucao do software levou apenas 0,020 segundos.
´
Indice da Nome da Tempo
Figura Imagem Plataforma Software
11 boy 36.23s 0.012s
12 jpeg testimg 21.16s 0.008s
15 mediabench 196.71s 0.052s
14 mibench large 132.94s 0.020s
13 mibench small 36.86s 0.008s
17 ufsc ctc 283.34s 0.052s
´
SOMATORIO 707.24s 0.152s
TOTAL 707.572s
¸˜ ¸˜
Tabela 9: Comparacao de tempos de execucao: plataforma x software

34. 33
¸˜ ´
Como se pode perceber, o tempo de execucao da plataforma e muito superior, algo em
`
torno de 3 a 4 ordens de grandeza. Buscamos, ent˜ o, identificar o porquˆ dessa diferenca t˜ o
a e ¸ a
¸˜
grande. Para tanto, executamos um “profiling“ da execucao da plataforma desenvolvida sobre
as mesmas figuras da tabela 9 e, finalmente, um sum´ rio desses seis “profilings“, de maneira
a
¸˜
an´ loga ao procedimento descrito na secao 4.1.3.
a
Parte do resultado deste “profiling“ est´ demonstrado na tabela 10, que relaciona as cinco
a
¸˜ ¸˜
funcoes mais chamadas durante as simulacoes com suas respectivas porcentagens sobre o tempo
¸˜
total e o tempo gasto em cada uma. Analisando a tabela, percebe-se que estas funcoes, sozinhas,
s˜ o respons´ veis por mais da metade do tempo de processamento. Tamb´ m pode-se notar que
a a e
a maior parte do tempo consumido pelas mesmas est´ relacionado com o SystemC, o que pode
a
¸˜
ser notado pelo namespace sc core no in´cio do nome das funcoes.
ı
Porcentagem Tempo Nome da
do tempo gasto (s) ¸˜
Funcao
19.74 107.58 sc core::sc event::trigger()
18.01 98.16 sc core::sc simcontext::crunch()
7.29 39.74 sc core::sc simcontext::simulate(sc core::sc time const&)
3.83 20.89 powerpc::behavior()
3.07 16.71 sc core::wait(sc core::sc time const&,sc core::sc simcontext*)
51.94 283.08 TOTAL
¸˜
Tabela 10: Sum´ rio dos “profilings“realizados durante execucao da plataforma
a
¸˜
Realizando esta separacao por namespaces em todo o sum´ rio, pudemos chegar ao gr´ fico
a a
¸˜
da figura 10. Ele nos mostra como o tempo gasto na execucao na plataforma est´ distribu´do.
a ı
´ ¸˜
Como pode-se perceber, em torno de 74% do tempo e gasto com funcoes do “kernel“ de
¸˜ ¸˜
simulacao e componentes da biblioteca do SystemC. Chamadas a funcoes do modelo do barra-
¸˜
mento SimpleBus ficam em torno de 11%. Outros 5% s˜ o gastos na simulacao do processador
a
PowerPC (mais 2% s˜ o gastos com o “wrapper“do processador). O resto do tempo (represen-
a
´ ¸˜
tado pela categoria Outros) e gasto com a simulacao do IP f orward DCT , biblioteca STL do
C++ al´ m de um pequeno overhead relacionado ao uso de TLM.
e
¸˜
Esses resultados deixam claro que existe muito a ser feito no que diz respeito a otimizacoes
¸˜ ¸˜ ´
na execucao das simulacoes, dado que a maior parte do tempo e gasta para se prover a infra-
a ¸˜
estrutura necess´ ria para a execucao do c´ digo dos modelos.
o

35. 34
¸˜ ¸˜
Figura 10: Distribuicao do tempo gasto na execucao da plataforma

36. 35
6 ˜
CONCLUSAO
¸˜
A utilizacao de modelagem em n´vel transacional parece indubitavelmente fundamental
ı
para que se lide com a crescente complexidade dos sistemas projetados e prazos cada vez mais
¸˜
apertados. TLM parece ter identificado o n´vel correto de abstracao para que se possa realizar o
ı
co-projeto de hardware e software, uma vez que a modelagem toma pouco tempo - se compa-
rado ao tempo total do projeto, e mesmo assim os resultados s˜ o precisos o suficiente para que o
a
desenvolvimento de software possa ser antecipado, executando-o em um modelo supostamente
preciso do futuro hardware.
O uso se TLM se torna particularmente interessante quando fazemos uso de outra aborda-
¸ u ¸˜
gem ganhando espaco na ind´ stria - o projeto baseado em plataforma. Modelar a comunicacao
¸˜
como transacoes torna mais f´ cil integrar novos componentes a um projeto gen´ rico - uma pla-
a e
¸˜ ´
taforma, de modo que a exploracao do espaco do projeto e favorecida devido ao grande n´ mero
¸ u
¸˜
de variacoes que podem ser testadas.
Juntas, as duas t´ cnicas mencionadas proporcionam um significativo ganho de produti-
e
vidade, conforme pode ser comprovado durante o desenvolvimento do IP e tamb´ m da sua
e
¸˜
integracao na plataforma descrita em TLM.
6.1 TRABALHOS FUTUROS
` ¸˜
Como trabalhos futuros, objetivamos chegar a uma descricao RTL do IP proposto em 4.4.
Para atingirmos este objetivo, modelaremos cada componente descrito na arquitetura da figura
9 tamb´ m em n´vel de transferˆ ncia de registradores.
e ı e
¸˜
Para tanto, cada componente passar´ pelo mesmo processo de projeto e validacao descrito
a
neste trabalho. Primeiramente ser´ gerado um “golden model“ e um IP descrito em n´vel fun-
a ı
cional para cada bloco. As sa´das dos dois ser˜ o confrontadas para que o IP seja considerado
ı a
validado. E ent˜ o ser˜ o estudadas poss´veis arquiteturas e a que apresentar as caracter´sticas
a a ı ı
mais atraentes ser´ escolhida para descer o n´vel de cada componente para RTL.
a ı

37. 36
a ¸˜
O maior grau de dificuldade estar´ na implementacao da DCT 1D, que envolver´ uma
a
¸˜
grande quantidade de somas e multiplicacoes. Portanto, dever´ ser escolhida uma arquitetura
a
¸˜ `
eficiente em velocidade de processamento - dado que boa parte das aplicacoes candidatas a uso
ı u ı o ¸˜
do IP s˜ o do tipo multim´dia, como compressores de a´ dio e v´deo, e imp˜ e restricoes de tempo
a
¸˜ ´
real -, mas n˜ o deixando de lado a preocupacao com o tamanho de area utilizado.
a

38. 37
ˆ
REFERENCIAS
AGOSTINI, L. V. Projeto de Arquiteturas Integradas para a Compress˜ o de Imagens JPEG.
a
¸˜
Dissertacao (Mestrado) — UFRGS, mar 22 2002.
AGOSTINI, L. V.; SILVA, I. S.; BAMPI, S. Pipelined fast 2-D DCT architecture for JPEG
image compression. 2001.
ARP. ArchC Reference Platform. Dispon´vel em: <http://www.archc.org/>.
ı
AZEVEDO, R. et al. The ArchC architecture description language and tools. International
Journal of Parallel Programming, Kluwer Academic Publishers, v. 33, n. 5, p. 453–484,
October 2005. ISSN 0885-7458.
BHASKARAN, V.; KONSTANTINIDES, K. Image and Video Compression Standards:
Algorithms and architectures. [S.l.]: Kluwer Academic Publishers, 1999.
BLACK, D.; DONOVAN, J. SystemC From the ground up. [S.l.]: Springer, 2004.
GHENASSIA, F. Transaction-Level Modeling with SystemC: TLM concepts and applications
for embedded systems. [S.l.]: Springer, 2005.
GUTHAUS, M. et al. MiBench: A free, commercially representative embedded benchmark
suite. In: . [S.l.: s.n.], 2001. p. 3–14.
LEE, C.; POTKONJAK, M.; MANGIONE-SMITH, W. H. MediaBench: A tool for evaluating
and synthesizing multimedia and communicatons systems. In: International Symposium on
Microarchitecture. [S.l.: s.n.], 1997. p. 330–335.
MARTIN, G.; CHANG, H. Winning the SOC Revolution: Experiences in real design. [S.l.]:
Kluwer Academic Publishers, 2003.
MARWEDEL, P. Embedded system design. [S.l.]: Springer, 2006.
SANGIOVANNI-VINCENTELLI, A. et al. Benefits and challenges for platform-based design.
In: Proceedings of the 41st Annual conference on Design Automation (DAC-04). New York:
ACM Press, 2004. p. 409–414.
SANGIOVANNI-VINCENTELLI, A. L.; MARTIN, G. Platform-based design and software
design methodology for embedded systems. IEEE Design & Test of Computers, v. 18, n. 6, p.
23–33, 2001.