Listagem 6.3: Arquivo defs.arp da plataforma com o Theora.
1 IP :=
2 IS := s i m p l e b u s u a 3 PROCESSOR := powerpc 4SW := theora mem mapped
5WRAPPER := s i m p l e b u s u a . t h e o r a a c m i x . 0 1 ac . s i m p l e b u s u a . 0 1
Altera¸c˜oes no processador PowerPC
O processador PowerPC original, dispon´ıvel no site do ArchC [32] n˜ao possui suporte a execu¸c˜ao de instru¸c˜oes de ponto flutuante. Assim, foi necess´ario acrescentar o conjunto de instru¸c˜oes de ponto flutuante ao processador para que o mesmo fosse capaz de executar o c´odigo compilado.
Esse procedimento foi executado obtendo-se o c´odigo Assembly do programa que gera a FFT e conferindo as instru¸c˜oes de ponto flutuante n˜ao implementadas. Com esse con- junto definido, implementaram-se as instru¸c˜oes seguindo o manual de referˆencia do ISA (instruction set architecture) do PowerPC [17].
6.2.2
Theora
O projeto Theora Hardware [12] foi criado por alunos do IC-Unicamp com o objetivo de fazer um decodificador de MPEG-4 em hardware. Esse decodificador trabalha com arquivos no formato Ogg-Theora e se baseou na biblioteca Theora criada pela funda¸c˜ao Xiph.Org [38].
A plataforma Theora utiliza um processador PowerPC convencional ligado ao barra- mento simple bus, o qual est´a ligado ao decodificador de MPEG-4 Theora mencionado acima. A organiza¸c˜ao dessa pataforma ´e exibida na figura 6.3 e no arquivo defs.arp ´e reproduzido na listagem 6.3.
6.3
Simula¸c˜ao da plataforma na ferramenta Model-
Sim
Como as plataformas de exemplo n˜ao podem ser simuladas diretamente no ModelSim, seguiram-se as instru¸c˜oes do manual do ModelSim [1] para torn´a-las compat´ıveis. As se¸c˜oes seguintes, adaptadas do manual, detalham o processo de convers˜ao e as restri¸c˜oes do ModelSim para a mesma.
6.3. Simula¸c˜ao da plataforma na ferramenta ModelSim 61
Figura 6.3: Rela¸c˜ao entre os componentes da plataforma Theora Observe que os componentes est˜ao ligados utilizando-se interfaces TLM.
6.3. Simula¸c˜ao da plataforma na ferramenta ModelSim 62
6.3.1
Limita¸c˜oes no uso de m´odulos VHDL para a co-simula¸c˜ao
com SystemC
Para co-simular uma design unit3 (m´odulo VHDL) dentro de um projeto SystemC, os
seguintes crit´erios tem que ser atendidos:
• A design unit ´e composta por um par entity/architecture ou ´e uma configuration • As portas tem que ser do tipo bit, bit vector, std logic, std logic vector,
std ulogic, std ulogic vector ou um de seus subtipos.
6.3.2
Cria¸c˜ao do foreign module
Para co-simular um design unit (m´odulo VHDL) dentro de um projeto SystemC, o Mo- delSim exige a cria¸c˜ao de um m´odulo stub SystemC que ´e chamado de foreign module.
Apesar de ser poss´ıvel cri´a-lo manualmente, um gerador autom´atico do stub ´e forne- cido juntamente com no ModelSim, tornando a tarefa um simples executar do comando scgenmod <nome da entity VHDL>, ap´os o passo de an´alise.
Com o foreign module gerado, pode-se instanci´a-lo assim como outro m´odulo SystemC qualquer.
6.3.3
Modifica¸c˜oes necess´arias no c´odigo SystemC
Um c´odigo SystemC OSSI-compliant (como ´e o caso do c´odigo da plataforma) n˜ao pode ser diretamente compilado no ModelSim sem as seguintes modifica¸c˜oes (mais detalhes no manual do ModelSim [1]):
Convers˜ao da fun¸c˜ao sc main() para um m´odulo
O ModelSim n˜ao aceita o uso da fun¸c˜ao sc main() no c´odigo, o conte´udo dessa fun¸c˜ao deve ser transferido para o SC CTOR() criado no m´odulo top level. Al´em desse passo ´e necess´ario que:
• o c´odigo utilizado para teste (testbench), deve ser movido para um processo
• todas as vari´aveis C++ na fun¸c˜ao sc main(), incluindo canais primitivos, portas e m´odulos, obrigatoriamente devem ser definidos como atributos de sc module. Dessa forma, a inicializa¸c˜ao dos mesmos ocorrer´a na SC CTOR.
6.3. Simula¸c˜ao da plataforma na ferramenta ModelSim 63
Substitui¸c˜ao da fun¸c˜ao sc start() por comandos run e suas op¸c˜oes
O ModelSim usa o comando run e suas op¸c˜oes (no terminal do ModelSim) ao inv´es da fun¸c˜ao sc start(). Na maioria dos projetos SystemC (inclusive nos projetos das plata- formas utilizadas por este trabalho), bastou apenas remover a referida fun¸c˜ao do c´odigo. Em outros casos (uso de mais de uma chamada da fun¸c˜ao sc start()), deve-se consultar o manual para maiores informa¸c˜oes.
Remo¸c˜ao de chamadas para sc initialize()
O ModelSim chama automaticamente a fun¸c˜ao sc initialize no fim da elabora¸c˜ao, assim chamadas feitas no c´odigo s˜ao desnecess´arias.
Exporta¸c˜ao dos m´odulos SystemC top level ´
E necess´ario exportar todos os m´odulos top level dispon´ıveis no projeto. Para isso, deve- se utilizar a macro SC MODULE EXPORT(<nome do m´odulo>) em um arquivo fonte (n˜ao pode ser utilizado em um arquivo header ). O uso de templates n˜ao ´e suportado em m´odulos top level.
6.3.4
Altera¸c˜oes nas plataformas utilizadas neste trabalho
Deve-se seguir os procedimentos descritos anteriormente, criando-se o foreign mo- dule e modificando o arquivo <raiz da plataforma>/platforms/<nome da plataforma>/<arquivo fonte principal da plataforma>.
6.3.5
Compila¸c˜ao
Como o compilador GCC e o SystemC providos pelo ModelSim possuem vers˜oes diferentes dos equivalentes utilizados neste trabalho, foi necess´ario recompilar o ArchC utilizando o GCC e o SystemC espec´ıficos do ModelSim.
Para compilar e fazer o linking da plataforma, utilizaram-se os passos descritos no manual [1], com o cuidado de referenciar os cabe¸calhos e as bibliotecas utilizadas.
6.3.6
Simula¸c˜ao
Com a plataforma compilada, utilizou-se o comando vsim, passando como parˆametros o nome do m´odulo top level da plataforma e o arquivo contendo scripts para iniciar a simula¸c˜ao.