PROJETO CONCEITUAL DE UM ASIP PARA PROCESSAMENTO DIGITAL DE ÁUDIO

Transcrição

1 UNIVERSIDADE FEDERAL DE SANTA CATARINA DEPARTAMENTO DE INFORMÁTICA E ESTATÍSTICA Eduardo D avila Koerich Vinicius Almeida Carlos PROJETO CONCEITUAL DE UM ASIP PARA PROCESSAMENTO DIGITAL DE ÁUDIO Florianópolis, 2004

2 Eduardo D avila Koerich Vinciius Almeida Carlos PROJETO CONCEITUAL DE UM ASIP PARA PROCESSAMENTO DIGITAL DE ÁUDIO Rascunho de relatório submetido à Universidade Federal de Santa Catarina como parte dos requisitos para obtenção da nota final da disciplina de Projetos I. Luiz Cláudio Villar dos Santos Florianópolis, 2004

3 Sumário 1 INTRODUÇÃO 3 2 MOTIVAÇÃO 4 3 ArchC - LINGUAGEM DE DESCRIÇÃO DE ARQUITETURAS 5 4 APLICAÇÃO Efeitos de Áudio METODOLOGIA 8 6 ARQUITETURA 10 7 ORGANIZAÇÃO 13 8 ESTADO ATUAL 14 Lista de Figuras 1 Fluxo de Projeto Precisão de cada algoritmo de ganho Tamanho estimado de cada componente em FPGA Atraso estimado de cada componente no FPGA Desempenho de cada algoritmo na execução do efeito Delay Conjunto de Instruções Organização do processador

4 1 INTRODUÇÃO Projetos de hardware têm oferecido cada vez mais desafios no que diz respeito a sua complexidade e tempo de desenvolvimento. O trabalho em questão visa aplicar uma metodologia de projeto baseada em uma Linguagem de Descrição de Arquitetura, doravante denominada como ADL, no projeto de um Application-Specific Instruction-Set Processor (ASIP) e a criação de seu conjunto de ferramentas (assembler, cross-compiler e simuladores). A aplicação alvo é um processador digital para geração de efeitos de áudio. A motivação para o trabalho, a metodologia empregada, as principais características do processador e o estado atual do projeto são descritos nos capítulos a seguir. 3

5 2 MOTIVAÇÃO Projetos de hardware baseados estritamente em HDL possuem metodologias de projeto consolidadas e existem inúmeras ferramentas de apoio a projetos seguindo essas metodologias. Porém, projetos em HDL levam muito mais tempo para se chegar a uma versão simulada, validada e testada, e são mais sensíveis a mudanças no projeto pois se trabalha em um nível de abstração menor. Nesse contexto, projetos no nível de sistema (system-level design) são interessantes pois permitem criar versões do projeto em alto nível, testá-la mais facilmente, refiná-la, alem de facilitar a criação de ferramentas que automatizem certos passos do projeto. Por isso, uma metodologia de projeto moderna deve estar de acordo com fluxo de projeto no nível de sistema e SystemC[1][2] vai de encontro a essa questão, pois SystemC é uma biblioteca de classes C++ e uma metodologia que se pode usar para criar efetivamente um modelo com precisão de ciclos de algoritmos de software, arquitetura de hardware, e interfaces para SoC (System On a Chip) and projetos no nível de sistema (SystemC Version 2.0 Users Guide 2.0, 2002, p.1). O fato de se iniciar o projeto com o uso de uma ADL facilita a criação de um toolkit de programação e testes do projeto, e a escolha pelo ArchC[3][4], que é uma linguagem de descrição de arquiteturas, se deu basicamente pelo fato dela gerar um modelo em SystemC[1][2]. Descrever o projeto em uma ADL permite iniciar o projeto em um nível alto de abstração. A descrição do processador pode então ser feita simplesmente baseada no conjunto de instruções definidas previamente. É possível então descrever o ASIP em vários níveis, dentro da própria ADL (funcional, precisão de ciclos, uso de memória cache etc). O toolkit é composto pelo simulador, gerador de montadores e cross-compiler. O gerador de montadores é uma ferramenta que permite, a partir de descrições em ArchC, gerar um montador para a arquitetura desejada. A ferramenta gerador de montadores pode ser tão complexa quanto se queira, e criar essa ferramenta de forma a ser genérica foge ao escopo do trabalho em questão. O gerador de montadores a ser implementado visa possibilitar pequenas modificações na arquitetura pré-definida, como por exemplo adições de novas instruções, ou mudanças nos campos das mesmas. O cross-compiler permitirá a geração de código de máquina, a partir de código em alto nível, para a arquitetura alvo. No caso de uma modificação na arquitetura, o código em alto nível seria recompilado para gerar código para a arquitetura modificada. O simulador é gerado automaticamente pela ferramenta ArchC[1]. 4

6 3 ArchC - LINGUAGEM DE DESCRIÇÃO DE ARQUITE- TURAS O ArchC é uma linguagem de descrição de arquitetura que está sendo desenvolvida no LSC (Laboratório de Sistemas de Computadores) no IC-UNICAMP (Instituto da Computação da Universidade de Campinas). Ele tem como base o SystemC, uma linguagem de descrição de hardware. O 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 parte é a descrição dos elementos da arquitetura (AC ARCH) onde é feito a declaração do tamanho da palavra que será utilizada na arquitetura, número de registradores, pipeline, etc. A partir das duas descrições acima, o ArchC Pre-Processor (ACPP) 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 arquietura modelada. O simulador executável pode então utilizar um código binário ou hexadecimal para fazer a simulação da arquitetura. Maiores informações podem ser encontradas em [3][4]. 5

7 4 APLICAÇÃO A aplicação em questão é um processador digital de audio, mais especificamente gerador de efeitos de áudio, com várias funcões implementadas, validado, testado e em condicões de ser construído fisicamente em FPGA. Os efeitos selecionados para rodarem no processador são: Delay, Distorção, Flanger, Phaser e Trêmolo. Porém, futuramente deseja-se expandir o repertório de efeitos a serem programados. A seleção dos efeitos teve como critérios básicos: - simplicidade (algoritmos com funções matemáticas complexas não foram inclusos pois dificultariam o projeto da arquitetura e implementação dos algoritmos de efeito) - resultado sonoro (efeitos com grande apelo auditivo, ou seja, as diferenças entre o som original e o modificado são facilmente percebidas, mesmos por leigos no assunto). O resultado final é um processador de efeitos de áudio, rodando efeitos em Real-Time, que seja configurável externamente na setagem de quais efeitos devem ser aplicados e os parâmetros a serem utilizados por cada efeito. Porém, são previstas implementações intermediárias mais simples, com parâmetros carregados diretamente da memória, execução de um único efeito por vez e aplicação dos efeitos a amostras de audio previamente carregadas em memória. 4.1 Efeitos de Áudio Os efeitos citados acima foram previamente programados em linguagem de alto nível. Segue abaixo uma pequena explanação sobre cada efeito implementado: 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. Tremolo: O tremolo é simplesmente a variação constante de volume de forma linear. É passado 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 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. Delay: O delay simplesmente 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 6

8 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 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 X e Y 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. 7

9 5 METODOLOGIA O objeto de estudo do trabalho é justamente a busca de novas maneiras de se realizar o projeto de hardware, usando novas ferramentas como ArchC[3][4] e SystemC[1][2] e criando uma metodologia que permita a execução do fluxo de projeto de forma sutil e recorrente. A metodologia do trabalho, capturada no plano de trabalho, pode ser vista na figura abaixo. Figura 1: Fluxo de Projeto Na figura vemos quatro cadeias de ferramentas interligadas entre si em pontos-chave. A cadeia de ferramenta de síntese de software compreende basicamente as ferramentas do tool kit. Essas ferramentas visam a programação em alto nível, com facilidade, do ASIP. Em um primeiro momento, para permitir a simulação dos códigos de aplicação (efeitos) é criado um montador manualmente e os efeitos são codificados em assembly. Na versão final o código é escrito em alto nível, compilado pelo cross-compiler e montado pelo montador gerado automaticamente. Ele então é carregado no simulador, gerando assim o ISS (Instruction Set Simulator). 8

10 Na cadeia de ferramenta de co-simulação de HW/SW tem-se como entrada as descrições do ASIP, em ArchC, nos níveis funcional e com precisão de ciclos. A simulação é feita primeiramente sobre o modelo funcional, sem precisão de ciclos, para assegurar que o conjunto de instruções é capaz de realizar as operações necessárias à aplicação. O próximo passo é refinar o modelo para apresentar instruções com precisão de ciclos, que é como o ASIP serah realmente implementado. O ArchC então gera um modelo executável em SystemC, que é usado para a simulação, tendo como código de teste o resultado gerado pela cadeia de síntese de software. O modelo gerado em SystemC pode ser refinado manualmente a fim de se chegar o mais próximo possível da descrição RTL que serah feita em VHDL, não perdendo, dessa forma, todo a cadeia gerada para simulação e testes gerado anteriormente. Da ultima descrição gerada em SystemC parte-se para a conversão manual para a descrição ASIP em RTL. A cadeia de síntese de hardware segue o caminho já conhecido da comunidade de microeletrônica. A síntese em FPGA conta com uma ultima etapa que carrega o código da aplicação para ser sintetizado junto com o hardware projetado. 9

11 6 ARQUITETURA A arquitetura do conjunto de instruções foi definida a partir de um conjunto de algoritmos de efeitos de áudio previamente selecionados, implementados e testados em uma linguagem de alto nível, que servirá posteriormente como testbenches para a aplicação em questão. Fazendo-se a análise dos algoritmos gerados em alto nível, detectaram-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. Como se visa a implementação em hardware do processador, a primeira preocupação foi com relação à multiplicação, que poderia se tornar um problema por ser custosa tanto em tempo de execução, quanto no espaço físico necessário para implementá-la em hardware. A opção foi reprogramar os efeitos, retirando as operações de multiplicação explícitas e as programando com soma 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 - 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 tanto de implementar deslocamentos em hardware usando Shift Register, quanto Barrel Shifter. Essas duas opções foram consideradas para a tomada da decisão. As tabelas usadas para tomada de decisão podem ser vistas abaixo: Figura 2: 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. As duas figuras anteriores comparam o atraso e espaço físico ocupado para cada possível implementação física, em um FPGA alvo. Esses critérios seriam importantes caso a 10

12 Figura 3: Tamanho estimado de cada componente em FPGA Figura 4: Atraso estimado de cada componente no FPGA diferença entre eles fosse muito grande, ou seja, se para implementar a multiplicação usando Barrel Shifter fosse dez vezes mais rápido e ocupasse cinquenta vezes menos o espaço no FPGA que um multiplicador, provavelmente teria um peso maior na decisão de qual implementação usar. Figura 5: Desempenho de cada algoritmo na execução do efeito Delay Esse figura apresenta o resultado mais importante, 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. Analisando-se as tabelas geradas, optou-se pelo uso da multiplicação simples, pois representa o melhor custo-benefício dentre as soluções apresentadas. Objetivando-se a criação de ferramentas de auxílio à programação do processador, e, 11

13 por conseguinte possibilitando a programação do mesmo em alto nível, optou-se por uma arquitetura RISC. Abaixo segue quadro-resumo com as principais definições da arquitetura. Figura 6: Conjunto de Instruções Algumas considerações importantes sobre a definição da arquitetura em 16 bits precisam ser citadas: - esse foi o menor tamanho encontrado que comportasse a definição das instruções em formatos regulares. O menor tamanho foi buscado justamente por se tratar de um sistema embarcado, onde a quantidade de memória disponível geralmente é pequena. - internamente todos os dados são tratados em 16 bits, porém os dados de entrada (amostras de áudio) são de 8 bits. Dessa maneira o processador trabalha com precisão estendida (característica geralmente de DSPs), visando minimizar os problemas com overflow e com problemas de arredondamento ocasionados pela instrução de multiplicação - conseguiu-se criar um banco com 16 registradores de 16 bits, o que garante uma boa alocação de registradores futuramente. - os registradores de uso geral podem ser usados para endereçamento sem problemas. 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. 12

14 7 ORGANIZAÇÃO A organização do processador segue o princípio de projeto adotado na definição da arquitetura. Optou-se por uma implementação multiciclo por ser mais eficiente que uma implementação monociclo e mais simples que uma implementação utilizando pipeline. Abaixo segue figura contendo as principais informações das definições feitas no projeto da organização do processador: Figura 7: Organização do processador Algumas definições sobre o controle ainda serão tomadas, por isso a parte dos jumps não está totalmente definida no datapath acima. 13

15 8 ESTADO ATUAL Do cronograma apresentado abaixo, todas as atividades previstas até o mês de maio estão terminadas. 1. Definição e implementação em linguagem de alto nível dos efeitos desejados 2. Familiarização com as ferramentas SystemC, ArchC e o pacote de ferramentas da Mentor Graphics 3. Projeto e Validação da arquitetura do ASIP (modelo funcional, sem precisão de ciclos) 4. Projeto e Validação da organização do ASIP (modelo com precisão de ciclos) 5. Projeto e Validação do ASIP em Baixo Nível 6. Desenvolvimento de Software para o ASIP 7. Integração e Teste 8. Relatório final 9. Entrega do Relatório à Banca Ativ. 02/04 03/04 04/04 05/04 06/04 07/04 08/04 09/04 10/04 11/04 1 X 2 X 3 X X 4 X X 5 X X X X 6 X X X X 7 X 8 X X 9 X 14

16 Referências [1] SystemC homepage. In [2] OSCI. SystemC Version 2.0 User s Guide, [3] The ArchC Resource Center. In [4] RIGO, Sandro, The ArchC Architecture Description Language v0.8.1 Reference Manual, Instituto de Computação - Unicamp, Laboratório de Sistemas de Computadores. 15