Projeto conceitual de um ASIP para processamento digital de áudio

(1)

PROJETO CONCEITUAL DE UM ASIP PARA PROCESSAMENTO

DIGITAL DE ´

AUDIO

Eduardo Koerich d’ ´Avila Vinicius Almeida Carlos

Florian´opolis - SC 2004/2

(2)

DEPARTAMENTO DE INFORM ´

ATICA E ESTAT´ISTICA

BACHARELADO EM CI ˆ

ENCIAS DA COMPUTAC

¸ ˜

AO

PROJETO CONCEITUAL DE UM ASIP PARA PROCESSAMENTO

DIGITAL DE ´

AUDIO

Eduardo Koerich d’ ´Avila 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´opolis - SC 2004/2

(3)

Vinicius Almeida Carlos

PROJETO CONCEITUAL DE UM ASIP PARA PROCESSAMENTO

DIGITAL DE ´

AUDIO

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´audio Villar dos Santos

Banca Examinadora:

Lu´ıs Fernando Friedrich

(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)

Esse trabalho trata do projeto de um ASIP para processamento digital de áudio e a geração au-tomá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 supor-tados 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.

(6)

Abstract

This text discourses about the design of an ASIP applied to digital audio processing and the auto-matic 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.

(7)

1 Fluxo de co-projeto de hardware e software . . . . p. 18 2 Fluxo de s´ıntese de software . . . . p. 19 3 Fluxo de s´ıntese de hardware . . . . p. 20 4 Fluxo de Projeto . . . p. 21 5 Fluxo de execução de efeitos de áudio . . . p. 23 6 Fluxo do processamento de efeitos digitais de áudio . . . p. 24 7 Audio original e áudio modificado pelo efeito Wah-Wah . . . .´ p. 25 8 Amostra normal e modificada pela distorção . . . p. 26 9 Amostra normal e modificada pelo tremolo . . . p. 27 10 Amostra normal e modificada pelo delay . . . p. 28 11 Precisão de cada algoritmo de ganho . . . p. 29 12 Desempenho de cada algoritmo de ganho na execução do efeito Delay . . . p. 29 13 Arquitetura do Conjunto de Instruções . . . p. 31 14 Número de ciclos por instrução . . . p. 34 15 Fluxo da geração do simulador em ArchC . . . p. 35 16 Fluxo do Gerador de Montadores . . . p. 37 17 Ferramentas de compilação do GCC . . . p. 38 18 Funcionamento do cc1 . . . p. 39 19 Exemplo de adição em C . . . p. 41

(8)

21 Exemplo de instrução RTL . . . p. 42 22 Exemplo de sa´ıda assembly . . . p. 42 23 Tempo de simulação dos efeitos . . . p. 45 24 Tempo de desenvolvimento dos modelos . . . p. 46 25 Tamanho do código de cada descrição do ASIP . . . p. 47 26 Proposta para conjunto de instruções extens´ıvel . . . p. 52

(9)

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

(10)

Sum´ario

1 INTRODUC¸ ˜AO p. 13

1.1 O uso de linguagens de descrição de arquiteturas (ADLs) . . . p. 13 1.2 Por que ASIPs? . . . p. 14 1.3 Cenas dos próximos cap´ıtulos . . . p. 14

2 TRABALHOS RELACIONADOS p. 16

3 METODOLOGIA p. 18

3.1 Ferramentas de CAD (Computer Aided Design) . . . p. 21 3.1.1 ArchC . . . p. 21 3.1.2 SystemC . . . p. 22 3.1.3 Pacote de ferramentas Mentor Graphics . . . p. 22

4 A CONCEPC¸ ˜AO DO ASIP p. 23

4.1 A Aplicação . . . p. 23 4.2 Efeitos Digitais de Áudio . . . p. 24 4.3 Estudos preliminares para definição da arquitetura . . . p. 28

5 ARQUITETURA E ORGANIZAC¸ ˜AO DO ASIP p. 31

5.1 Arquitetura . . . p. 31 5.1.1 RISC x Outras arquiteturas: uma vis˜ao pragm´atica . . . p. 32

(11)

5.1.3 Peculiaridades de algumas instruções . . . p. 32 5.2 Organização do ASIP . . . p. 33

6 FERRAMENTAS DE DESENVOLVIMENTO p. 35

6.1 Simulador do conjunto de instruções . . . p. 35 6.2 Montador Manual . . . p. 36 6.3 Gerador de Montadores . . . p. 36 6.4 Loader . . . . p. 36 6.5 Cross-compiler . . . . p. 37 6.5.1 A cadeia de ferramentas do GCC . . . p. 38 6.5.2 Por dentro do cc1 . . . p. 39 6.5.3 RTL: A linguagem intermediária . . . p. 40 6.5.4 Portando o GCC . . . p. 40 6.5.5 Um exemplo de uma compilação . . . p. 41 6.5.6 Portando o GCC para a nossa arquitetura . . . p. 42

7 RESULTADOS EXPERIMENTAIS p. 44

7.1 Validação do ASIP . . . p. 44 7.1.1 Comparações entre cada n´ıvel . . . p. 44 7.2 Validação das ferramentas . . . p. 46

8 CONCLUS ˜OES E TRABALHOS FUTUROS p. 48

8.1 Das Etapas de Projeto do Processador . . . p. 48 8.2 Das Ferramentas Utilizadas . . . p. 49

(12)

8.4 Trabalhos Futuros . . . p. 50

Referˆencias

Anexo A -- C´odigo fonte: algoritmos em Java

Anexo B -- C´odigo fonte: modelo funcional ArchC

Anexo C -- C´odigo fonte: modelo com precis˜ao de ciclos ArchC

Anexo D -- Código fonte: código assembly dos efeitos de áudio

Anexo E -- C´odigo fonte: ASIP descrito em VHDL

Anexo F -- Datapath

Anexo G -- M´aquina de estados do controlador

(13)

1 INTRODUC

¸ ˜

AO

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 transac¸˜oes (TL) escrito em SystemC e um modelo RTL

escrito em VHDL ´e enorme.

1.1 O uso de linguagens de descric¸˜ao de arquiteturas (ADLs)

Apesar de SystemC permitir o refinamento dos modelos em TL para RTL, alguns mecanismos fo-ram 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 sa-tisfazer 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

(14)

exem-plo, permitindo melhor compreens˜ao 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 flexibi-lidade 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 execu-tada. 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 percorri-dos, alguns deles automatizapercorri-dos, 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´oximos cap´ıtulos

O restante do texto é organizado da seguinte maneira. O Cap´ıtulo 2 resume os trabalhos relaciona-dos. 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 pre-liminares para a definição da arquitetura. O Cap´ıtulo 5 descreve a arquitetura e organização do ASIP

(15)

projetado. O Cap´ıtulo 6 traz as ferramentas desenvolvidas para o projeto. O Cap´ıtulo 7 resume os resul-tados experimentais obtidos e no Cap´ıtulo 8 as principais considerações sobre o projeto e a perspectiva para futuros trabalhos são citadas.

´

E 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)

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 con-junto de ferramentas.

Pesquisas estão sendo feitas com o objetivo de criar ferramentas para a geração automática de mon-tadores, 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 ado-tada não possui uma ferramenta para a geração automática do compilador. Sendo assim, optou-se por

(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)

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 alimen-tado 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 mo-dificados automaticamente para estarem de acordo com as novas instruções. ´E por isso que o back-end

(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 escalona-mento 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ˆaneo usando uma ADL como ponto de par-tida, 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)

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.

(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 per-curso. 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 descric¸˜ao das ferramentas de CAD utilizadas nesse projeto.

3.1.1 ArchC

A introdução sobre a linguagem de descrição de arquiteturas ArchC já foi dada nos cap´ıtulos anteri-ores. 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)

parte é a descrição dos elementos da arquitetura (AC ARCH) onde é feita a declaração do tamanho da pa-lavra 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.

3.1.2 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.

3.1.3 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)

4 A CONCEPC

¸ ˜

AO 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 Aplicac¸˜ao

Este estudo de caso visa uma aplicação simples para geração de efeitos digitais de áudio, como ilus-tra a Figura 5. O áudio de enilus-trada 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.

(24)

4.2 Efeitos Digitais de ´

Audio

Efeitos de ´audio podem ser definidos como qualquer tratamento realizado em um determinado si-nal de entrada a fim de se obter um sisi-nal de sa´ıda com suas caracter´ısticas alteradas de acordo com a necessidade. No escopo desse trabalho trata-se apenas dos efeitos de ´audio 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 ´audio

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 2n, onde n é o número de bits utilizados na conversão. ´E 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)

Figura 7: ´Audio original e ´audio 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ˆancia;

- 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 equi-pamentos 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.

(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 simplifi-car a arquitetura e sua implementação.

- Apelo auditivo: preferiu-se selecionar efeitos cujo resultado sonoro ´e 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 distorc¸˜ao

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)

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)

Figura 10: Amostra normal e modificada pelo delay

Explicac¸˜oes detalhadas sobre cada um desses efeitos podem ser encontradas em[16]e[17].

4.3 Estudos preliminares para definic¸˜ao da arquitetura

Uma das maiores preocupações em projetos de sistemas embarcados é justamente com a área ocu-pada pelo hardware. Em um projeto visando a implementação em FPGA, essa preocupação está di-retamente 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 algorit-mos de ganho. Para a tomada de decisão entre multiplicação e algoritalgorit-mos de ganho usando deslocamen-tos, foram criadas tabelas comparando os seguintes fatores de cada opção:

- precis˜ao

(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 opc¸˜oes foram consideradas para

a tomada da decis˜ao.

As tabelas mais relevantes para a tomada da decis˜ao podem ser vistas abaixo.

Figura 11: Precis˜ao 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 execuc¸˜ao 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)

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)

5 ARQUITETURA E ORGANIZAC

¸ ˜

AO 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.

(32)

5.1.1 RISC x Outras arquiteturas: uma vis˜ao pragm´atica

Máquinas RISC, por definição, apresentam um conjunto reduzido de instruções, geralmente com for-matos 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 au-tomática de ferramentas de programação do processador (toolkit).

5.1.2 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 pro-blemas 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 registra-dores de uso geral, o que garante uma boa alocação de registraregistra-dores[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.

5.1.3 Peculiaridades de algumas instruc¸˜oes

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:

(33)

Semˆantica 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´umero 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´aria.

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.

RD: recebe byte da mem´oria 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´udo de RS para a busca do byte na mem´oria.

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.

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´udo de RS para armazenamento do byte na mem´oria.

5.2 Organizac¸˜ao 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)

A Figura 14 e os anexos F e G resumem as principais definic¸˜oes do projeto do caminho de dados e controlador do processador.

(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˜ao explicitadas abaixo.

6.1 Simulador do conjunto de instruc¸˜oes

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.

(36)

6.2 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 arqui-tetura sejam rapidamente reavaliadas através da programação em assembly.

O fluxo do gerador de montadores ´e 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 contro-lador. 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 de-senvolvida 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)

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.

(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.

6.5.1 A cadeia de ferramentas do GCC

Figura 17: Ferramentas de compilac¸˜ao 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. ´E 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)

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.

6.5.2 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ˆanticos,

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.

(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.

6.5.3 RTL: A linguagem intermedi´aria

Tal como explicado anteriormente, quase todo trabalho do GCC é feito utilizando a linguagem inter-mediá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.

6.5.4 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.

(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˜ao 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 13.

6.5.5 Um exemplo de uma compilac¸˜ao

Código em C (supondo que as variáveis são do tipo int):

a = b + c;

Figura 19: Exemplo de adic¸˜ao 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)

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 definic¸˜ao RTL

Na expressão RTL não otimizada, o compilador adota um número arbitrário qualquer para os regis-tradores. 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˜ao RTL (n˜ao otimizada):

(set (reg:SI 46) (plus:SI (reg:SI 47) (reg:SI 48)))

Express˜ao RTL (otimizada):

(set (reg:SI 6) (plus:SI (reg:SI 7) (reg:SI 8)))

Figura 21: Exemplo de instruc¸˜ao RTL

A última etapa, é a geração do código assembly. Para isso, o compilador percorre o machine

des-cription 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 6 7 8

Figura 22: Exemplo de sa´ıda assembly

6.5.6 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)

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 auto-maticamente. 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 fer-ramenta para geração automática de código RTL (VHDL) e necessita de um longo tempo de estudo para ser desenvolvido.

(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 Validac¸˜ao 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.

7.1.1 Comparac¸˜oes 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 comple-xidade relativa entre n´ıveis. Obviamente, quanto mais abstrato o modelo, menor sua complecomple-xidade e o tempo de simulação a ele associado.

(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

0 1000 2000 3000 4000 5000 6000 7000 8000 9000 10000 Java ArchC

Funcional ArchC Precisãode Ciclos VHDL

Modelos Te m po (m s) Tremolo Phaser Flanger Distort Delay

Figura 23: Tempo de simulac¸˜ao 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)

Tempo de desenvolvimento por modelo 30 60 85 180 0 20 40 60 80 100 120 140 160 180 200

Java ArchC – UF ArchC – CA VHDL

Modelo Te m po (h )

Figura 24: Tempo de desenvolvimento dos modelos

crescente dos modelos com o menor n´ıvel de abstrac¸˜ao correlata com os tempos de desenvolvimento da Figura 24.

7.2 Validac¸˜ao 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 pro-gramado 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 ma-nualmente 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)

Tamanho do código 360 398 650 1185 0 200 400 600 800 1000 1200 1400

Java ArchC – UF ArchC – CA VHDL

Modelos C ód ig o (e m li nh as )

Figura 25: Tamanho do código de cada descrição do ASIP

considerado j´a 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)

8 CONCLUS ˜

OES 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 importan-tes 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 al-gor´ı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)

uma oportunidade de automac¸˜ao 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)

8.3 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)

das extens˜oes 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á esta-ria 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 imple-mentada 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)