UNIVERSIDADE FEDERAL DE SANTA CATARINA

Transcrição

1 UNIVERSIDADE FEDERAL DE SANTA CATARINA PROJETO CONCEITUAL DE UM ASIP PARA PROCESSAMENTO DIGITAL DE ÁUDIO Eduardo Koerich d Ávila Vinicius Almeida Carlos Florianópolis - SC 2004/2

2 UNIVERSIDADE FEDERAL DE SANTA CATARINA DEPARTAMENTO DE INFORMÁTICA E ESTATÍSTICA BACHARELADO EM CIÊNCIAS DA COMPUTAÇÃO PROJETO CONCEITUAL DE UM ASIP PARA PROCESSAMENTO DIGITAL DE ÁUDIO Eduardo Koerich d Ávila Vinicius Almeida Carlos Trabalho de conclusão de curso apresentado como parte dos requisitos para obtenção do grau de Bacharel em Ciências da Computação Florianópolis - SC 2004/2

3 Eduardo Koerich d Ávila Vinicius Almeida Carlos PROJETO CONCEITUAL DE UM ASIP PARA PROCESSAMENTO DIGITAL DE ÁUDIO Trabalho de conclusão de curso apresentado como parte dos requisitos para obtenção do grau de Bacharel em Ciências da Computação Orientador: Luiz Cláudio Villar dos Santos Banca Examinadora: Luís Fernando Friedrich Olinto José Varela Furtado

4 Agradecimentos Gostaríamos de agradecer primeiramente aos nossos pais, pois sem eles nada seríamos. Gostaríamos de agradecer também ao nosso orientador, o professor Luiz Cláudio, que deu todo o suporte para a realização do trabalho, agindo sempre da forma mais correta e auxiliando-nos sempre que possível.

5 Resumo Esse trabalho trata do projeto de um ASIP para processamento digital de áudio e a geração automática do seu toolkit, utilizando uma metodologia de projeto baseada em uma linguagem de descrição de arquiteturas. O projeto tem como ponto de partida o estudo e a definição dos efeitos a serem suportados pelo processador e do conjunto de instruções. O próximo passo é a descrição do processador nos vários níveis de abstração (funcional e com precisão de ciclos na ADL e RTL em VHDL). A descrição na ADL serve de insumo para geração do toolkit. Os resultados envolvendo tanto o projeto do ASIP quanto às ferramentas são apresentadas ao final do trabalho, enfatizando as diferenças entre cada nível de descrição e os problemas levantados na automação da geração do toolkit. PALAVRAS-CHAVE: ASIP, ADL, metodologia de projeto, geração automática de toolkit.

6 Abstract This text discourses about the design of an ASIP applied to digital audio processing and the automatic generation of its software toolkit, applying an ADL-based methodology. The design starting point is the definition of the audio effects to be supported by the ASIP and the definition of the instruction-set architecture. The next step is the ASIP description in some abstraction levels (functional, cycle-accurate and RTL). The ADL description is used as input for the toolkit generation. The results about ASIP design and software toolkit are presented at the end of text, emphasizing the differences among each description level and the problems concerning automatic toolkit generation. KEY-WORDS: ASIP, ADL, design methodology, automatic toolkit generation.

7 Lista de Figuras 1 Fluxo de co-projeto de hardware e software p Fluxo de síntese de software p Fluxo de síntese de hardware p Fluxo de Projeto p Fluxo de execução de efeitos de áudio p Fluxo do processamento de efeitos digitais de áudio p Áudio original e áudio modificado pelo efeito Wah-Wah p Amostra normal e modificada pela distorção p Amostra normal e modificada pelo tremolo p Amostra normal e modificada pelo delay p Precisão de cada algoritmo de ganho p Desempenho de cada algoritmo de ganho na execução do efeito Delay p Arquitetura do Conjunto de Instruções p Número de ciclos por instrução p Fluxo da geração do simulador em ArchC p Fluxo do Gerador de Montadores p Ferramentas de compilação do GCC p Funcionamento do cc p Exemplo de adição em C p. 41

8 20 Exemplo de definição RTL p Exemplo de instrução RTL p Exemplo de saída assembly p Tempo de simulação dos efeitos p Tempo de desenvolvimento dos modelos p Tamanho do código de cada descrição do ASIP p Proposta para conjunto de instruções extensível p. 52

9 Lista de Abreviaturas RTL: Register Transfer Level ou Register Transfer Language HDL: Hardware Description Languages IP: Intellectual Property EDA: Electronic Design Automation TL: Transaction-Level VHDL: Very High Speed Integrated Circuits Hardware Description Language ADL: Architecture Description Language ASIP: Application-Specific Instruction-set Processor CPU: Central Processing Unit ASIC: Application-Specific Integrated Circuit UF: Untimed Functional CA: Cycle-Accurate ISS: Instruction-Set Simulator CAS: Cycle-Accurate Simulator FPGA: Field Programmable Gate Arrays GCC: GNU Compiler Collection RTX: RTL Expression

10 Sumário 1 INTRODUÇÃO p O uso de linguagens de descrição de arquiteturas (ADLs) p Por que ASIPs? p Cenas dos próximos capítulos p TRABALHOS RELACIONADOS p METODOLOGIA p Ferramentas de CAD (Computer Aided Design) p ArchC p SystemC p Pacote de ferramentas Mentor Graphics p A CONCEPÇÃO DO ASIP p A Aplicação p Efeitos Digitais de Áudio p Estudos preliminares para definição da arquitetura p ARQUITETURA E ORGANIZAÇÃO DO ASIP p Arquitetura p RISC x Outras arquiteturas: uma visão pragmática p. 32

11 5.1.2 Principais características p Peculiaridades de algumas instruções p Organização do ASIP p FERRAMENTAS DE DESENVOLVIMENTO p Simulador do conjunto de instruções p Montador Manual p Gerador de Montadores p Loader p Cross-compiler p A cadeia de ferramentas do GCC p Por dentro do cc p RTL: A linguagem intermediária p Portando o GCC p Um exemplo de uma compilação p Portando o GCC para a nossa arquitetura p RESULTADOS EXPERIMENTAIS p Validação do ASIP p Comparações entre cada nível p Validação das ferramentas p CONCLUSÕES E TRABALHOS FUTUROS p Das Etapas de Projeto do Processador p Das Ferramentas Utilizadas p. 49

12 8.3 Das Ferramentas Desenvolvidas p Trabalhos Futuros p. 50 Referências Anexo A -- Código fonte: algoritmos em Java Anexo B -- Código fonte: modelo funcional ArchC Anexo C -- Código fonte: modelo com precisão de ciclos ArchC Anexo D -- Código fonte: código assembly dos efeitos de áudio Anexo E -- Código fonte: ASIP descrito em VHDL Anexo F -- Datapath Anexo G -- Máquina de estados do controlador Anexo H -- Artigo

13 13 1 INTRODUÇÃO A crescente complexidade dos sistemas embarcados advogam por níveis mais altos de abstração, reuso de projeto e verificação escalável. O projeto de um sistema começando no nível RTL como provido pela maioria das linguagens de descrição de hardware (HDLs) é incapaz de lidar com a demanda de plataformas contendo uma ou mais CPUs, vários barramentos, blocos de propriedade intelectural (IP), memórias e dispositivos de I/O. Embora grande parte da comunidade de automação de projetos (EDA) aponta SystemC [1] como a futura linguagem padrão para o projeto no nível de sistemas [2] (System-level design), o gap entre um modelo no nível de transações (TL) escrito em SystemC e um modelo RTL escrito em VHDL é enorme. 1.1 O uso de linguagens de descrição de arquiteturas (ADLs) Apesar de SystemC permitir o refinamento dos modelos em TL para RTL, alguns mecanismos foram introduzidos para simplificar e agilizar a criação e manutenção de modelos funcionais para CPUs com a introdução de linguagens de descrição de arquiteturas (ADLs) [3] [4] [5] [6] [7]. O papel de uma ADL é especialmente importante quando um processador de propósito geral não é adequado para satisfazer restrições de tempo real ou de potência de uma certa aplicação e um processador de aplicação específica (ASIP) tem que ser usado. ADLs são cruciais para usabilidade dos ASIPs, uma vez que não há, previamente, um conjunto de software de desenvolvimento (por exemplo, cross-compiler, simuladores, montadores, ligadores etc) que possa ser usado para fazer a programação do ASIP. Isso faz das ADLs um ponto de partida muito comum para refinamento do modelo, síntese da CPU e geração automática das ferramentas citadas acima. Além disso, ADLs podem também ser usadas em disciplinas de Arquitetura de Computadores por exemplo, seja na apresentação de modelos de arquiteturas bem conhecidas, como a do MIPS por exem-

14 14 plo, permitindo melhor compreensão das características do processador explicados somente na teoria, seja na pesquisa de novas arquiteturas. 1.2 Por que ASIPs? A utilização de ASIPs é pragmática no sentido que eles representam um compromisso entre flexibilidade e eficiência. ASIPs são basicamente uma solução intermediária entre processadores de propósito geral e circuitos integrados de aplicação específica (ASIC). Em [8] há uma figura que ilustra de forma muito interessante o problema entre flexibilidade e consumo de energia entre as soluções mais comuns para sistemas embarcados. Como dito anteriormente, ASIPs são utilizados no lugar de processadores de propósito geral quando esses não satisfazem as restrições de tempo e potência de uma certa aplicação; e são utilizados no lugar dos ASICs quando há a necessidade de programação da aplicação a ser executada. Esse trabalho apresenta um estudo de caso cujo objetivo maior é automatizar os vários passos que devem ser percorridos durante o projeto de ASIPs (compreendendo a geração do seu toolkit). Para abrir caminho em direção à completa automação, dois elementos chaves são aqui abordados. Em primeiro lugar, uma metodologia de projeto é definida e usada durante o projeto de um ASIP para uma aplicação simples de processamento digital de áudio. Segundo, os principais passos de refinamento são percorridos, alguns deles automatizados, outros, embora provisoriamente executados manualmente, contribuem para identificação os pontos chaves para automações futuras. Além disso, no escopo do trabalho de conclusão de curso, o projeto é um ótimo atrativo pois permite o contato com diversas áreas estudadas no curso como Arquitetura de Computadores, Sistemas Digitais, Projetos de Sistemas Embutidos e Compiladores. É importante também notar que a aplicação em si não é o ponto chave do trabalho, e por isso mesmo foi escolhida uma aplicação que motivasse a dupla na realização do trabalho. 1.3 Cenas dos próximos capítulos O restante do texto é organizado da seguinte maneira. O Capítulo 2 resume os trabalhos relacionados. O Capítulo 3 descreve a metodologia empregada e as principais ferramentas utilizadas no auxílio ao projeto do ASIP. O Capítulo 4 descreve mais detalhadamente a aplicação alvo e alguns estudos preliminares para a definição da arquitetura. O Capítulo 5 descreve a arquitetura e organização do ASIP

15 15 projetado. O Capítulo 6 traz as ferramentas desenvolvidas para o projeto. O Capítulo 7 resume os resultados experimentais obtidos e no Capítulo 8 as principais considerações sobre o projeto e a perspectiva para futuros trabalhos são citadas. É também importante observar que o trabalho já produziu alguns resultados interessantes, como a publicação do artigo [9] no SFM 2004, evento ocorrido conjuntamente com o SBCCI 2004 e o SBMicro 2004, dois simpósios de nível internacional na área de projetos de circuito integrados e microeletrônica, além da submissão de um outro artigo para o IBERCHIP 2005, evento ibero-americano também na área de microeletrônica.

16 16 2 TRABALHOS RELACIONADOS Muitas ADLs foram reportadas na literatura. As primeiras ADLs foram desenvolvidas visando compiladores redirecionáveis (por exemplo, ISDL [4] ). Mais tarde, a evolução do projeto no nível de sistema abriu caminho para o surgimento de ADLs para a geração automática tanto de compiladores eficientes quanto de modelos de CPU com precisão de ciclos. Algumas ADLs, como EXPRESSION [3] e ArchC [7], alcançam esse objetivo provendo visões separadas do conjunto de instruções: uma visão semântica (para geração de compiladores) e uma visão comportamental (para geração do simulador). Outras ADLs, como nml [5] e PEAS-III [6] buscam o mesmo objetivo combinando as duas visões em uma gramática mais restritiva. Essencialmente, o trabalho nesse domínio foca em melhorias para superar tais restrições gramaticais e visões redundantes [10], a extensão de núcleos de processadores genéricos [11] e a caracterização de aplicações embarcadas para permitir tais extensões no conjunto de instruções [12]. Neste trabalho nós adotamos a ADL ArchC [7], uma linguagem de descrição de arquitetura de cógido aberto que tem a vantagem de gerar modelos funcionais em SystemC, desse modo permitindo integração direta do modelo com uma plataforma descrita em SystemC. Nosso principal objetivo é considerar como o hardware do ASIP pode ser sintetizado a partir de uma descrição em ADL, juntamente com seu conjunto de ferramentas. Pesquisas estão sendo feitas com o objetivo de criar ferramentas para a geração automática de montadores, compiladores, ligadores, etc, a partir de descrições utilizando as ADLs. Dentre elas, pode-se citar uma cuja finalidade foi a geração automática, embora parcial, do back-end do GCC a partir de uma descrição utilizando a ADL nml [13]. Uma outra objetivou a geração automática de um montador a partir de uma descrição ArchC [14]. Esta última ferramenta foi utilizada neste trabalho. A ADL adotada não possui uma ferramenta para a geração automática do compilador. Sendo assim, optou-se por

17 17 modificar manualmente o back-end do GCC para a arquitetura que foi desenvolvida. Para auxiliar nesta etapa, utilizou-se como referência um trabalho onde foi feita a modificação do back-end do GCC para o processador C6x [15].

18 18 3 METODOLOGIA O fluxo principal do projeto começa com a descrição do ASIP na ADL, primeiramente como um modelo funcional sem precisão de ciclos (UF), e depois refinado para o modelo com precisão de ciclos (CA). Um simulador do conjunto de instruções (ISS) ou um simulador com precisão de ciclos (CAS) é automaticamente gerado a partir da descrição apropriada na ADL, como mostrado na Figura 1, e alimentado com um código executável gerado pelo fluxo de síntese de software. Esses passos de automação já estão implementados pelo pacote ArchC. Figura 1: Fluxo de co-projeto de hardware e software O fluxo de síntese de software, que engloba as ferramentas responsáveis por permitir a programação do ASIP em alto nível de modo fácil e eficiente, também tem como entrada a descrição provida na ADL escolhida, como mostra a Figura 2. Caso a arquitetura núcleo seja extensível, tanto o compilador quanto o montador tem que ser modificados automaticamente para estarem de acordo com as novas instruções. É por isso que o back-end

19 19 Figura 2: Fluxo de síntese de software do compilador precisa extrair informações automaticamente a partir da descrição ADL, seja para seleção de instruções (semântica a partir do modelo funcional ou com precisão de ciclos), seja para escalonamento de código (latências a partir do modelo com precisão de ciclos). Pela mesma razão um gerador de montadores é necessário. Neste projeto, o GNU GCC é adotado como front-end e seu back-end é modificado para gerar código para o ASIP. Uma vez que a arquitetura atual não apresenta a característica de extensibilidade, a modificação automática do back-end não se faz estritamente necessária, embora faça parte dos objetivos a serem alcançados para total automação do projeto de ASIPs. O mesmo ocorre com o gerador de montadores, embora este já tenha sido implementado por parte dos alunos do grupo de pesquisa [14] no qual este trabalho foi desenvolvido. Tendo então os algoritmos programados em alto nível e o compilador criado, pode-se gerar o código assembly, que depois de passar pelo montador está pronto para ser carregado no simulador. A partir dessa etapa o ASIP está validado nos níveis funcional e com precisão de ciclos. Buscou-se um fluxo de síntese de hardware contemporâneo usando uma ADL como ponto de partida, como mostrado na Figura 3. A partir da descrição em ADL do modelo com precisão de ciclos, um modelo com precisão de ciclos escrito em SystemC é gerado. É realizada então a Síntese Arquitetural a partir de SystemC, resultando

20 20 Figura 3: Fluxo de síntese de hardware numa descrição RTL que é então combinada, por um Loader, com o código executável gerado na síntese de software; a descrição RTL resultante é sintetizada visando uma plataforma FPGA. Neste projeto, VHDL é a linguagem utilizada na descrição RTL. A Síntese Arquitetural é executada manualmente neste projeto, passando-se então diretamente da descrição com precisão de ciclos na ADL para a descrição RTL. Uma vez que as primeiras gerações de ferramentas de síntese arquitetural assumem uma descrição comportamental em uma HDL, a maioria das ferramentas comerciais não pode ser usada diretamente para automatizar esse passo partindo de uma descrição em SystemC. Adicionalmente, a necessidade de uma segunda geração de síntese arquitetural foi advogada pela comunidade de EDA [2], onde HDLs são usadas para síntese RTL e não para síntese arquitetural comportamental. Ao executar manualmente a síntese arquitetural, está se fazendo uma primeira tentativa em avaliar os desafios e necessidades dessa segunda geração de ferramentas. Um fluxo clássico de simulação HDL, possivelmente com back annotation, é adotado, permitindo assim o uso de ferramentas comerciais. A Figura 4 mostra o fluxo de projeto completo.

21 21 Figura 4: Fluxo de Projeto 3.1 Ferramentas de CAD (Computer Aided Design) No fluxo de projeto explanado acima foram citadas algumas ferramentas utilizadas durante o percurso. Elas se encaixam no que comumemente se chama de ferramentas de CAD, ou seja, ferramentas de auxílio a projetos por computador. Toda metodologia de projeto de hardware está apoiada nessas ferramentas e o desenvolvimento e o aprimoramento das mesmas é umas das áreas mais promissoras em Automação de Projetos. Abaixo segue uma breve descrição das ferramentas de CAD utilizadas nesse projeto ArchC A introdução sobre a linguagem de descrição de arquiteturas ArchC já foi dada nos capítulos anteriores. Não é objetivo dessa seção dar uma visão exaustiva sobre a linguagem, pelo contrário, a intenção é resumir como é a descrição de um modelo em ArchC. O modelo descrito em ArchC é composto de duas partes. Uma delas é a descrição da arquitetura do conjunto de instruções (AC ISA) que contém a declaração de todas a instruções e seus formatos. A outra

22 22 parte é a descrição dos elementos da arquitetura (AC ARCH) onde é feita a declaração do tamanho da palavra que será utilizada na arquitetura, número de registradores, pipeline, memória utilizada etc. A partir das duas descrições acima, o ArchC Simulator Generator (ACSIM) gera um template comportamental, que deverá ser preenchido com o comportamento de cada instrução. Com a descrição comportamental completa, o modelo é compilado gerando um simulador executável da arquitetura modelada. O simulador executável pode então utilizar um código binário ou hexadecimal para fazer a simulação da arquitetura SystemC SystemC [1] é composto por um conjunto de bibliotecas que estendem C/C++ para permitir projeto e verificação de hardware em níveis maiores de abstração. O código fonte para o kernel de simulação é freeware e está disponível em [1]. Embora permita descrições em nível RTL, SystemC não tem como objetivo substituir as já bem conhecidas linguagens de descrição de hardware, VHDL e Verilog, mas sim permitir o projeto no nível de sistema Pacote de ferramentas Mentor Graphics Em um primeiro momento tinha-se a intenção de utilizar o pacote de ferramentas Mentor Graphics, uma das mais importantes fabricantes de ferramentas de CAD, para realizar toda a parte de simulação em VHDL e possivelmente a síntese para FPGA. Porém, durante o projeto, as licenças para essas ferramentas não puderam ser renovadas e passou-se então para o uso de versões de avaliação de simuladores VHDL.

23 23 4 A CONCEPÇÃO DO ASIP As seções seguintes mostram os passos relacionados à definição do ASIP, começando com a delimitação da aplicação a ser suportada pelo ASIP, seguido de uma breve explicação sobre o domínio da aplicação (Efeitos Digitais de Áudio), finalizando, então, com uma explanação de como se definiu o conjunto de operações que o ASIP seria capaz de realizar. 4.1 A Aplicação Este estudo de caso visa uma aplicação simples para geração de efeitos digitais de áudio, como ilustra a Figura 5. O áudio de entrada pode ser produzido por um instrumento musical, pode ser sintetizado a partir de mídia digital, etc. O áudio de saída pode ser enviado a um amplificador, gravador de mídia digital, etc. O processamento do áudio é realizado por um sistema integrado de hardware e software. Cada efeito de áudio corresponde a um software embarcado distinto, que é carregado na memória do sistema. O áudio suportado pela aplicação possui dados codificados em 8 bits, com taxa de amostragem de 16 khz. Figura 5: Fluxo de execução de efeitos de áudio

24 Efeitos Digitais de Áudio Efeitos de áudio podem ser definidos como qualquer tratamento realizado em um determinado sinal de entrada a fim de se obter um sinal de saída com suas características alteradas de acordo com a necessidade. No escopo desse trabalho trata-se apenas dos efeitos de áudio realizados digitalmente. O processo de execução de um efeito de áudio digital é esquematizado na Figura 6. Figura 6: Fluxo do processamento de efeitos digitais de áudio Em primeiro lugar, o áudio em formato analógico passa por um conversor analógico-digital que vai realizar a amostragem do sinal de entrada. Para que a conversão ocorra corretamente e o sinal resultante não apresente distorções é necessário que a taxa de amostragem esteja de acordo com o teorema Nyquist, que diz que se um sinal analógico contém componentes de freqüência até f Hz, a taxa de amostragem deve ser no mínimo 2 f Hz. O áudio em formato digital é representado através de números que variam de 0 a 2 n, onde n é o número de bits utilizados na conversão. É sobre esses valores que os efeitos de áudio digitais atuam. Os dados resultantes das operações realizadas pelos efeitos são então convertidos novamente para o formato analógico, usando-se a mesma taxa de amostragem aplicada à conversão anterior. Nem sempre todas as etapas ocorrem conjuntamente, sendo possível aplicar os efeitos à arquivos previamente gravados, por exemplo. A Figura 7 mostra o resultado da aplicação do efeito Wah-Wah a uma amostra de áudio. Os parâmetros mais comuns nas implementações do efeito Wah-Wah são:

25 25 Figura 7: Áudio original e áudio modificado pelo efeito Wah-Wah - freqüência da forma de onda de variação; - fase inicial da forma de onda de variação; - profundidade; - ressonância; - freqüência de compensação. Como pode-se ver, a forma de onda resultante da aplicação do efeito sofreu várias alterações. Cada um dos parâmetros citados acima é responsável por determinar o formato final da forma de onda. Existe uma gama enorme de efeitos que podem ser implementados, como por exemplo: Equalização, Compressão, Wah-Wah, Echo, Reverb, Chorus, Noise Reduction, Pitch, Tremolo, Flanger, Distorção, Delay, Phaser etc. Além disso, cada efeito possui suas variações, constituindo assim um número enorme de efeitos possíveis. Variados também são as formas de implementação dos efeitos. Existem hoje centenas de equipamentos construídos especificamente para geração de efeitos, além de inúmeros softwares utilizados para o mesmo fim. Porém nesses dois casos, a qualidade dos efeitos é absolutamente imprescindível e para se alcançar tais características, tanto em implementações em hardware quanto em software, há uma complexidade considerável, dado que todos efeitos são baseados em complexas equações matemáticas. Entretanto, não faz parte do escopo desse trabalho o estudo aprofundado de efeitos de áudio e sua

26 26 implementação com a devida fidelidade. A aplicação no contexto desse projeto é o meio e não o fim. Por esse motivo, a escolha dos efeitos foi feita com base em dois critérios: - Simplicidade: algoritmos com funções matemáticas complexas não foram incluídos para simplificar a arquitetura e sua implementação. - Apelo auditivo: preferiu-se selecionar efeitos cujo resultado sonoro é facilmente percebido por um ouvinte comum. Abaixo segue a lista dos efeitos escolhidos e uma breve explicação para cada um deles. Ao final de cada explicação há uma figura mostrando a forma de onda original e a forma de onda modificada pelo efeito implemententado, com exceção para os efeitos Phaser e Flanger, cujas formas de onda resultantes não apresentam características facilmente percebidas. Distorção: A distorção basicamente satura a onda sonora dando ao som um aspecto meio distorcido ou sujo. O algoritmo de distorção recebe como entrada a onda sonora, um ganho e um valor de saturação. Quando a onda é processada, primeiramente aplica-se a ela o ganho e em seguida ela é saturada com o valor de saturação. Figura 8: Amostra normal e modificada pela distorção Trêmolo: O trêmolo é simplesmente a variação constante de volume de forma linear. São passados como parâmetros o volume máximo e mínimo, assim como a velocidade de variação do volume. A onda vai aumentando sua amplitude de acordo com a velocidade de variação. Quando esta atinge

27 27 o volume máximo desejado, ela começa a diminuir sua amplitude até atingir o volume mínimo e voltar a aumentar a amplitude novamente, ficando assim até que se pare a execução do efeito. Figura 9: Amostra normal e modificada pelo tremolo Delay: O delay adiciona à onda uma ou mais amostras atrasadas, mas não chega a dar uma sensação de eco. O algoritmo de delay recebe como entrada a onda sonora, um ganho para a onda original, um ganho para as amostras atrasadas, a quantidade de feedback e o tempo de atraso. No processamento da onda, aplica-se a ela um ganho (ganho da onda original) e depois pega-se uma amostra atrasada em t (tempo de atraso) segundos e aplica-se a ela um outro ganho (ganho para amostras atrasadas). No caso de haver feedback, a onda processada nesta etapa será adicionada a amostra t segundos seguinte, porém a ela será aplicado um ganho menor que um para diminuir sua intensidade. A intenção é que a amostra atrasada vá se repetindo seguidas vezes, cada vez mais baixo, até que não mais se possa ouví-la. Flanger: O flanger utiliza-se da técnica do delay para sua execução. No entanto ele não faz uso de feedback e seu tempo de atraso fica entre 20 e 200 milisegundos. Um diferencial no algoritmo do flanger, é que o tempo de atraso fica constantemente variando para maior e menor atraso. Um dos parâmetros do algoritmo é justamente o menor e o maior atraso desejado. Phaser: O phaser tem um comportamento exatamente igual ao flanger, sendo a única diferença que a amostra atrasada, antes de ser adicionada a onde original, é invertida para dar um outro aspecto sonoro.

28 28 Figura 10: Amostra normal e modificada pelo delay Explicações detalhadas sobre cada um desses efeitos podem ser encontradas em [16] e [17]. 4.3 Estudos preliminares para definição da arquitetura Uma das maiores preocupações em projetos de sistemas embarcados é justamente com a área ocupada pelo hardware. Em um projeto visando a implementação em FPGA, essa preocupação está diretamente ligada com o número de gates presentes no dispositivo. Não obstante, para a realização de efeitos de áudio há a necessidade de algumas operações matemáticas que demandam alta complexidade e por conseguinte, mais espaço no FPGA. Outro problema diz respeito à velocidade de processamento do hardware, que deve atender às exigências da aplicação. Face a esses dois problemas, estudos preliminares foram realizados a fim de se buscar a melhor relação custo-benefício para o projeto. A principal preocupação foi com a operação de multiplicação que poderia demandar bastante espaço em hardware, além de tornar proibitivo a execução dos efeitos no período necessário. A opção foi reprogramar os efeitos, retirando as operações de multiplicação explícitas e as programando com somas e deslocamentos, criando-se assim o que se chamou de algoritmos de ganho. Para a tomada de decisão entre multiplicação e algoritmos de ganho usando deslocamentos, foram criadas tabelas comparando os seguintes fatores de cada opção: - precisão - desempenho em número de ciclos para se executar ganho

29 29 - desempenho em número de ciclos e tempo total de execução de cada efeito - número aproximado de componentes necessários para implementação em hardware - escalabilidade Para o caso de se usar deslocamentos, havia a possibilidade de implementar deslocamentos em hardware usando tanto Shift Register, quanto Barrel Shifter. Essas duas opções foram consideradas para a tomada da decisão. As tabelas mais relevantes para a tomada da decisão podem ser vistas abaixo. Figura 11: Precisão de cada algoritmo de ganho Para cada algoritmo, foram executados todos os possíveis valores de ganho aceitos e anotada a diferença entre o valor dado e valor esperado e calculada a média. Nesse critério o algoritmo 2 foi descartado por apresentar precisão mais baixa que os demais e ter uma abrangência menor que os outros, ou seja, seria possível somente executar ganhos em uma faixa restrita de valores (por exemplo de 0,5 a 2,75, variando de 0,25 em 0,25). Figura 12: Desempenho de cada algoritmo de ganho na execução do efeito Delay Das comparações realizadas pelos critérios acima citados, a Figura 12 apresenta o resultado mais relevante, que é a comparação do desempenho de cada um dos algoritmos para um determinado efeito. Ela é resultado da contagem do número de instruções do efeito para cada implementação, combinado com o tempo de atraso de cada componente utilizado. Com esses valores foi possível calcular qual o tempo de execução do efeito para cada possível implementação.

30 30 Da análise das tabelas geradas optou-se pelo uso da multiplicação simples, uma vez que os custos de hardware, e o tempo de execução, mostrado na Figura 12, não tornariam proibitiva, de maneira alguma, a construção do ASIP em um possível FPGA de baixo custo; além do uso da multiplicação proporcionar a melhor precisão nos resultados e, por fim, tornar mais intuitiva a programação dos efeitos de áudio.

31 31 5 ARQUITETURA E ORGANIZAÇÃO DO ASIP 5.1 Arquitetura A arquitetura do conjunto de instruções foi definida a partir do conjunto de algoritmos de efeitos de áudio previamente selecionados, implementados e testados em uma linguagem de alto nível. Fazendo a análise dos algoritmos implementados em alto nível, detectou-se quais seriam as instruções necessárias para a geração dos efeitos em um processador específico. De modo geral observou-se a presença de somas, subtrações, multiplicações e saltos, além de instruções de acesso a memória, mas, como era de se esperar nesse tipo de aplicação, as instruções aritméticas são a grande maioria. O conjunto de instruções é mostrado na Figura 13. Figura 13: Arquitetura do Conjunto de Instruções

32 RISC x Outras arquiteturas: uma visão pragmática Máquinas RISC, por definição, apresentam um conjunto reduzido de instruções, geralmente com formatos mais regulares que outros tipos de arquitetura, acesso a memória apenas com o uso de instruções LOAD/STORE (também conhecidas como máquinas Load/Store), etc. Além de apresentarem hardware menos complexo que outras arquiteturas, essas características contribuem para facilitar a geração automática de ferramentas de programação do processador (toolkit) Principais características Além da escolha por uma arquitetura RISC, algumas considerações importantes precisam ser citadas sobre a arquitetura projetada: - Tamanho da palavra: 16 bits; foi o menor tamanho encontrado capaz de comportar a definição das instruções em formatos regulares. A escolha do menor tamanho visa contribuir para a minimização do tamanho código. - Precisão estendida: embora os dados de entrada/saída (amostras de áudio) tenham precisão de 8 bits, internamente são tratados com precisão de 16 bits. Esta escolha visa minimizar os problemas com overflow e arredondamento ocasionados pelas instruções aritméticas. Além disso, a representação para as amostras de áudio em 8 bits minimiza a quantidade de memória ocupada por dados. - Banco de registradores: os registradores têm comprimento de 16 bits e há um total de 16 registradores de uso geral, o que garante uma boa alocação de registradores [18]. - Espaço de endereçamento: o espaço de endereçamento de 64 kbytes é mais que o atualmente necessário, o que garante a possibilidade de futuras extensões no projeto Peculiaridades de algumas instruções A maioria das instruções apresenta comportamento similar as encontradas em outras máquinas RISC, porém, três delas merecem um pouco mais de atenção. São elas: MULT RD RS RT : Multiplicação em ponto fixo entre os operando RS e RT

33 33 Semântica dos operandos: RD: número inteiro de 16 bits, recebe o resultado da multiplicação entre RS e RT. RS: número inteiro de 16 bits sinalizado RT: número em ponto fixo de 16 bits, onde os 12 bits mais significativos representam a parte inteira e os 4 bits menos significativos representam a parte fracionária. LBX RD RS IMM4 : Carrega byte da memória endereçada pelo conteúdo de RS mais o valor do campo IMM4, fazendo extensão do sinal do bit mais significativo do byte lido. Semântica dos operandos: RD: recebe byte da memória com sinal extendido RS: contém o endereço da memória onde o byte será buscado. IMM4: constante de 4 bits sinalizada, somada ao conteúdo de RS para a busca do byte na memória. SBS RD RS IMM4 : Carrega byte na memória endereçada pelo conteúdo de RS mais o valor do campo IMM4, fazendo saturação do conteúdo de RD para representar valores na faixa de 8 bits. Semântica dos operandos: RD: registrador de 16 bits com valor a ser saturado e armazenado na memória. RS: contém o endereço da memória onde o byte será armazenado. IMM4: constante de 4 bits sinalizada, somada ao conteúdo de RS para armazenamento do byte na memória. 5.2 Organização do ASIP A arquitetura foi implementada segundo uma organização clássica composta de um datapath e de um controlador. Como a aplicação não demanda alto desempenho, decidiu-se implementar as instruções em múltiplos ciclos de relógio e sem qualquer paralelismo entre instruções. A escolha por uma implementação multiciclo sem pipeline resulta em um datapath compacto (devido ao compartilhamento das unidades funcionais) e permite a operação em freqüência adequada aos requisitos da aplicação.

34 34 A Figura 14 e os anexos F e G resumem as principais definições do projeto do caminho de dados e controlador do processador. Figura 14: Número de ciclos por instrução

35 35 6 FERRAMENTAS DE DESENVOLVIMENTO Um processador sem ferramentas que permitam sua programação em alto nível não tem grande utilidade. Realizar a programação em binário, embora possível, não é uma alternativa viável, ainda mais para processadores com um grande número de instruções. Nesse sentido, um toolkit de programação do ASIP se faz absolutamente necessário. As ferramentas presentes nesse projeto são explicitadas abaixo. 6.1 Simulador do conjunto de instruções O simulador do conjunto de instruções é gerado automaticamente pelo pacote ArchC a partir da descrição do modelo, tanto no nível funcional quanto no nível com precisão de ciclos. O fluxo de geração automática do simulador é mostrado na Figura 15. Figura 15: Fluxo da geração do simulador em ArchC

36 Montador Manual O montador é responsável por transformar um código de montagem (código assembly) em código binário. Essa foi a primeira ferramenta desenvolvida para o projeto, pois seria inviável testar o modelo descrito em ArchC com código binário criado manualmente. O montador foi implementado em Java e é responsável também por transferir para o código binário, na seção de dados, o conteúdo de um arquivo de áudio no formato wave com amostras de 8 bits. Dessa forma foi possível aplicar aos efeitos implementados em assembly à mesma entrada de áudio aplicada aos efeitos implementados em Java. 6.3 Gerador de Montadores Um dos objetivos da metodologia de projeto adotada é justamente permitir explorar de modo rápido e eficiente novas soluções de projeto. Desse modo, o gerador de montadores resolve dois problemas importantes na construção de ASIPs: em primeiro lugar retira a necessidade da construção manual do montador, o que representa grande ganho de tempo, e em segundo lugar permite que alterações na arquitetura sejam rapidamente reavaliadas através da programação em assembly. O fluxo do gerador de montadores é mostrado na Figura 16. O gerador de montadores foi desenvolvido por parte do grupo de alunos do LAPS (Laboratório de Automação e Projeto de Sistemas) e está descrito mais detalhadamente em [14]. 6.4 Loader A descrição VHDL do ASIP compreende todos os elementos do caminho de dados mais o controlador. A memória, como um dos elementos do caminho de dados, precisa ser alimentada com o código da aplicação a ser executada. Para tanto, uma ferramenta simples, porém de grande utilidade, foi desenvolvida com o intuito de transferir o código hexadecimal gerado da montagem para o código VHDL correspondente à memória. A ferramenta, que nada mais é que um script, recebe como entrada o arquivo em assembly e, caso necessário, o arquivo de áudio contendo os dados a serem processados, e de posse de um template de memória pré-existente, constrói o novo arquivo de memória em VHDL.

37 37 Figura 16: Fluxo do Gerador de Montadores 6.5 Cross-compiler Um conjunto de ferramentas de programação completo é composto também por um compilador que permite gerar código para a máquina alvo a partir de uma descrição em uma linguagem de alto nível. Isto é muito importante também no que diz respeito à comercialização do produto, uma vez que a grande maioria dos programadores está mais acostumada com a programação em alto nível. Algumas das etapas de compilação podem ser consideradas independentes da plataforma alvo. Por

38 38 essa razão, ao invés de se criar um desde o início, optou-se por portar o GNU GCC [19], um compilador bem conhecido, resultando então em um compilador cruzado (cross-compiler) para a nossa arquitetura. A situação ideal seria portar o GCC automaticamente a partir da descrição em uma ADL. Embora, neste trabalho, isto tenha sido executada manualmente, foi importante para identificar problemas e pontos de automação para a execução automática. Para entender como portar o GCC para a nossa arquitetura é necessário entender o seu funcionamento, explicado a seguir A cadeia de ferramentas do GCC Figura 17: Ferramentas de compilação do GCC A execução do GCC é controlada através do compiler driver, que utiliza várias ferramentas para realizar a compilação, sendo ele o responsável por fazer o controle e a comunicação entre elas. Um esquema de como estas ferramentas são usadas está representado na Figura 17. Ao ser executado, o primeiro passo do GCC é iniciar a execução do cc1, ou C Compiler, e passar para ele o arquivo C/C++ que foi fornecido como entrada do compilador. O cc1, ao iniciar, executa o cpp, ou Preprocessor, que irá percorrer todos os arquivos de entrada, procurando por diretivas tais como #include e #define, por exemplo, expandindo qualquer macro que encontrar. O cpp, ao fim de sua execução, repassa o controle da execução ao cc1, que analisa o código C/C++ pré-processado. O cc1 compreende a parte mais importante da compilação. É aqui que são feitas todas as análises léxica, sintática, semântica, além de todas as otimizações de código. Ao final de sua execução, o cc1 gera um código assembly para a arquitetura alvo escolhida. O GCC retoma a execução e inicia a execução do gas, ou GNU Assembler, passando para ele o código assembly gerado pelo cc1. O gas é responsável por traduzir o código assembly gerado no passo anterior em um código binário para a arquitetura alvo.

39 39 Ao fim da execução do gas, o GCC passa a execução para o ld, ou GNU Linker, que combina os módulos gerados nas etapas anteriores transformando-os em um único arquivo executável, que é o código fornecido como saída do compilador. Neste trabalho, somente a primeira parte, ou o cc1 e o cpp foram utilizados para compilação. O gas e o ld não foram utilizados, e no lugar deles usou-se o montador gerado automaticamente pelo gerador de montadores e o script de carga que foi criado manualmente Por dentro do cc1 Figura 18: Funcionamento do cc1 Como o objetivo deste trabalho foi somente portar o GCC para gerar código assembly para a nossa arquitetura, não foi necessário estudar a fundo o funcionamento do gas e o ld. No entanto, não se pode dizer o mesmo do cc1, já que toda a parte de geração de código assembly esta compreendida nesta etapa. A execução do cc1 é dividida em três etapas, o Front-End, o Middle-End e o Back-End, executados nesta seqüência, como mostrado na Figura 18. O primeiro passo do Front-End, é criar uma representação em árvore, chamada parse tree, da função que está sendo compilada. Para isso, o cc1 executa o parser, que divide as declarações C/C++ em tokens, associa a cada token um valor e depois inclui este valor, junto com alguns valores semânticos, em um ramo da árvore de representação. Em seguida, são feitas algumas otimizações independentes da plataforma alvo, como simplificações aritméticas, etc, utilizando a árvore de representação. Depois de criar a árvore de representação e fazer as devidas otimizações, a árvore é usada para

40 40 fazer a geração do código intermediário utilizado pelo cc1, conhecido como RTL, ou Register Transfer Language. Para executar este passo, o cc1 necessita de algumas informações da máquina destino, tais como, quais as instruções suportadas pela máquina etc. Estas informações são dadas ao cc1 através de um arquivo, chamado machine description. Após a geração do código intermediário, encerra-se a etapa do Front-End e inicia-se a do Middle- End. Nesta etapa, ocorrem varias otimizações de código bem conhecidas, tais como otimização de desvio, otimização de loops, escalonamento de código, alocação de registradores, etc. Para realizar esta etapa, informações da máquina alvo precisam ser fornecidas ao cc1 para que ele possa fazer as otimizações corretamente. Parte dos dados são fornecidos através do arquivo machine description, no entanto a maior parte das informações é dada pelo arquivo target description macros. A última etapa do cc1 é o Back-End, onde é feita a tradução do código RTL gerado e otimizado nas etapas anteriores para o código assembly da máquina alvo, casando as instruções RTL com as definições que foram descritas no arquivo machine description RTL: A linguagem intermediária Tal como explicado anteriormente, quase todo trabalho do GCC é feito utilizando a linguagem intermediária. As otimizações de código são feitas utilizando esta linguagem, além da tradução para código assembly. Inspirada em listas LISP, a linguagem intermediária possui duas formas de representação. Uma delas utiliza um formato interno, em que estruturas apontam para outras estruturas e assim vão formando as expressões. E a outra, utiliza uma forma textual usada no machine description e em saídas escritas para fins de depuração Portando o GCC Para portar o GCC, não é necessário modificar seu código fonte de modo que se adapte a arquitetura alvo. Ele requer que apenas três arquivos lhe sejam fornecidos para que possa gerar código para o processador. Estes arquivos são: machine.md ou machine description e o machine.h em conjunto com o machine.c, formando o target description macros and functions. O machine description contém uma série de definições de padrões que descrevem o comportamento

41 41 da máquina. Dentre eles, os mais usados são o define_insn e o define_expand. O segundo é utilizado durante a geração do código intermediário, a partir da árvore de representação, enquanto o primeiro pode ser usado tanto na geração do código intermediário quanto na fase final de compilação, para gerar o código assembly. O define_expand é usado para dizer ao compilador como gerar um código RTL específico de uma arquitetura alvo. Se ele for usado, é preciso definir um define_insn sem nome que corresponda a estrutura definida no define_expand. Isto precisa ser feito, senão, durante a geração de código assembly, o compilador não irá encontrar uma definição de instrução RTL que combine com a estrutura criada na hora da geração de código intermediário. Há muitas outras definições além das duas citadas acima. Entre elas, duas bastante importantes são o define_split e o define_peephole, utilizados na etapa de otimização. Todas as definições do machine description estão presentes em [20], no Capítulo 12. O target description macros and functions contém várias macros que precisam ser definidas, mas que não cabem no esquema do machine description. Dentre estas macros pode-se citar o tamanho dos tipos de dados, pois algumas máquinas não suportam operações inteiras de 16 bits, por exemplo, e a variável int tem de ser emulada para que caiba em um registrador de 16 bits, o tamanho do banco de registradores, se a máquina é big endian ou little endian etc. Todas as macros que podem ser definidas estão presente em [20], no Capítulo Um exemplo de uma compilação Código em C (supondo que as variáveis são do tipo int): a = b + c; Figura 19: Exemplo de adição em C O compilador, ao receber o código C mostrado na Figura 19, faz o parser e cria uma representação em árvore para a expressão. Em seguida, o compilador identifica que se trata de uma instrução de adição entre inteiros, gera o nome addsi3 e procura no machine description por uma definição RTL que tenha o mesmo nome. Veja um exemplo de definição na Figura 20. Ao encontrar, o compilador gera uma instrução RTL não otimizada, de acordo com a estrutura descrita na definição encontrada, como mostrado na Figura 21 (os números de registradores adotados foram escolhidos ao acaso).

42 42 Definição de instrução RTL (machine description): define_insn ("addsi3" [(set (match_operand:si 0 "register_operand" "") (plus:si (match_operand:si 1 "register_operand" "") (match_operand:si 2 "register_operand" "")))] "" "add %0 %1 %2" "") Figura 20: Exemplo de definição RTL Na expressão RTL não otimizada, o compilador adota um número arbitrário qualquer para os registradores. Mesmo que a máquina alvo tenha, por exemplo, 16 registradores de uso geral, o compilador assume que ela possui infinitos. Somente depois da etapa de otimização de código é que o compilador troca os números arbitrários por números de registradores reais, como se pode ver na Figura 21. Expressão RTL (não otimizada): (set (reg:si 46) (plus:si (reg:si 47) (reg:si 48))) Expressão RTL (otimizada): (set (reg:si 6) (plus:si (reg:si 7) (reg:si 8))) Figura 21: Exemplo de instrução RTL A última etapa, é a geração do código assembly. Para isso, o compilador percorre o machine description a procura de uma definição RTL que coincida com a instrução RTL otimizada. Neste caso, ele irá encontrar a mesma definição addsi3. O compilador então pega a saída assembly da definição RTL e troca os valores em % pelo respectivo valor do registrador, gerando a saída mostrada na Figura 22. Saída Assembly: add Figura 22: Exemplo de saída assembly Portando o GCC para a nossa arquitetura Até o momento, somente uma parte do machine description foi descrito. Isto se deve ao fato de que estudar o GCC acabou tomando muito tempo e não foi possível terminar as descrições no prazo estabelecido. Um dos objetivos do trabalho, no entanto, é identificar pontos de automação para a geração

43 43 automática do machine description e do target description macros através do ArchC. Quanto a esse aspecto, pode-se observar que o ArchC, apesar de fácil de entender e usar devido a sua simplicidade, acaba apresentando algumas deficiências para a geração automática da machine description, pois seria necessário extrair informações do código de comportamento para portar a arquitetura para o GCC automaticamente. Isso seria uma tarefa extremamente complicada, uma vez que o código de comportamento não apresenta uma estrutura rígida, pois é escrito em C. Aparentemente, utilizar um descrição ArchC para portar a arquitetura automaticamente para o GCC parece ser tão complicado quanto fazer uma ferramenta para geração automática de código RTL (VHDL) e necessita de um longo tempo de estudo para ser desenvolvido.

44 44 7 RESULTADOS EXPERIMENTAIS Os principais produtos de trabalho resultantes do projeto são o ASIP propriamente dito, nos diversos níveis de descrição, e as ferramentas desenvolvidas para o mesmo. 7.1 Validação do ASIP Projetos de processadores são tipicamente top-down, ou seja, começam em um nível elevado de abstração e através de refinamentos sucessivos se alcança um nível que possa ser diretamente mapeado em hardware; e a validação do mesmo é geralmente feita comparando os resultados de um nível com outro. Embora o nível algorítmico não faça parte das várias etapas do projeto de uma CPU, no projeto em questão o ponto de partida foi justamente a definição dos algoritmos de efeito para se realizar a identificação das instruções necessárias e avaliar a qualidade dos mesmos. Para tanto, os efeitos foram implementados em Java e testados com inúmeras amostras de áudio para avaliar o impacto sonoro de cada efeito. Como dito anteriormente, não se buscou fidelidade nos efeitos, mas sim alterações interessantes no áudio que pudessem ser percebidas por um ouvinte leigo no assunto. O próximo passo foi executar os efeitos de áudio em ArchC no nível funcional com a mesma amostra de áudio aplicada aos efeitos em Java. O mesmo foi feito para o modelo com precisão de ciclos descrito em ArchC e o modelo em VHDL. Uma vez que os resultados foram equivalentes em todos os níveis, cada nível foi considerado validado Comparações entre cada nível A descrição e simulação do ASIP em vários níveis de abstração permitem a comparação da complexidade relativa entre níveis. Obviamente, quanto mais abstrato o modelo, menor sua complexidade e o tempo de simulação a ele associado.

45 45 A Figura 23 quantifica essa noção em termos de tempo de simulação em cada nível de abstração. Note que o tempo de simulação do modelo RTL é cerca de 13 vezes maior do que o tempo de um modelo funcional e 4 vezes maior do que o modelo com precisão de ciclos. Tempo de execução/simulação dos efeitos Tempo (ms) Tremolo Phaser Flanger Distort Delay Java ArchC Funcional ArchC Precisão de Ciclos VHDL Modelos Figura 23: Tempo de simulação dos efeitos A Figura 24 mostra o tempo de desenvolvimento do modelo do ASIP em vários níveis de abstração: algorítmico, funcional, funcional com precisão de ciclos e RTL. Note que o tempo de desenvolvimento do modelo RTL foi cerca de 6 vezes maior do que o correspondente ao modelo algorítmico. A Figura 24 quantifica o ganho de produtividade obtido nos mais altos níveis de abstração e deixa claro que um projeto iniciado diretamente no nível RTL tem menos chances de satisfazer restrições de time-to-market muito severas. (Com a exceção de Java, não havia conhecimento relevante prévio nem de ArchC nem de VHDL no projeto em questão). Para finalizar as comparações entre os vários níveis de descrição, o número de linhas de código de cada nível foi computado e o resultado está mostrado na Figura 25. É importante observar que, para o cômputo do número de linhas de código nos modelos descritos em ArchC e em VHDL, também foram considerados o código em assembly dos efeitos de áudio. Como era de se esperar, a complexidade

46 46 Tempo de desenvolvimento por modelo Tempo (h) Java ArchC UF ArchC CA VHDL Modelo Figura 24: Tempo de desenvolvimento dos modelos crescente dos modelos com o menor nível de abstração correlata com os tempos de desenvolvimento da Figura Validação das ferramentas Para um arquitetura simples, com apenas 12 instruções, a validação do montador manual poderia ser feita simplesmente comparando o código gerado pela ferramenta com o código correspondente programado diretamente em binário. Essa comparação foi feita para cada instrução presente na arquitetura, porém o montador foi considerado realmente validado quando os códigos dos efeitos programados manualmente em assembly foram transformados em código executável pelo montador e introduzidos no simulador gerado pelo ArchC e os resultados produzidos pelo simulador foram exatamente iguais aos obtidos nos algoritmos implementados em Java. Já a validação do gerador de montadores foi bem mais simples, uma vez que foi necessário somente comparar o código executável resultante com o código executável produzido pelo montador manual,

47 47 Tamanho do código Código (em linhas) Java ArchC UF ArchC CA VHDL Modelos Figura 25: Tamanho do código de cada descrição do ASIP considerado já validado. Para todos os efeitos programados em assembly, o resultado foi exatamente igual entre o montador manual e o montador gerado automaticamente. A comparação com o código do cross-compiler ainda não foi realizada pois este não está pronto até o presente momento.

48 48 8 CONCLUSÕES E TRABALHOS FUTUROS Um exercício de projeto completo, como o realizado nesse trabalho, tem como um dos objetivos dar a noção exata das dificuldades encontradas ao se realizar o projeto de um processador e seu toolkit, além de, apoiado por uma metodologia que segue as tendências da EDA, possibilitar a identificação de possíveis passos a serem automatizados e efetivamente automatizando outros. Os pontos mais importantes e as perspectivas de trabalhos futuros com base nesse projeto são citados abaixo: 8.1 Das Etapas de Projeto do Processador Embora o projeto Top-Down de um processador não tenha como ponto de partida uma descrição algorítmica, as primeira etapas do projeto: pesquisa, definição, implementação e testes de forma algorítmica e alto nível dos efeitos a serem suportados pelo processador, são essenciais para a delimitação do trabalho e assim garantir a factibilidade do mesmo. Juntamente com a definição do conjunto de instruções, esses dois passos representam uma parte considerável do trabalho, que é necessária para o bom andamento do mesmo, embora não tragam contribuições científicas. Dos vários passos de refinamento realizados no projeto, a transição de um modelo com precisão de ciclos descrito em ArchC para o modelo RTL descrito em VHDL foi o mais difícil e demorado, como mostrado na Figura 24. Porém, a descrição com precisão de ciclos em ArchC fornece mais pistas para esse refinamento do que simplesmente a definição da arquitetura do conjunto de instruções. Além de representar o refinamento mais demorado, a transição de uma descrição em ArchC para uma descrição em VHDL acarreta na mudança também dos vetores de testes utilizados, na maneira de se realizar a simulação e na velocidade que é realizada tal simulação. Garantir o funcionamento de uma descrição em VHDL é uma tarefa muito mais trabalhosa que em ArchC, justamente pelo nível de detalhamento que uma descrição RTL permite. Aqui, portanto, se identifica um importante passo a ser considerado como

49 49 uma oportunidade de automação no projeto. Além disso, os resultados obtidos mostraram claramente a necessidade se aumentar o nível de abstração no projeto de ASIPs, pois, para uma aplicação muito simples, a descrição do ASIP em RTL foi responsável, aproximadamente, por 61% do tempo gasto com sua implementação nos seus vários níveis. Além disso, o tempo de simulação para o nível RTL em VHDL é praticamente 100 vezes maior que o tempo de simulação em Java. Isso implica que um projeto começando no nível RTL, embora possível, não é viável. 8.2 Das Ferramentas Utilizadas ArchC tem como grande atrativo a usabilidade. A documentação provida no site [21] é de grande utilidade. O fato de ser de domínio público é mais um ponto positivo para a ferramenta. Não obstante, o grupo responsável pelo ArchC na Unicamp incentiva o uso do ArchC e se dispõe a ajudar o quanto for possível. Porém, uma descrição em ArchC precisou de algumas extensões para se realizar a geração de montadores e provavelmente precisa de outras extensões, ou até mesmo possíveis restrições precisam ser feitas ao se descrever o comportamento das instruções, para se permitir tanto a geração automática do back-end quanto a síntese arquitetural. Por outro lado, as ferramentas utilizadas na parte do fluxo de projeto envolvendo a descrição RTL em VHDL são dominadas por grandes empresas de CAD como Cadence, Synopsis, Mentor Graphics, Synplicty etc; por esse motivo, ferramentas de simulação e síntese de VHDL são muito caras e de difícil acesso. O projeto contava previamente com a utilização das ferramentas da Mentor Graphics, porém, por um problema com as licenças, não foi possível mais utilizá-las. O ponto crítico para o projeto foi o simulador VHDL, ferramenta necessária para validação do processador no nível RTL. A solução encontrada foi a utilização da versão de avaliação da ferramenta ActiveHDL 6.3 da Aldec. Uma das primeiras tarefas do projeto foi a familiarização com as ferramentas do pacote da Mentor Graphics, que foram utilizadas nos estudos preliminares para a definição da arquitetura do conjunto de instruções, porém, ao iniciar a descrição em VHDL não se contava mais com as ferramentas da Mentor, sendo necessário um período de reaprendizado em outro pacote de ferramentas, o que de certa forma contribuiu para uma demora maior na conclusão da descrição RTL.

50 Das Ferramentas Desenvolvidas A primeira ferramenta desenvolvida foi o montador manual, imprescíndivel para a validação do modelo descrito em ArchC nos seus estágios iniciais. Dada a escolha por uma arquitetura RISC com um conjunto de instruções reduzido, o desenvolvimento do montador manual transcorreu de forma bem rápida. O gerador de montadores, por outro lado, é uma ferramenta muito mais poderosa e complexa, por isso exigiu bem mais tempo para ser completado. Um pré-processamento do código assembly, além de algumas extensões na linguagem ArchC precisaram ser feitas para viabilizar total automação da geração de montadores. Dados mais representativos sobre essa ferramenta podem ser encontrados em [14]. O script de carregamento de memória, embora muito simples, é de grande utilidade. Os testes finais com a descrição VHDL exigiam diretamente a execução de pequenos códigos em assembly, porém, embora já de posse do montador, a transferência do código hexadecimal para a memória descrita em VHDL era feita de forma manual, caracterizando um trabalho extremamente massante e demorado. O script agilizou consideralvemente o processo de validação e testes da descrição em VHDL. A criação de um cross-compiler para a nossa arquitetura, e até mesmo a geração automática desse cross-compiler, representava, com certeza, um dos maiores desafios do projeto, pois incluia um estudo aprofundado do funcionamento do GNU GCC, além de todo processo de modificação do back-end do mesmo. Embora não tenha sido completamente terminada, os passos percorridos e descritos no trabalho são extremamente úteis para futuros trabalhos na mesma linha. 8.4 Trabalhos Futuros Como dito anteriormente, o refinamento mais crítico foi da descrição em ArchC do modelo com precisão de ciclos para o modelo RTL descrito em VHDL. Porém, é justamente nesse passo que está uma das mais importantes contribuições a ser feita. Uma ferramenta, ou um conjunto de ferramentas, que realize essa conversão, mesmo que parcial, traria um grande avanço no projeto do ASIP. No caso ideal, a ferramenta faria todo o refinamento e juntamente com a geração automática do toolkit teria-se uma plataforma de prototipação de ASIPs muito poderosa. Porém a descrição em ArchC não é poderosa o suficiente para lidar com todas essas necessidades e extensões precisam ser feitas, no entanto, a natureza

51 51 das extensões precisa ser melhor estudada. Outro possível trabalho futuro diz respeito à automação da geração de back-ends para o GNU GCC tendo como entrada a descrição em ArchC. Alguns pontos precisam ser melhor estudados a fim de se garantir a possibilidade desse projeto, pois a descrição ArchC, embora muito simples e funcional, talvez necessite de extensões para permitir essa geração automática. O projeto do processador em hardware não fazia parte do escopo desse trabalho. Chegou-se, então, a um nível de descrição em RTL simulado e validado, porém não se realizou a síntese do mesmo visando um FPGA alvo, nem mesmo a simulação com os atrasos reais de cada componente de hardware. Um futuro trabalho seria a continuação desse projeto até a implementação final em uma plataforma FPGA com todos os componentes necessários a se realizar propriamente dito a geração de efeitos de áudio. Um dos objetivos perseguidos com esse trabalho era a criação de um núcleo do conjunto de instruções que pudesse ser estendido simplesmente pela adição de novas instruções. Dessa forma, o núcleo já estaria validado e com suporte de ferramentas e a geração das novas ferramentas para a nova arquitetura não traria grandes dificuldades. Porém, visando minimizar o tamanho do código e manter a regularidade no formato das instruções que uma arquitetura RISC pede, o campo de opcode acabou ficando com apenas 4 bits, que dá o total de 16 instruções possíveis. Dado que 12 instruções foram criadas, um espaço de 4 instruções a mais não dá ao ASIP a característica de um processador extensível. Por esse motivo, uma nova proposta para a arquitetura do conjunto de instruções foi pensada. Essa arquitetura não foi implementada durante o projeto pois ela apresenta algumas peculiaridades que necessitam de um certo estudo antes de realmente ser adotada. A Figura 26 mostra a arquitetura do conjunto de instruções sugerida. A principal mudança diz respeito ao tamanho do campo de opcode das instruções que passaria a ter 7 bits, comportando um total de 128 instruções, um número com certeza suficiente para viabilizar futuras extensões. Por outro lado, mantendo o tamanho da palavra em 16 bits, o número de bits dedicado aos registradores passa a ser 3 contra os 4 da arquitetura anterior. Dessa forma, o banco de registradores tem seu tamanho reduzido pela metada, pois apenas 8 registradores podem ser endereçados com o novo formato das instruções. Para permitir uma boa alocação de registradores foi criada a instrução SWRB, que faz a troca de qual banco de registradores está sendo utilizado no momento. A conseqüência imediata da adição dessa instrução é a necessidade de múltiplos bancos de registradores, acarretando dificuldades tanto no projeto do hardware quanto na construção do compilador.

52 Figura 26: Proposta para conjunto de instruções extensível 52