ANDR´EIA APARECIDA BARBIERO AMBIENTE DE SUPORTE AO PROJETO DE SISTEMAS EMBARCADOS

AMBIENTE DE SUPORTE AO PROJETO DE SISTEMAS EMBARCADOS

Disserta¸c˜ ao apresentada como requisito par- cial ` a obten¸c˜ ao do grau de Mestre. Pro- grama de P´ os-Gradua¸c˜ ao em Inform´ atica, Setor de Ciˆ encias Exatas, Universidade Fe- deral do Paran´ a.

Orientador: Prof. Dr. Roberto Andr´ e Hexsel

CURITIBA

2006

AMBIENTE DE SUPORTE AO PROJETO DE SISTEMAS EMBARCADOS

Disserta¸c˜ ao apresentada como requisito par- cial ` a obten¸c˜ ao do grau de Mestre. Pro- grama de P´ os-Gradua¸c˜ ao em Inform´ atica, Setor de Ciˆ encias Exatas, Universidade Fe- deral do Paran´ a.

Orientador: Prof. Dr. Roberto Andr´ e Hexsel

CURITIBA

2006

AMBIENTE DE SUPORTE AO PROJETO DE SISTEMAS EMBARCADOS

Disserta¸c˜ ao aprovada como requisito parcial ` a obten¸c˜ ao do grau de Mestre no Programa de P´ os-Gradua¸c˜ ao em Inform´ atica da Universidade

Federal do Paran´ a, pela Comisso formada pelos professores:

Orientador: Prof. Dr. Roberto Andr´ e Hexsel Departamento de Inform´ atica, UFPR Prof. Dr. V´ oldi Costa Zambenedetti

Departamento de Engenharia El´ etrica, PUCPR Prof. Dr. Sandro Rigo

Instituto de Computa¸c˜ ao, Unicamp Prof. Dr. Bruno M¨ uller Jr

Departamento de Inform´ atica, UFPR

Curitiba, 10 de Julho de 2006

AGRADECIMENTOS

Agrade¸co em primeiro lugar ao meu companheiro Zeno Stivanin pela paciˆ encia e apoio

constante. Ao professor Roberto Hexsel pela disponibilidade e pelas “inje¸c˜ oes” de ˆ animo

no decorrer do projeto. Ao bolsista Antˆ onio Massaro Neto pela ajuda na codifica¸c˜ ao do

simulador Atmega8515. A equipe de desenvolvedores do ArchC pelo r´ apido retorno no

esclarecimento de d´ uvidas. E ao LACTEC que serviu de inspira¸c˜ ao para este trabalho e

permitiu a utiliza¸c˜ ao de seus recursos para a realiza¸c˜ ao de testes.

SUM ´ ARIO

LISTA DE FIGURAS v

LISTA DE TABELAS vi

RESUMO vii

ABSTRACT viii

1 INTRODUC ¸ ˜ AO 1

2 REVIS ˜ AO BIBLIOGR ´ AFICA 5

2.1 Defini¸c˜ oes Preliminares . . . . 5

2.2 Metodologia de Desenvolvimento de Sistemas Embarcados . . . . 7

2.2.1 Especifica¸c˜ ao e Modelagem . . . . 9

2.2.2 Valida¸c˜ ao . . . . 12

2.2.3 S´ıntese . . . . 14

2.3 Blocos de Propriedade Intelectual e Reuso de Software . . . . 15

2.4 SystemC . . . . 17

2.5 Simuladores de Conjuntos de Instru¸c˜ oes . . . . 19

2.6 Trabalhos Relacionados . . . . 25

3 DESCRIC ¸ ˜ AO DOS MICROPROCESSADORES 27 3.1 Motorola DSP56F827 . . . . 27

3.2 Atmel Atmega8515 . . . . 31

3.3 Rabbit R2000 . . . . 34

4 DESENVOLVIMENTO DO AMBIENTE DE SIMULAC ¸ ˜ AO 38 4.1 Implementa¸c˜ ao dos Simuladores . . . . 38

4.1.1 Descri¸c˜ ao da Arquitetura da CPU . . . . 40

4.1.2 Descri¸c˜ ao da Sintaxe das Instru¸c˜ oes . . . . 42

4.1.3 Descri¸c˜ ao da Semˆ antica das Instru¸c˜ oes . . . . 44

4.2 Implementa¸c˜ ao das M´ etricas de Mem´ oria . . . . 46

5 AVALIAC ¸ ˜ AO DE DESEMPENHO 48 5.1 Descri¸c˜ ao do Ambiente de Testes . . . . 48

5.2 Compara¸c˜ ao entre os Processadores . . . . 50

5.3 Precis˜ ao do Modelo do DSP56F827 . . . . 54

5.4 Estudo de Caso - O Conversor Serial-IP . . . . 55 6 CONCLUS ˜ AO E TRABALHOS FUTUROS 58

A C ´ ODIGO FONTE DO SIMULADOR DSP56F827 61

B C ´ ODIGO FONTE DO SIMULADOR ATMEGA8515 67

C C ´ ODIGO FONTE DO SIMULADOR R2000 70

BIBLIOGRAFIA 81

LISTA DE FIGURAS

2.1 Fluxo Gen´ erico de Projeto de Sistemas Embarcados. . . . . 8

2.2 Estrutura da Linguagem SystemC. . . . . 18

2.3 Estrutura de um Contador em SystemC. . . . 19

2.4 Implementa¸c˜ ao do Processo de Contagem. . . . 19

2.5 Implementa¸c˜ ao da Interface de Leitura. . . . 19

2.6 Fluxo de um Simulador Interpretado. . . . 20

2.7 Fluxo de um Simulador Compilado. . . . 20

3.1 Segmenta¸c˜ ao das Instru¸c˜ oes no DSP56F827. . . . 31

3.2 Interface do CodeWarrior. . . . 32

3.3 Segmenta¸c˜ ao das Instru¸c˜ oes no Atmega8515. . . . 33

3.4 Interface do AVR Studio 4. . . . 34

3.5 Arquitetura de Mem´ oria do R2000. . . . 36

3.6 Interface do WinIDE 1.58.03. . . . . 37

4.1 Fluxo de Implementa¸c˜ ao de um Simulador Utilizando ArchC. . . . 39

4.2 Descri¸c˜ ao da Arquitetura Motorola DSP56F827 em ArchC. . . . 40

4.3 Descri¸c˜ ao da Arquitetura Atmega8515. . . . 42

4.4 Descri¸c˜ ao do Conjunto de Instru¸c˜ oes do DSP56F827 em ArchC (parte). . . 43

4.5 Descri¸c˜ ao do Comportamento de uma Instru¸c˜ ao (semˆ antica) do DSP56F827. 44 4.6 Incremento do Contador de Programa no R2000. . . . 45

4.7 C´ odigo que Computa o Tamanho da Mem´ oria de Programa. . . . 46

4.8 Trecho do C´ odigo que Computa o Tamanho da Mem´ oria de Dados. . . . . 47

5.1 Exemplo de um Arquivo de Teste em Formato Hexadecimal. . . . 50

5.2 Utiliza¸c˜ ao da Mem´ oria de Dados. . . . 52

5.3 Utiliza¸c˜ ao da Mem´ oria de Programa. . . . 52

5.4 N´ umero de Ciclos Executados. . . . 53

5.5 N´ umero de Instru¸c˜ oes Executadas. . . . . 54

5.6 Estrutura do Projeto Serial-IP. . . . . 56

LISTA DE TABELAS

3.1 Principais Caracter´ısticas dos Microprocessadores. . . . 27

5.1 Programas de Teste. . . . . 48

5.2 Utiliza¸c˜ ao de Mem´ oria. . . . 51

5.3 N´ umero de Ciclos e Instru¸c˜ oes Executadas . . . . 51

5.4 Compara¸c˜ ao entre Modelo e Processador DSP56F827. . . . . 55

5.5 Resultado Obtido com um Trecho da Pilha TCP/IP/PPP. . . . 56

RESUMO

O crescimento na produ¸c˜ ao de hardware e software para sistemas embarcados exige que o tempo de projeto seja cada vez mais curto. Assim, s˜ ao necess´ arias ferramentas que auxiliem os projetistas na escolha do hardware mais adequado para uma determinada aplica¸c˜ ao e que possibilitem o in´ıcio do desenvolvimento do c´ odigo antes da conclus˜ ao do hardware. Este trabalho descreve um ambiente de simula¸c˜ ao que permite escolher o processador mais adequado ainda na fase inicial de um projeto e iniciar a codifica¸c˜ ao do firmware imediatamente.

O ambiente de simula¸c˜ ao consiste de simuladores que permitem estimar, atrav´ es de simula¸c˜ oes precisas, m´ etricas de desempenho como tempo de execu¸c˜ ao e mem´ oria utilizada em c´ odigo, pilha e conjunto de dados. As m´ etricas de mem´ oria s˜ ao uma contribui¸c˜ ao in´ edita deste trabalho ` a ferramenta ArchC.

O ambiente suporta os processadores Motorola DSP56F827, Rabbit R2000 e Atmel Atmega8515 e pode ser facilmente expandido com outros processadores das fam´ılias dos j´ a citados. O trˆ es microprocessadores foram escolhidos por serem bastante populares do dom´ınio de sistemas embarcados.

Os simuladores foram desenvolvidos utilizando a Linguagem de Descri¸c˜ ao de Arquite- turas ArchC que ´ e baseada na linguagem de modelagem de hardware SystemC.

A constru¸c˜ ao dos simuladores foi relativamente trabalhosa, principalmente tratando- se de arquiteturas complexas, como ´ e o caso do microprocessador DSP56F827. Ao todo foram necess´ arias mais de 26.000 linhas de c´ odigo para descrever as instru¸c˜ oes dos trˆ es processadores.

Os testes realizados permitiram a compara¸c˜ ao dos processadores em rela¸c˜ ao ` a m´ etricas

de desempenho tais como tempo de execu¸c˜ ao e mem´ oria utilizada. Em compara¸c˜ oes

efetuadas entre o simulador e um m´ odulo de hardware do processador DSP56F827 foi

constatado que o simulador possui precis˜ ao melhor que 85%.

ABSTRACT

The dynamics of the embedded computing market force the design cycles to be rather short. Thus, efficient tools are needed to assist designers in choosing the right components early in the design cycle and make possible the beginning of the software development before the conclusion of the hardware. This work describes a simulation environment that allows to choose the most adequate processor still in the initial phase of a project and to initiate the codification of firmware immediately. The tools provide performance metrics like execution time and memory usage – code, stack and data set sizes. The memory measurements are a great contribution of this work to ArchC tools.

The environment supports the processors Motorola DSP56F827, Rabbit R2000 and Atmel Atmega8515. The three microprocessors had been chosen for being popular in the domain of embedded systems.

The simulators were developed using the ArchC Architecture Description Language that is based on the hardware modeling language SystemC.

The construction of the simulators was relatively laborious, especially for the more complex architecture which is the case of microprocessor DSP56F827. In all, over 26.000 lines of code were necessary to model the three processors.

The tests performed had allowed the comparison of the processors regarding to per-

formance metrics such as, the execution time and memory usage. Comparisons between a

hardware module of processor DSP56F827 and the its model had shown that the simulator

accuracy is better that 85%.

CAP´ ITULO 1 INTRODUC ¸ ˜ AO

Um relat´ orio publicado pela Intel em 2000 mostrava que apenas 2% de todos os processa- dores fabricados no mundo eram destinados a aplica¸c˜ oes desktop. Os 98% restantes eram divididos em aplica¸c˜ oes de rob´ otica (6%), sistemas automotivos (12%), e 80% usados em sistemas embarcados [55]. As aplica¸c˜ oes mais comuns deste ´ ultimo mercado s˜ ao telefones celulares, brinquedos, eletrodom´ esticos e outros equipamentos eletrˆ onicos. Estes produ- tos s˜ ao projetados sob restri¸c˜ oes de recursos tais como energia consumida, utiliza¸c˜ ao de mem´ oria, tamanho do circuito integrado, e principalmente de custo. No custo deve ser in- clu´ıdo, al´ em dos componentes de hardware, o desenvolvimento do hardware e de software aplicativo.

Existe uma fatia de mercado na qual desempenho e a confiabilidade s˜ ao cr´ıticos en- quanto que baixo consumo de energia ´ e desej´ avel mas n˜ ao obrigat´ orio. Nestes casos, o foco do projeto ´ e o desenvolvimento eficiente do software e a escolha do processador com a melhor rela¸c˜ ao custo/desempenho. Os produtos desenvolvidos para este tipo de mer- cado s˜ ao destinados, geralmente, para automa¸c˜ ao de processos em setores de gera¸c˜ ao e distribui¸c˜ ao de energia el´ etrica, telecomunica¸c˜ oes e ind´ ustria em geral.

N˜ ao ´ e raro que os projetos neste segmento possuam o seguinte perfil: (i) tratam- se de aplica¸c˜ oes “novas” com a especifica¸c˜ ao do sistema ainda incompleta; (ii) existem ao menos duas op¸c˜ oes de microprocessadores; e (iii) alguns componentes de software j´ a encontram-se dispon´ıveis, tais como uma implementa¸c˜ ao da pilha TCP/IP ou um algo- ritmo de criptografia. Neste caso, quest˜ oes como “qual processador atender´ a aos requisitos de desempenho e/ou consumo?” e “quanta mem´ oria ser´ a necess´ aria?” devem ser respon- didas no in´ıcio do processo de desenvolvimento.

Quando apenas a experiˆ encia dos projetistas ´ e utilizada para responder ` aquelas per-

guntas alguns problemas podem ocorrer. Dentre eles salientam-se o sub- ou o super-

dimensionamento de recursos, perda de tempo e o conseq¨ uente aumento no custo de desenvolvimento. H´ a super-dimensionamento quando s˜ ao utilizados recursos al´ em do ne- cess´ ario para determinada aplica¸c˜ ao, como a utiliza¸c˜ ao de um processador poderoso e caro para executar uma aplica¸c˜ ao simples. No sub-dimensionamento ocorre o contr´ ario, e a capacidade do hardware n˜ ao ´ e suficiente para satisfazer aos requisitos de desempenho, como em uma aplica¸c˜ ao que demanda mais mem´ oria do que o dispon´ıvel no microcon- trolador escolhido. Neste caso pode ocorrer a inutiliza¸c˜ ao de placas de circuito impresso e seu re-projeto para a inclus˜ ao de mais mem´ oria. Em ambos os exemplos, ´ e evidente o aumento no custo e no tempo de desenvolvimento.

Este trabalho descreve um ambiente de simula¸c˜ ao que pode auxiliar projetistas na escolha de um processador que atenda aos requisitos de sua aplica¸c˜ ao. Os simuladores do ambiente cont´ em modelos detalhados de processadores de 8 e 16 bits, de trˆ es fabrican- tes distintos. Os simuladores permitem prever com razo´ avel precis˜ ao, no in´ıcio do ciclo de desenvolvimento, (1) se determinado processador tem desempenho suficiente para a aplica¸c˜ ao, (2) qual ser´ a o tamanho do c´ odigo compilado, e (3) qual a capacidade m´ınima da mem´ oria de dados. Com estimativas precisas e referidas ` a aplica¸c˜ ao ´ e mais prov´ avel que a escolha do processador ou microcontrolador seja a acertada. A maioria dos fabri- cantes n˜ ao fornece ferramentas adequadas para este tipo de compara¸c˜ ao, ao contr´ ario, as ferramentas s˜ ao dirigidas ` a sua linha de produtos, na forma de software propriet´ ario e com custo elevado, como ´ e o caso de [19], por exemplo.

Os simuladores foram implementados com a linguagem de descri¸c˜ ao de arquitetura ArchC [50, 6], que por sua vez ´ e baseada em SystemC [31]. ArchC permite modelar um processador de forma mais abstrata do que as linguagens de descri¸c˜ ao de hardware convencionais como Verilog e VHDL. ArchC permite descrever a arquitetura desejada de forma eficiente e r´ apida, e a partir da descri¸c˜ ao gera automaticamente o simulador apropriado, que ´ e capaz de estimar o tempo de execu¸c˜ ao e o n´ umero de acessos ` a mem´ oria.

Correntemente, est˜ ao implementados modelos de trˆ es microcontroladores amplamente

utilizados no mercado, que s˜ ao: o Motorola DSP56F827 [47], Rabbit R2000 [48], e At-

mel Atmega8515 [7]. Estes foram escolhidos por conta de nosso envolvimento em projetos

em que estes seriam poss´ıveis candidatos [39, 60]. Al´ em dos trˆ es citados acima, os simula- dores podem ser facilmente expandidos para aceitar a simula¸c˜ ao de outros processadores das trˆ es fam´ılias, j´ a que na maioria das vezes o conjunto de instru¸c˜ oes n˜ ao sofre grandes altera¸c˜ oes, apenas se adiciona ou remove algumas fun¸c˜ oes. Por exemplo, o simulador do microprocessador DSP56F827 pode facilmente simular o microprocessador DSP56F826.

O simulador do microprocessador Rabbit R2000 foi testado parcialmente, devido a problemas com o ambiente de gera¸c˜ ao do c´ odigo execut´ avel que ´ e utilizado como entrada para o simulador.

Para agregar mais informa¸c˜ oes ´ uteis ao conjunto de m´ etricas disponibilizado pela linguagem ArchC foi desenvolvido, neste trabalho, uma medida para o tamanho, ou uti- liza¸c˜ ao, da mem´ oria de dados e de programa. A m´ etrica da utiliza¸c˜ ao da mem´ oria de dados inclui a medi¸c˜ ao dinˆ amica dos tamanhos m´ aximos de heap e pilha.

O objetivo deste trabalho ´ e disponibilizar um recurso eficiente e eficaz para a sele¸c˜ ao de processadores e especifica¸c˜ ao de mem´ oria, e que permita otimizar o processo de desen- volvimento de sistemas embarcados. Al´ em disso, a disponibilidade de um simulador na fase inicial de um projeto possibilita que o desenvolvimento de software seja iniciado antes que haja hardware dispon´ıvel, permitindo o levantamento antecipado das caracter´ısticas dos algoritmos e de detalhes obscuros da especifica¸c˜ ao. A utiliza¸c˜ ao de modelos para simular as aplica¸c˜ oes antes do desenvolvimento ´ e recomendada principalmente quando se trata de aplica¸c˜ oes complexas [58].

Al´ em dos argumentos j´ a apresentados, parte da motiva¸c˜ ao para este trabalho ´ e a carˆ encia, no mercado brasileiro de sistemas embarcados, de ferramentas e recursos que auxiliem no desenvolvimento das aplica¸c˜ oes. O mercado de sistemas embarcados ´ e bas- tante abrangente e oferece diversas possibilidades, portanto ´ e necess´ ario um esfor¸co mais dirigido por parte da comunidade de Computa¸c˜ ao no sentido de aperfei¸coar e criar novas t´ ecnicas e ferramentas para impulsionar o crescimento desta ´ area.

Um exemplo da crescente importˆ ancia desta ´ area no Brasil ´ e a cria¸c˜ ao do projeto

CI Brasil pelo Minist´ erio de Ciˆ encia e Tecnologia, que visa a cria¸c˜ ao de cinco centros

de projeto para cria¸c˜ ao e fabrica¸c˜ ao de circuitos integrados eletrˆ onicos comerciais. O

CEITEC [18] ´ e um destes centros e est´ a em fase de constru¸c˜ ao da sede em Porto Alegre.

O texto est´ a organizado como segue. Alguns conceitos sobre desenvolvimento de siste-

mas embarcados e trabalhos relacionados s˜ ao discutidos no Cap´ıtulo 2. No Cap´ıtulo 3 s˜ ao

descritos os microprocessadores utilizados no trabalho. O desenvolvimento do projeto e a

avalia¸c˜ ao de desempenho s˜ ao vistos, respectivamente, nos Cap´ıtulos 4 e 5. A conclus˜ ao e

as propostas para a expans˜ ao do ambiente de desenvolvimento, est˜ ao no Cap´ıtulo 6. Os

Apˆ endices A, B e C mostram os modelos de algumas instru¸c˜ oes dos microprocessadores,

codificados na linguagem ArchC.

CAP´ ITULO 2

REVIS ˜ AO BIBLIOGR ´ AFICA

Neste cap´ıtulo ´ e apresentada a base te´ orica para o desenvolvimento do trabalho. A Se¸c˜ ao 2.1 apresenta alguns conceitos b´ asicos de sistemas embarcados; na Se¸c˜ ao 2.2 ´ e des- crita uma metodologia gen´ erica de desenvolvimento de sistemas embarcados; a Se¸c˜ ao 2.3 discute sobre o reuso de software e os blocos de propriedade intelectual; a Se¸c˜ ao 2.4 apresenta a linguagem de modelagem de hardware, SystemC e nas Se¸c˜ oes 2.5 e 2.6 s˜ ao mostradas as t´ ecnicas de simula¸c˜ ao de sistemas embarcados e os trabalhos relacionados, respectivamente.

2.1 Defini¸ c˜ oes Preliminares

Devido a evolu¸c˜ ao dos sistemas embarcados e do crescimento da utiliza¸c˜ ao destes no cotidiano, v´ arios grupos tem direcionado seus esfor¸cos nesta ´ area. Os principais objetos de estudo est˜ ao relacionados ao aumento de desempenho, economia de recursos cr´ıticos (energia consumida e utiliza¸c˜ ao de mem´ oria, por exemplo), seguran¸ca, confiabilidade, reuso de software e metodologias de projeto.

O projeto de um sistema embarcado ´ e bastante complexo, pois requer conhecimentos sobre quest˜ oes geralmente pouco exploradas ou ignoradas em aplica¸c˜ oes desktop, como por exemplo a restri¸c˜ ao ao consumo de energia e a pouca disponibilidade de mem´ oria.

A complexidade do projeto tamb´ em est´ a relacionada ao espa¸co arquitetural, que torna

a explora¸c˜ ao das op¸c˜ oes para a constru¸c˜ ao de um sistema ainda mais dif´ıcil. A arquitetura

de hardware de um sistema embarcado pode conter um ou mais processadores, mem´ orias

de v´ arios tipos, interfaces para perif´ ericos e blocos dedicados. Os componentes s˜ ao in-

terligados por uma estrutura de comunica¸c˜ ao que pode variar de um barramento a uma

rede complexa (Network-on-Chip ou NoC ). No caso de sistemas contendo componen-

tes program´ aveis, o software de aplica¸c˜ ao pode ser composto por m´ ultiplos processos,

distribu´ıdos entre diferentes processadores e comunicando-se atrav´ es de mecanismos va- riados [17]. Em muitos casos ´ e necess´ ario a implementa¸c˜ ao de um sistema operacional de tempo real (RTOS ) para auxiliar no gerenciamento e sincroniza¸c˜ ao dos processos [12].

Os processadores podem ser de arquiteturas diversas: RISC, VLIW, DSP e Processa- dores Integrados para Aplica¸ c˜ oes Espec´ıficas (ASIP). O uso de pipeline e a explora¸c˜ ao de paralelismo em geral j´ a s˜ ao aplicados em processadores de sistemas embarcados [33].

O projeto de hierarquia de mem´ oria tamb´ em segue os padr˜ oes cl´ assicos de computa¸c˜ ao, cache e mem´ oria principal [33], apesar de alguns estudos questionarem a usabilidade da mem´ oria cache para sistemas embarcados, j´ a que o seu consumo de energia ´ e bastante elevado [17].

Em muitas aplica¸c˜ oes, ´ e necess´ aria a integra¸c˜ ao do software e do hardware em uma

´

unica pastilha, em um sistema chamado de System-on-Chip ou SoC. Neste caso, quando as restri¸c˜ oes de recursos tais como potˆ encia, mem´ oria e tempo, tornam-se cr´ıticas, pode ser indispens´ avel o desenvolvimento de um Circuito Integrado para Aplica¸ c˜ ao Espec´ıfica (ASIC ) ou um Field Programmable Gate Array (FPGA). Pesquisas recentes, indicam a necessidade de algumas aplica¸c˜ oes em utilizar Multiprocessor-on-Chips (MPSoCs ), o que aumenta consideravelmente a complexidade de um sistema [37].

Um FPGA ´ e um circuito program´ avel composto por um conjunto de c´ elulas l´ ogicas ou blocos l´ ogicos alocados em forma de uma matriz. Em geral, a funcionalidade destes blocos e o roteamento s˜ ao configur´ aveis por software [1]. Tanto um ASIP quanto um ASIC se baseiam em um conjunto de m´ odulos de hardware constru´ıdo especialmente para uma determinada aplica¸c˜ ao. Os ASIPs s˜ ao processadores que possuem a arquitetura e o conjunto de instru¸c˜ oes personalizados para um dado sistema. Um exemplo de ASIP ´ e o processador R6, desenvolvido para fins did´ aticos e utilizado na PUC-RS [46]. Um ASIP deve ser implementado sobre uma plataforma de hardware tamb´ em espec´ıfica, que pode ser um ASIC ou um FPGA.

Os ASICs s˜ ao bastante utilizados em produtos eletrˆ onicos constru´ıdos em larga escala,

como brinquedos e eletrodom´ esticos. Normalmente s˜ ao necess´ arios meses para construir

um ASIC, tornando este invi´ avel como ferramenta de avalia¸c˜ ao e prototipa¸c˜ ao de novos

produtos. Neste caso, a utiliza¸c˜ ao de um FPGA passa a ser a op¸c˜ ao mais interessante.

Geralmente um projeto de sistema embarcado necessita ser desenvolvido em um curto espa¸co de tempo para atender as necessidades do mercado. Para auxiliar nesta tarefa,

´ e necess´ ario o estudo de metodologias eficientes que atendam aos requisitos de tempo de projeto e que adicionem confiabilidade ` a aplica¸c˜ ao. A pr´ oxima se¸c˜ ao descreve uma metodologia formal para o desenvolvimento destes sistemas.

2.2 Metodologia de Desenvolvimento de Sistemas Embarcados

Devido a complexidade dos sistemas embarcados e a variedade de solu¸c˜ oes poss´ıveis no dom´ınio da aplica¸c˜ ao, ´ e necess´ aria a divis˜ ao do projeto em etapas de modo a facilitar o desenvolvimento e organizar o fluxo de tarefas. A Figura 2.1 mostra uma metodologia gen´ erica de projeto de sistemas embarcados [17] e como o projeto pode ser dividido.

O projeto de um sistema embarcado ´ e iniciado, normalmente, por uma especifica¸c˜ ao da funcionalidade desejada, descrita atrav´ es de uma linguagem ou formalismo adequado.

A seguir, explora-se o espa¸co de projeto arquitetural, com o objetivo de encontrar uma arquitetura que implemente as fun¸c˜ oes contidas na especifica¸c˜ ao inicial e que atenda aos requisitos de projeto, em termos de custo, desempenho, potˆ encia, ´ area, etc. O resultado final desta etapa ´ e uma macro-arquitetura (ou arquitetura abstrata), contendo um ou mais processadores de determinados tipos (DSP, microcontroladores) e outros componentes necess´ arios (mem´ orias, interfaces, blocos dedicados de hardware), todos interconectados atrav´ es de uma infra-estrutura de comunica¸c˜ ao (um ou mais barramentos ou uma NoC ).

Entre a especifica¸c˜ ao funcional e a macro-arquitetura, estabelece-se um mapeamento atrav´ es do qual cada fun¸c˜ ao do sistema ´ e atribu´ıda a um processador ou a um bloco dedi- cado de hardware. Este mapeamento ´ e tamb´ em chamado de particionamento de fun¸c˜ oes entre hardware e software ou ainda, entre blocos dedicados e fun¸c˜ oes implementadas por um processador de instru¸c˜ oes.

A explora¸c˜ ao do espa¸co de projeto deve ser capaz de responder a trˆ es quest˜ oes b´ asicas:

(1) Quantos e quais processadores e blocos dedicados de hardware s˜ ao necess´ arios? (2) Qual

´ e o mapeamento ideal entre fun¸c˜ oes e componentes de hardware? (3) Qual ´ e a estrutura

Figura 2.1: Fluxo Gen´ erico de Projeto de Sistemas Embarcados.

de comunica¸c˜ ao ideal para conectar os componentes entre si, tendo em vista as trocas de informa¸c˜ ao que devem ser realizadas entre as fun¸c˜ oes mapeadas para os componentes?

Para que a explora¸c˜ ao seja efetuada rapidamente, ´ e fundamental a existˆ encia de esti- madores que, a partir da especifica¸c˜ ao funcional do sistema, sejam capazes de informar com um grau de precis˜ ao adequado os valores de m´ etricas importantes de projeto como desempenho, potˆ encia, ´ area e consumo de mem´ oria.

Uma vez definida a macro-arquitetura, ´ e necess´ aria a gera¸c˜ ao do software para a mesma, a partir da especifica¸c˜ ao funcional do sistema. Idealmente, seria desej´ avel uma s´ıntese autom´ atica do software incluindo tanto o software aplicativo como o RTOS.

Os componentes de hardware e software selecionados para a macro-arquitetura podem

ter interfaces heterogˆ eneas, implementando diferentes protocolos de comunica¸c˜ ao. Neste

caso, ´ e necess´ aria a s´ıntese da comunica¸c˜ ao entre os componentes. Esta s´ıntese deve gerar

adaptadores (wrappers ) que fazem a convers˜ ao entre os diferentes protocolos.

Uma vez definidos os componentes de hardware da macro-arquitetura, incluindo a infraestrutura de comunica¸c˜ ao e os eventuais adaptadores, o hardware pode ser sinteti- zado. Numa primeira etapa, a macro-arquitetura pode ser expandida para uma micro- arquitetura, contendo o detalhamento de todos os componentes e suas interconex˜ oes pino- a-pino e considerando o funcionamento do circuito com precis˜ ao no n´ıvel de ciclo de rel´ ogio.

Numa segunda etapa, podem ser usadas ferramentas convencionais de s´ıntese de hardware, que a partir da micro-arquitetura produzem o layout final do circuito. Para tanto, ´ e ne- cess´ ario que a micro-arquitetura esteja descrita numa linguagem apropriada para estas ferramentas, como por exemplo VHDL [9] ou Verilog [40]. A existˆ encia pr´ evia de layouts para os componentes de hardware selecionados facilita bastante esta s´ıntese, que se limita ent˜ ao ao posicionamento e roteamento de c´ elulas.

Em todas as etapas da metodologia de projeto, ´ e necess´ aria a valida¸c˜ ao das descri¸c˜ oes funcionais e arquiteturais geradas. Normalmente, esta valida¸c˜ ao se d´ a por simula¸c˜ ao, sendo portanto necess´ aria a existˆ encia de simuladores adequados para o tratamento das linguagens utilizadas no projeto.

As pr´ oximas se¸c˜ oes descrevem as etapas formais do projeto de sistemas embarcados segundo Edwards e Vincentelli [27], s˜ ao elas: Especifica¸c˜ ao e Modelagem, Valida¸c˜ ao e S´ıntese. Na Especifica¸c˜ ao e Modelagem s˜ ao mapeados os requisitos e as restri¸c˜ oes da aplica¸c˜ ao e o produto desta etapa ´ e o modelo do sistema. A Valida¸c˜ ao ´ e utilizada para verificar se o sistema est´ a sendo desenvolvido corretamente. J´ a na S´ıntese, o sistema ´ e efetivamente desenvolvido.

2.2.1 Especifica¸ c˜ ao e Modelagem

O processo de desenvolvimento de um projeto pode ser encarado como uma seq¨ uˆ encia

de passos que transforma uma especifica¸c˜ ao descrita informalmente em uma especifica¸c˜ ao

detalhada, para ent˜ ao se transformar em um produto. Um projetista pode executar um

ou mais passos neste processo. Neste contexto, o processo de entrada ´ e a especifica¸ c˜ ao

e a sa´ıda ´ e a implementa¸ c˜ ao. Por exemplo, um programador de sistemas pode ver um

conjunto de rotinas em C como uma implementa¸c˜ ao do seu projeto na qual diversos outros passos foram executados antes do produto estar conclu´ıdo. Durante este processo a valida¸c˜ ao ´ e necess´ aria, principalmente para garantir desempenho e funcionalidade.

Infelizmente os v´ arios passos que comp˜ oem o processo de desenvolvimento s˜ ao, na maioria das vezes, descritos de maneira informal e n˜ ao possuem uma rela¸c˜ ao precisa entre os componentes. Neste caso, um modelo formal de projeto deve ser gerado e executado.

Um modelo formal de projeto consiste dos seguintes componentes:

• Uma especifica¸c˜ ao funcional que exibe as rela¸c˜ oes, impl´ıcitas e expl´ıcitas, entre os sinais de entrada, de sa´ıda e de controle;

• Um conjunto de propriedades que especificam as rela¸c˜ oes entre as entradas, sa´ıdas e estados e s˜ ao comparadas com a especifica¸c˜ ao funcional;

• Um conjunto de m´ etricas de desempenho; e

• Um conjunto de restri¸c˜ oes que est˜ ao relacionadas com as m´ etricas.

A especifica¸c˜ ao funcional caracteriza a opera¸c˜ ao do sistema, enquanto as restri¸c˜ oes de desempenho podem ser utilizadas para limitar o custo. As propriedades s˜ ao listadas separadamente porque elas s˜ ao mais simples, mais abstratas e tamb´ em mais incompletas quando comparadas com a especifica¸c˜ ao funcional.

Uma propriedade ´ e uma asser¸c˜ ao sobre o comportamento do sistema e n˜ ao uma des- cri¸c˜ ao do mesmo. Por exemplo, quando projeta-se um protocolo de rede ´ e desej´ avel que a implementa¸c˜ ao nunca entre em impasse (deadlock ). Esta propriedade pode ser chamada de liveness.

Um projeto ´ e representado geralmente por um conjunto de componentes que podem ser vistos como blocos isolados interagindo entre si. Um modelo de computa¸c˜ ao define o comportamento e a intera¸c˜ ao entre estes blocos. Existem v´ arios modelos de computa¸c˜ ao que podem ser utilizados para descrever sistemas embarcados [27]:

• Eventos Discretos: utilizado para modelagem de tempo;

• M´ aquinas de Estados Finitas (FSM): utilizadas para modelar comportamento sequˆ encial, mas invi´ avel para modelagem de concorrˆ encia e mem´ oria;

• S´ıncrono/Reativo: ordena eventos simultˆ aneos, utilizado em simuladores baseados em ciclo (cycle based );

• Rede de Fluxo de Dados: o sistema ´ e representado por um grafo direcionado, no qual os nodos representam o processamento, e as arestas a ordem dos eventos.

Para auxiliar na constru¸c˜ ao de um determinado modelo v´ arias linguagens podem ser utilizadas, cada qual com suas vantagens e desvantagens. A linguagem C, por exemplo, n˜ ao ´ e uma linguagem ideal para especifica¸c˜ ao, principalmente se o grau de abstra¸c˜ ao desejado e de generalidade da aplica¸c˜ ao s˜ ao elevados, mas possui a vantagem de permitir a gera¸c˜ ao de software para um grande n´ umero de processadores utilizados no contexto de sistemas embarcados.

A ado¸c˜ ao da orienta¸c˜ ao a objetos, como em C++, se por um lado ´ e vantajosa do ponto de vista de especifica¸c˜ oes de alto n´ıvel, na qual reuso e especializa¸c˜ ao de componentes s˜ ao caracter´ısticas muito interessantes, por outro lado causa problemas para a s´ıntese de hardware e tamanho do software, al´ em do potencial para comprometer o desempenho do sistema no que diz respeito a tempo de execu¸c˜ ao.

Na tentativa de aumentar as possibilidades de modelagem e abstra¸c˜ ao, Java tamb´ em tem sido utilizada como ferramenta de descri¸c˜ ao e simula¸c˜ ao de sistemas [34, 35]. Con- tudo, os problemas relacionados ` a s´ıntese de hardware e desempenho s˜ ao equivalentes aos provocados pelo C++.

As linguagens C, C++ e Java apresentam uma evidente desvantagem, tendo em vista

sua inadequa¸c˜ ao semˆ antica para a descri¸c˜ ao de aspectos de hardware. Para este tipo de

descri¸c˜ ao podem ser utilizadas linguagens espec´ıficas, como VHDL e Verilog. A grande

vantagem destas ´ e a possibilidade de se utilizar os modelos como entrada para simula¸c˜ ao

e s´ıntese autom´ atica de circuitos. A linguagem VHDL possui constru¸c˜ oes mais voltadas ` a

simula¸c˜ ao, de tal modo que algumas de suas constru¸c˜ oes n˜ ao s˜ ao sintetiz´ aveis, o que for¸ca

ferramentas de s´ıntese a aceitarem apenas um determinado sub-conjunto da linguagem

e/ou estilo de descri¸c˜ ao. As linguagens VHDL e Verilog tˆ em uma semˆ antica destinada apenas para a descri¸c˜ ao de hardware, n˜ ao sendo apropriadas para descri¸c˜ oes de software nem para especifica¸c˜ oes funcionais de alto n´ıvel.

Outras linguagens como Matlab [42], SpecC [29] e SDL [28] podem ser usadas. Matlab possui ` a facilidade de modelagem de fenˆ omenos f´ısicos e a possibilidade de descri¸c˜ oes mistas com sinais anal´ ogicos e digitais. A linguagem SpecC ´ e uma linguagem baseada em C e permite que a funcionalidade de um sistema seja capturada atrav´ es de uma rede hier´ arquica de comportamentos (behaviors ) conectados por canais hier´ arquicos (channels ).

A desvantagem desta linguagem ´ e que n˜ ao possui suporte ` a ferramentas de s´ıntese. A SDL foi criada originalmemte para a ´ area de telecomunica¸c˜ oes e possui a vantagem de permitir a especifica¸c˜ ao de sistemas concorrentes, por´ em ´ e fraca para descri¸c˜ ao de algoritmos porque n˜ ao possui primitivas de controle de fluxo tais como if, for, while.

Com o objetivo de manter o alto n´ıvel de abstra¸c˜ ao e possibilitar a descri¸c˜ ao do hard- ware, foi desenvolvida a linguagem SystemC [31]. O SystemC combina as vantagens do C++, e sua adequa¸c˜ ao ao processo de gera¸c˜ ao de software, com uma semˆ antica adicional (na forma de uma biblioteca de classes) apropriada para a descri¸c˜ ao de hardware. Devido a importˆ ancia do SystemC no escopo deste trabalho, suas caracter´ısticas ser˜ ao discutidas com mais detalhes na Se¸c˜ ao 2.4.

Apesar do avan¸co das linguagens de programa¸c˜ ao e especifica¸c˜ ao atuais, ainda n˜ ao ´ e poss´ıvel modelar simultˆ aneamente hardware e software e este ´ e um dos desafios da ´ area de pesquisa relacionada ao codesign [4, 59].

2.2.2 Valida¸ c˜ ao

O passo seguinte ` a constru¸c˜ ao do modelo ´ e a sua valida¸c˜ ao. A valida¸c˜ ao do sistema evolui conforme este ´ e desenvolvido e v´ arios passos s˜ ao requeridos at´ e se atingir n´ıveis satisfat´ orios de funcionalidade e desempenho.

A principal ferramenta utilizada nesta etapa ´ e a simula¸ c˜ ao. Idealmente, um simula-

dor de sistema embarcado deveria ser capaz de cobrir aspectos de hardware e software

permitindo a co-simula¸ c˜ ao. Por´ em, como visto anteriormente, nenhuma linguagem de pro-

grama¸c˜ ao consegue atender simultˆ aneamente todos os dom´ınios de uma aplica¸c˜ ao. Neste caso ´ e necess´ aria a valida¸c˜ ao de descri¸c˜ oes multi-linguagem em determinados passos do projeto.

Algumas ferramentas de co-simula¸c˜ ao atuais, como CoCentric System Studio, da Sy- nopsys [53], e Seamless CVE, da Mentor [45], permitem a integra¸c˜ ao de SystemC, C, simuladores de software no n´ıvel de instru¸c˜ oes de m´ aquina de um processador e lingua- gens de descri¸c˜ ao de hardware diversas, como VHDL e Verilog.

Na pr´ atica, utiliza-se um simulador de programas de prop´ osito geral, que simula a CPU escolhida executando o software de aplica¸c˜ ao, escrito em C por exemplo, sobre um deter- minado modelo, baseado em VHDL, Verilog, SystemC, entre outros. Estes simuladores podem ser classificados entre os modelos abaixo [27]:

• N´ıvel de Porta: Simula¸c˜ ao l´ ogica no n´ıvel de hardware e portas l´ ogicas. ´ E indicado para projetos simples onde o custo da valida¸c˜ ao pode ser pequeno.

• Conjunto de Instru¸ c˜ oes da Arquitetura (ISA): Simula o comportamento das ins- tru¸c˜ oes do processador (geralmente escrito em C), com informa¸c˜ oes da interface hardware/software;

• Barramento Funcional : S˜ ao modelos de hardware utilizados somente para testar a interface do processador. N˜ ao executam nenhum software, e ao inv´ es disso os simuladores s˜ ao programados para que a interface pare¸ca estar executando algum programa;

• Baseado em Tradu¸ c˜ ao: Estes simuladores convertem o c´ odigo que ser´ a executado no processador em um c´ odigo que pode ser executado nativamente pelo simula- dor. Al´ em da tradu¸c˜ ao do c´ odigo propriamente dita, uma grande dificuldade destes simuladores ´ e manter as informa¸c˜ oes de tempo do c´ odigo original.

Atualmente o modelo de Conjunto de Instru¸c˜ oes ´ e o mais utilizado, j´ a que permite

observar o comportamento da aplica¸c˜ ao no n´ıvel de instru¸c˜ oes e possibilita que a imple-

menta¸c˜ ao do software seja iniciada antes da conclus˜ ao do hardware. Outra vantagem ´ e

que ap´ os o t´ ermino do projeto o mesmo simulador pode ser reutilizado para simular ou- tras aplica¸c˜ oes destinadas ao mesmo processador. A Se¸c˜ ao 2.5 mostra o que s˜ ao e como implementar estes simuladores.

Uma outra alternativa para a valida¸c˜ ao ´ e a verifica¸c˜ ao formal, que consiste na va- lida¸c˜ ao matem´ atica do comportamento do sistema [27]. A verifica¸c˜ ao formal pode ser aplicada nas fases de (a) Especifica¸c˜ ao, para garantir que o sistema ser´ a capaz de atender aos requisistos de funcionamento, e durante (b) Implementa¸c˜ ao para identificar poss´ıveis inconsistˆ encias. Por exemplo, em [23] ´ e proposto um m´ etodo para modelagem e valida¸c˜ ao formal baseado nas Redes de Petri que promete capturar caracter´ısticas importantes do sistema e represent´ a-las em diferentes n´ıveis de granularidade.

A eficiˆ encia da verifica¸c˜ ao formal depende da complexidade do modelo utilizado e da aplica¸c˜ ao em si. Apesar de ser uma ´ area de estudo em crescimento, ainda n˜ ao atingiu um grau de maturidade que permita a sua aplica¸c˜ ao em todas as etapas do projeto e para diferentes dom´ınios de aplica¸c˜ ao [17].

2.2.3 S´ıntese

No processo de s´ıntese s˜ ao gerados refinamentos para transformar uma especifica¸c˜ ao mais abstrata em uma menos abstrata. Esta etapa ´ e geralmente dividida em: (i) mapeamento da arquitetura, (ii) particionamento e (iii) s´ıntese do software e do hardware.

Durante o mapeamento da arquitetura, o projetista define quais componentes e ferra- mentas ser˜ ao utilizados e decide se estas atendem ` as restri¸c˜ oes do sistema. Uma arquite- tura ´ e geralmente composta de:

• Componentes de Hardware: microprocessadores, mem´ orias, dispositivos de entrada/sa´ıda, ASICs e FPGAs ;

• Componentes de Software: sistema operacional, drivers de dispositivos e bibliotecas de fun¸c˜ oes;

• Canais de Interconex˜ ao: canais abstratos, barramentos e mem´ orias compartilhadas.

A escolha destes componentes depende da especifica¸c˜ ao funcional, dos requisitos e res- tri¸c˜ oes impostos ao projeto. Para auxiliar nesta tarefa ´ e recomendado o uso de estimadores ou simuladores.

O particionamento define quem vai fazer o quˆ e dentre o software e o hardware, geral- mente com base nos resultados de um simulador/estimador. Por exemplo, o projetista pode decidir implementar determinada fun¸c˜ ao em hardware para atender requisitos de desempenho.

Existem v´ arios estudos sobre particionamento autom´ atico [27]. Uma abordagem co- mum ´ e a utiliza¸c˜ ao de um estimador/simulador para identificar blocos com desempenho cr´ıtico. Ap´ os a identifica¸c˜ ao, estes blocos s˜ ao movidos para implementa¸c˜ ao em hardware.

Este processo ´ e repetido at´ e que uma solu¸c˜ ao razo´ avel seja encontrada.

Em [43, 44] ´ e descrito um sistema no qual a sele¸c˜ ao do hardware e/ou do software

´ e feita automaticamente de acordo com o consumo de energia, desempenho e utiliza¸c˜ ao de mem´ oria. Por exemplo, ser´ a selecionado para determinada aplica¸c˜ ao o algoritmo de ordena¸c˜ ao que possuir a melhor rela¸c˜ ao entre desempenho × consumo de energia × uti- liza¸c˜ ao de mem´ oria.

A fase final ´ e a s´ıntese do hardware e do software, quando estes s˜ ao implementados.

As entradas para esta fase s˜ ao a especifica¸c˜ ao funcional e o conjunto de recursos mapeado na arquitetura.

Para diminuir o tempo do projeto, alguns estudos prop˜ oem m´ etodos de s´ıntese au- tom´ atica de hardware e software. A ferramenta TEReCS [16], por exemplo, objetiva a s´ıntese autom´ atica de um RTOS m´ınimo e dedicado, com ˆ enfase nas estruturas de co- munica¸c˜ ao. O RTOS ´ e constru´ıdo a partir de uma biblioteca pr´ e-definida de servi¸cos denominada DREAMS.

2.3 Blocos de Propriedade Intelectual e Reuso de Software

Devido ` a expans˜ ao do mercado de sistemas embarcados ´ e pouco prov´ avel que uma empresa

desenvolva apenas um projeto desta natureza ou que deseje implementar m´ odulos j´ a

desenvolvidos e validados por outras equipes. Por conta disto, muitos esfor¸cos est˜ ao

sendo dedicados ao reuso de componentes de software e hardware, tamb´ em chamados de Intellectual Property Blocs ou blocos IP [17].

Atualmente ´ e poss´ıvel encontrar uma grande quantidade de fornecedores de compo- nentes IP de hardware e software [25]. No dom´ınio do software, os componentes que ge- ralmente s˜ ao reus´ aveis incluem pilhas de protocolos de comunica¸c˜ ao (TCP/IP, Wireless), sistemas operacionais, drivers de dispositivos, algoritmos de compacta¸c˜ ao e criptografia.

No ˆ ambito do hardware pode-se encontrar interfaces de comunica¸c˜ ao (Bluetooth, 802.11), codificadores/decodificadores de ´ audio e v´ıdeo e barramentos, dentre outros. A caracte- riza¸c˜ ao precisa dos componentes em termos das m´ etricas de projeto deve ser definida pelo projetista do sistema.

Numa situa¸c˜ ao ideal, componentes selecionados para uma dada macro-arquitetura te- riam interfaces compat´ıveis e poderiam ser conectados diretamente uns aos outros, ou ent˜ ao atrav´ es de uma estrutura de comunica¸c˜ ao tamb´ em consistente. Isto vale tanto para componentes de hardware, por exemplo conectados atrav´ es de um barramento padroni- zado, como para componentes de software, comunicando-se atrav´ es de fun¸c˜ oes padroniza- das dispon´ıveis numa API. Numa situa¸c˜ ao mais gen´ erica, no entanto, o projetista pode desejar reusar componentes j´ a dispon´ıveis que foram desenvolvidos em projetos anteriores, dentro de contextos diferentes, e que podem portanto apresentar interfaces inconsistentes.

Segundo [17], os componentes IP de hardware podem ser oferecidos de duas manei- ras distintas. Componentes hard, j´ a est˜ ao sintetizados para uma dada tecnologia-alvo e ´ e seu layout que ´ e comercializado, j´ a caracterizado quanto aos resultados obtidos em termos de ´ area, potˆ encia e desempenho. Sua restri¸c˜ ao, no entanto, ´ e a quase impossibili- dade de adapta¸c˜ ao para outra arquitetura e/ou tecnologia. Componentes soft, por outro lado, s˜ ao ofertados atrav´ es de descri¸c˜ oes de mais alto n´ıvel (tipicamente n´ıvel Register- Transfer (RT)), podendo ter suas interfaces e comportamentos adaptados, se necess´ ario, e sintetizados para diferentes tecnologias.

Componentes IP de software tamb´ em podem ser divididos em componentes hard, j´ a

compilados para um determinado processador e oferecidos atrav´ es de seu c´ odigo exe-

cut´ avel, e soft, descritos numa linguagem de alto n´ıvel.

A adapta¸c˜ ao de componentes IP a um novo projeto pode ocorrer de duas maneiras.

No caso de componentes soft, descri¸c˜ oes de alto n´ıvel est˜ ao dispon´ıveis e podem ser mo- dificadas de tal modo que as interfaces de componentes a serem conectados passem a ser consistentes entre si. A adapta¸c˜ ao pode tamb´ em afetar a pr´ opria funcionalidade do com- ponente, caso isto seja necess´ ario no contexto do novo projeto. No caso de componentes hard, no entanto, interfaces heterogˆ eneas n˜ ao podem ser adaptadas atrav´ es de modi- fica¸c˜ oes nas descri¸c˜ oes dos componentes. Neste caso, ´ e imprescind´ıvel o desenvolvimento de adaptadores de comunica¸c˜ ao.

Devido a importˆ ancia dos componentes IP no desenvolvimento de sistemas embarcados atuais, foi criado o projeto Brazil-IP [15], que ´ e um cons´ orcio constitu´ıdo por oito univer- sidades brasileiras, UNICAMP, USP, UFPE, UFCG, UFRGS, UFMG, UnB e PUC-RS, com o objetivo de formar m˜ ao-de-obra qualificada em projetos de hardware no Brasil.

2.4 SystemC

Devido a crescente necessidade de ferramentas que auxiliem no projeto de sistemas embar- cados, muitos esfor¸cos vem sendo direcionados ` a cria¸c˜ ao e aperfei¸coamento de linguagens de especifica¸c˜ ao e modelagem de sistemas. Atualmente observa-se uma competi¸c˜ ao acir- rada entre as linguagens, cada qual com suas vantagens e desvantagens [41]. Apesar da concorrˆ encia, a linguagem SystemC vem sendo adotada por diversos fabricantes como linguagem padr˜ ao de modelagem e simula¸c˜ ao. Uma compara¸c˜ ao recente entre modelos implementados em SystemC e Register Transfer Level (RTL) Hardware Description Lan- guage (HDL) mostrou que a simula¸c˜ ao utilizando SystemC pode ser at´ e 10.000 vezes mais r´ apida [51].

SystemC foi desenvolvido em 1999 atrav´ es de uma coopera¸c˜ ao entre a Synopsys, a CoWare/IMEC e a Universidade da Calif´ ornia - Irvine. Hoje em dia v´ arias empresas e institui¸c˜ oes comp˜ oem a Open SystemC Initiative (OSCI) e disponibilizam ferramentas e c´ odigo fonte na p´ agina do projeto [54].

SystemC ´ e uma biblioteca de classes que estende a linguagem C++ com o objetivo

de modelar sistemas. A biblioteca possibilita a descri¸c˜ ao de comportamento concorrente,

uma no¸c˜ ao de tempo em opera¸c˜ oes seq¨ uenciais, tipos de dados para descrever hardware, estrutura hier´ arquica e suporte ` a simula¸c˜ ao. A Figura 2.2 mostra a arquitetura do Sys- temC.

Figura 2.2: Estrutura da Linguagem SystemC.

O n´ ucleo da linguagem ´ e baseado em um simulador dirigido a evento que trabalha com eventos e processos. Tamb´ em s˜ ao inclu´ıdos no n´ ucleo da linguagem m´ odulos e portas para representar a estrutura bem como, interfaces e canais para descrever a comunica¸c˜ ao.

A biblioteca tamb´ em oferece um conjunto de tipos de dados necess´ arios para a mo- delagem de hardware e certos tipos para programa¸c˜ ao de software. Por fim, a biblioteca oferece um conjunto de primitivas como sinais e filas FIFO.

Em SystemC, um sistema pode ser modelado como uma cole¸c˜ ao de m´ odulos que cont´ em processos, portas e canais. Um processo define o comportamento de um m´ odulo espec´ıfico e disponibiliza m´ etodos para expressar concorrˆ encia. Um canal implementa uma ou mais interfaces, onde uma interface ´ e uma cole¸c˜ ao de m´ etodos ou fun¸c˜ oes. Um processo acessa a interface de um canal atrav´ es de uma porta [21]. A Figura 2.3 mostra a estrutura de um contador ou timer [22].

O contador possui uma interface que permite configurar o(s) registrador(es) para lei-

tura ou escrita. Quando o contador expira, uma interrup¸c˜ ao ´ e enviada para a porta da

interrup¸c˜ ao. Deve existir tamb´ em uma conex˜ ao com o rel´ ogio do sistema (clock ) atrav´ es

Figura 2.3: Estrutura de um Contador em SystemC.

de outra porta.

O processo de contagem consiste em decrementar o contador toda vez que uma borda do rel´ ogio ´ e detectada (subida ou descida). Se o contador chegar a zero ´ e gerada uma interrup¸c˜ ao. As Figuras 2.4 e 2.5 mostram um exemplo de implementa¸c˜ ao, em SystemC, do processo de contagem e da interface de leitura.

void timer::tick() {

...

if (--this->count == 0) this->interruptPort = 1;

...

}

Figura 2.4: Implementa¸c˜ ao do Processo de Contagem.

void timer::read(int register, unsigned char *value) {

*value = this->regs[register];

}

Figura 2.5: Implementa¸c˜ ao da Interface de Leitura.

2.5 Simuladores de Conjuntos de Instru¸ c˜ oes

Um simulador de conjunto de instru¸c˜ oes ou Instruction Set Simulator (ISS) ´ e uma ferra-

menta que imita o comportamento da execu¸c˜ ao de uma aplica¸c˜ ao em uma dada arquite-

tura. Os ISSs s˜ ao usados para validar o projeto da arquitetura, o projeto de um compi-

lador, bem como para avaliar as decis˜ oes do espa¸co arquitetural durante a explora¸c˜ ao do

dom´ınio.

Os ISSs podem ser Compilados ou Interpretados [49]. Os simuladores interpretados s˜ ao flex´ıveis, pois permitem a simula¸c˜ ao de qualquer arquitetura e aplica¸c˜ ao, por´ em s˜ ao lentos. Nesta t´ ecnica, uma instru¸c˜ ao ´ e buscada, decodificada e executada em tempo de execu¸c˜ ao, como mostra a Figura 2.6. A decodifica¸c˜ ao da instru¸c˜ ao ´ e a etapa que mais consome tempo na simula¸c˜ ao. Em [50, 8] utiliza-se uma cache para armazenamento das instru¸c˜ oes decodificadas para minimizar o problema.

Figura 2.6: Fluxo de um Simulador Interpretado.

Para resolver o problema da velocidade de simula¸c˜ ao, o simulador compilado decodifica as instru¸c˜ oes em tempo de compila¸c˜ ao, conforme ´ e mostrado na Figura 2.7. No entanto, os simuladores compilados dependem que o c´ odigo do programa seja conhecido antes da gera¸c˜ ao do simulador. A aplica¸c˜ ao passa por um processo de compila¸c˜ ao e o c´ odigo intermedi´ ario ´ e gerado com a decodifica¸c˜ ao das instru¸c˜ oes j´ a efetuada [14]. Esta t´ ecnica aumenta substancialmente a velocidade de simula¸c˜ ao mas perde em flexibilidade, j´ a que cada simula¸c˜ ao de uma nova aplica¸c˜ ao requer uma nova compila¸c˜ ao do simulador. Al´ em disso, o simulador n˜ ao permite a simula¸c˜ ao de c´ odigos que se auto-modificam ou que carregam bibliotecas em tempo de execu¸c˜ ao. As linguagens ArchC [50] e ABSCISS [5]

permitem a implementa¸c˜ ao deste tipo de simulador, como ser´ a visto adiante.

Figura 2.7: Fluxo de um Simulador Compilado.

Um simulador pode ser funcional ou com precis˜ ao de ciclo (cycle-accurate ). Com a

simula¸c˜ ao funcional pode-se verificar e testar o comportamento das instru¸c˜ oes e a funci- onalidade b´ asica do sistema modelado. A descri¸c˜ ao das instru¸c˜ oes para os simuladores com precis˜ ao de ciclo deve conter informa¸c˜ oes detalhadas sobre o tempo de execu¸c˜ ao de cada instru¸c˜ ao. Os simuladores podem modelar implementa¸c˜ oes multi-ciclo ou segmen- tado (pipeline ). Num simulador multi-ciclo declara-se o n´ umero de ciclos necess´ ario para executar cada tipo de instru¸c˜ ao, enquanto que em um simulador segmentado a descri¸c˜ ao deve conter um modelo detalhado dos segmentos do processador bem como de circuitos de adiantamento ou de bloqueios [33].

Devido a necessidade de aumentar a velocidade de desenvolvimento de um sistema embarcado e permitir a utiliza¸c˜ ao do simulador nas fases iniciais do projeto, ´ e necess´ ario que os simuladores n˜ ao demandem muito tempo para constru¸c˜ ao.

Para auxiliar nesta tarefa foram introduzidas as Linguagens de Defini¸c˜ ao de Arquite- tura ou Architectute Description Languages (ADLs). As ADLs podem ser classificadas considerando dois aspectos, (1) conte´ udo e (2) objetivo. A classifica¸c˜ ao orientada ao conte´ udo ´ e baseada na natureza da informa¸c˜ ao que a ADL pode descrever enquanto que a classifica¸c˜ ao orientada ao objetivo ´ e baseada no prop´ osito da ADL. Por exemplo, a ADL pode ser orientada ` a simula¸c˜ ao, orientada ` a s´ıntese, orientada ` a teste, orientada ` a compila¸c˜ ao, orientada ` a valida¸c˜ ao e orientada ao Sistema Operacional.

Com base na natureza da informa¸c˜ ao, pode-se ainda subclassificar as ADLs como es- truturais, comportamentais, parciais e mistas. As ADLs estruturais descrevem a estrutura em termos da arquitetura de componentes e sua conectividade. J´ a as ADLs comportamen- tais descrevem o comportamento do conjunto de instru¸c˜ oes da arquitetura do processador.

As ADLs mistas agregam mais que um aspecto apresentados anteriormente. J´ a as parciais s˜ ao linguagens que descrevem informa¸c˜ oes espec´ıficas sobre a arquitetura para uma deter- minada tarefa, como por exemplo uma ADL destinada a s´ıntese da interface n˜ ao requer a descri¸c˜ ao do comportamento do processador. Segue abaixo a descri¸c˜ ao de algumas ADLs:

Lisa. Language for Instruction Set Architecture - LISA [61] foi desenvolvida na Aachen

University of Technology (Alemanha) com o objetivo de produzir simuladores de qualidade

de produ¸c˜ ao. Um aspecto importante da linguagem LISA ´ e sua habilidade de descrever explicitamente o caminho de controle. A modelagem expl´ıcita do caminho de dados e de controle ´ e necess´ aria para a simula¸c˜ ao precisa dos ciclos. Quando foi introduzida, a principal contribui¸c˜ ao de LISA foi a capacidade de descri¸c˜ ao de pipeline e de modelos seq¨ uenciais. Algumas desvantagens de LISA s˜ ao a complexidade da implementa¸c˜ ao para descrever formatos de instru¸c˜ oes complexos e a falta de ferramentas de dom´ınio p´ ublico para manipula¸c˜ ao da linguagem.

EXPRESSION. EXPRESSION [32] ´ e uma Linguagem de Descri¸c˜ ao de Arquite- tura de c´ odigo livre focada na explora¸c˜ ao do espa¸co arquitetural para SoCs e na gera¸c˜ ao autom´ atica de compiladores e simuladores. O ponto forte da linguagem ´ e o suporte ` a es- pecifica¸c˜ ao de hierarquia de mem´ oria. A ADL EXPRESSION, fornece ferramentas para gera¸c˜ ao do EXPRESS, um compilador otimizado que permite paralelismo em n´ıvel de instru¸c˜ oes, e do SIMPRESS, um simulador funcional da linguagem.

Sleipnir. Sleipnir ´ e uma ADL que tem o objetivo de facilitar a descri¸c˜ ao das arquite- turas e de prover informa¸c˜ oes sobre desempenho [36]. Os simuladores constru´ıdos atrav´ es da Sleipnir s˜ ao port´ aveis e podem ser executados em diferentes plataformas. Para me- lhorar o tempo de simula¸c˜ ao, a Sleipnir utiliza os conceitos de simula¸c˜ ao compilada e gera c´ odigo intermedi´ ario que cont´ em as instru¸c˜ oes decodificadas. Uma desvantagem do Sleipnir ´ e a dificuldade em descrever arquiteturas com conjunto de instru¸c˜ oes complexos, como o de processadores superscalares.

ABSCISS. A ABSCISS [5] ´ e um gerador de simuladores compilados de conjunto de instru¸c˜ oes que efetua a simula¸c˜ ao de c´ odigos escritos em Assembly. Os simuladores gerados podem ser de precis˜ ao de ciclo (cycle-accurate ) ou funcionais. Ao contr´ ario da maioria dos geradores de simuladores, o ABSCISS aceita como entrada um arquivo escrito em Assembly, o que dispensa a descri¸c˜ ao dos opcodes e o uso de montadores e ligadores.

Esta caracter´ıstica aumenta consideravelmente o tempo de descri¸c˜ ao da arquitetura. Um

inconveniente da abordagem no n´ıvel de montador ´ e a baixa precis˜ ao na simula¸c˜ ao de

caches. Isto ocorre devido ao ABSCISS atribuir por conta pr´ opria os endere¸cos de dados e de instru¸c˜ oes, possivelmente de forma diferente que um ligador original.

GAPH. A equipe do Grupo de Apoio ao Projeto de Hardware (GAPH) [46] apresenta uma ferramenta que permite a defini¸c˜ ao e a reconfigura¸c˜ ao de uma arquitetura imple- mentada em FPGAs. O conjunto de instru¸c˜ oes, as opera¸c˜ oes da ULA, e o conjunto de registradores podem ser configurados. Esta ferramenta ´ e ´ util como um recurso did´ atico pois permite a explora¸c˜ ao do espa¸co de projeto, mas n˜ ao ´ e suficientemente poderosa para permitir a descri¸c˜ ao de um processador comercial relativamente complexo, pois n˜ ao h´ a suporte ` a segmenta¸c˜ ao.

CACO-PS. O Cycle-Accurate Configurable Power Simulator (CACO-PS) [13] per- mite a descri¸c˜ ao de arquiteturas atrav´ es de uma linguagem pr´ opria que relaciona sinais de entrada aos sinais de sa´ıda, e onde uma biblioteca em C cont´ em descri¸c˜ oes do compor- tamento dos componentes da arquitetura. O CACO-PS permite otimizar uma aplica¸c˜ ao com rela¸c˜ ao ao consumo de energia seja pelo re-projeto de algum componente “quente”, ou pela escolha de um algoritmo mais adequado. Os arquivos de entrada (mem´ oria de programa e de dados) devem ser gerados com a ferramenta Sashimi a partir de programas escritos em Java [35].

ArchC. ArchC ´ e uma especializa¸c˜ ao do SystemC com o objetivo de gera¸c˜ ao au-

tom´ atica de simuladores [50]. ArchC utiliza as bibliotecas do SystemC para modelar

o hardware a ser simulado, e inclui ferramentas capazes de automatizar o processo de

constru¸c˜ ao do simulador. Para gerar um simulador de uma CPU com ArchC ´ e necess´ ario

descrever as caracter´ısticas b´ asicas da organiza¸c˜ ao da CPU e descrever a sintaxe e a

semˆ antica do conjunto de instru¸c˜ oes. Na vers˜ ao 1.6 do ArchC, os arquivos com a des-

cri¸c˜ ao da organiza¸c˜ ao (arquitetura), e do conjunto de instru¸c˜ oes s˜ ao submetidos ao pr´ e-

processador do ArchC, que gera automaticamente a estrutura do simulador. O arquivo

com a semˆ antica do conjunto de instru¸c˜ oes ´ e gerado e deve ser preenchido com a descri¸c˜ ao

do comportamento das instru¸c˜ oes.

ArchC pode suportar trˆ es tipos de simuladores: (a) funcional, (b) multi-ciclo e (c) seg- mentado (pipeline), descritos anteriormente.

Os simuladores gerados com ArchC permitem medir diretamente grandezas como (i) o n´ umero que ciclos executados, (ii) tempo de execu¸c˜ ao, (iii) n´ umero de instru¸c˜ oes execu- tadas, (iv) n´ umero de chamadas de E/S, e (v) n´ umero de acessos a cada instru¸c˜ ao e ` a mem´ oria [8].

Uma medida fundamental para os projetistas de sistemas embarcados, e que n˜ ao ´ e diretamente produzida pelo ArchC, ´ e a quantidade de mem´ oria necess´ aria para execu- tar determinada aplica¸c˜ ao. Um mecanismo que supre esta falta foi implementado neste trabalho e ´ e descrito na Se¸c˜ ao 4.2.

ArchC permite a constru¸c˜ ao de simuladores Interpretados e Compilados, o que lhe confere uma grande vantagem em rela¸c˜ ao as demais linguagem, que geralmente focam em um dos modelos. Al´ em disso, a ArchC permite uma simula¸c˜ ao detalhada da hierarquia de mem´ oria [57].

Outra caracter´ıstica importante do ArchC ´ e a capacidade dos simuladores gerados emularem chamadas ao sistema operacional. Com isso, aplica¸c˜ oes que efetuam opera¸c˜ oes de entrada/sa´ıda, como leitura e escrita em arquivos, tamb´ em podem ser simuladas. Para utilizar esta funcionalidade, o projetista deve implementar interfaces de acesso ` as fun¸c˜ oes do sistema operacional que consistem basicamente em mapear os parˆ ametros e o valor de retorno das fun¸c˜ oes.

Na vers˜ ao 1.5, ArchC foi extendida para permitir a gera¸c˜ ao autom´ atica de montadores para arquiteturas com instru¸c˜ oes de tamanho fixo [10]. Uma vers˜ ao beta do ArchC 2.0 foi disponibilizada recentemente e inclui diversas melhorias, entre elas, (i) gera¸c˜ ao de mon- tadores/desmontadores para conjuntos de instru¸c˜ oes vari´ aveis, (ii) gera¸c˜ ao de ligadores, (iii) melhoria na cole¸c˜ ao de estat´ısticas e (iv) suporte ao protocolo (Transaction Level Modeling) utilizado para comunica¸c˜ ao.

No Cap´ıtulo 4 s˜ ao detalhados os passos necess´ arios para a implementa¸c˜ ao de um

simulador utilizando a linguagem ArchC.

As ADLs evoluiram consideravelmente nos ´ ultimos anos e o grupo acima representa um pequeno conjunto das diversas linguagens existentes. Outros modelos podem ser encontrados em [56].

Ap´ os o estudo das linguagens de descri¸c˜ ao de arquiteturas foi conclu´ıdo que a melhor op¸c˜ ao para o trabalho proposto ´ e a linguagem ArchC. ArchC mostrou-se a mais completa, abrangendo o espa¸co da simula¸c˜ ao de sistemas embarcados. Outro motivo ´ e a atividade de desenvolvimento, que propicia atualiza¸c˜ ao das ferramentas e inclus˜ ao de novas funcio- nalidades. A facilidade de manipula¸c˜ ao, flexibilidade e boa documenta¸c˜ ao tamb´ em foram itens decisivos na escolha.

Uma das propostas deste trabalho ´ e estender o conjunto de estat´ısticas da linguagem ArchC permitindo a medida do tamanho do conjunto de dados e de programa, determi- nando dinamicamente, e com precis˜ ao, o tamanho da pilha e do heap.

2.6 Trabalhos Relacionados

O trabalho aqui descrito consiste na implementa¸c˜ ao de simuladores para trˆ es arquitetu- ras diferentes com o objetivo de disponilizar m´ etricas de desempenho que auxiliem na etapa da explora¸c˜ ao arquitetural. A seguir s˜ ao descritos os ambientes de desenvolvimento dispon´ıveis para estes processadores

Os microprocessadores Motorola DSP56F827 e Rabbit R2000 n˜ ao possuem ferramen- tas de dom´ınio p´ ublico dispon´ıveis para simula¸c˜ ao. A plataforma CodeWarrior, da Me- trowerks [19] ´ e a ferramenta mais utilizada por desenvolvedores dos microprocessadores da fam´ılia 56800, a qual pertence o DSP56F827. Esta plataforma permite a implementa¸c˜ ao do software, execu¸c˜ ao passo-a-passo e simula¸c˜ ao. ´ E poss´ıvel verificar o n´ umero de ciclos executados e a utiliza¸c˜ ao de mem´ oria. A desvantagem desta ferramenta ´ e o custo, em torno de $2000, que inviabiliza sua aquisi¸c˜ ao apenas para fins de teste da arquitetura.

O microcontrolador R2000 da Rabbit n˜ ao possui ferramenta de simula¸c˜ ao no mercado.

As plataformas de desenvolvimento, WinIDE da Softools [52] e Dynamic C [48] da Rabbit,

s˜ ao aplicativos propriet´ arios e s´ o executam quando conectadas diretamente a um m´ odulo

de hardware.

O microprocessador Atmega8515, possui a ferramenta AVR Studio, da Atmel [7] que

´ e gratuita, por´ em n˜ ao disponibiliza m´ etricas de desempenho. As aplica¸c˜ oes desenvolvidas para o Atmega8515 tamb´ em podem ser compiladas utilizando o Gnu Compiler Collec- tion (GCC) [30]. Em [38] e [3] tamb´ em s˜ ao apresentados um simulador e um ambiente de desenvolvimento Assembly, respectivamente, para o processador Atmega8515. Ambos n˜ ao disponibilizam m´ etricas de desempenho.

Este trabalho contribuir´ a para que os desenvolvedores destes dispositivos utilizem o

simulador para iniciar o desenvolvimento do software antes da conclus˜ ao do hardware, e

com os futuros projetistas, que poder˜ ao utilizar esta ferramenta para decidir qual proces-

sador melhor atende ` as suas necessidades.

CAP´ ITULO 3

DESCRIC ¸ ˜ AO DOS MICROPROCESSADORES

Neste cap´ıtulo s˜ ao descritas as principais caracter´ısticas dos microprocessadores utilizados neste trabalho e de seus ambientes nativos de desenvolvimento.

Os trˆ es microprocessadores possuem diferen¸cas significativas em termos de recursos e de custo, como mostra a Tabela 3.1. O DSP56F827 da Motorola (DSP) ´ e um processador de 16 bits e instru¸c˜ oes de tamanho vari´ avel, enquanto que o Atmel Atmega8515 (AT) ´ e um processador de 8 bits de dados, com instru¸c˜ oes de 16 bits. O Rabbit R2000 (RB)

´ e um processador de 8 bits com instru¸c˜ oes de tamanho vari´ avel. As diferen¸cas entre os microprocessadores contribuem para a verifica¸c˜ ao da qualidade do ambiente, pois atrav´ es dos testes ser´ a poss´ıvel efetuar a medi¸c˜ ao e a compara¸c˜ ao direta da capacidade de pro- cessamento de cada um deles. Compara¸c˜ oes como estas permitir˜ ao aos projetistas decidir com base em dados concretos, e quando poss´ıvel, a decis˜ ao ser´ a baseada na execu¸c˜ ao do c´ odigo da aplica¸c˜ ao para a qual os processadores s˜ ao candidatos. Nas Se¸c˜ oes que se seguem s˜ ao descritos os processadores.

Processador DSP AT RB Freq¨ uˆ encia [MHz] 80 * 16 30 Mem´ oria Flash [KBytes] 128 8 64**

RAM Interna [Bytes] 8192 512 64·10

**

RAM Externa [KBytes] 128 64 1024 Custo [US$] 11,11 4,84 12,75

* A freq¨ uˆ encia do rel´ ogio interno ´ e o dobro da externa.

** A mem´ oria de dados e c´ odigo ´ e compartilhada.

Tabela 3.1: Principais Caracter´ısticas dos Microprocessadores.

3.1 Motorola DSP56F827

Atualmente, diversos sistemas embarcados necessitam processar sinais digitalmente. Um

exemplo cl´ assico ´ e o telefone celular, no qual quase todo o processamento das informa¸c˜ oes

de entrada/sa´ıda da antena ´ e feito no dom´ınio digital para permitir maior repetitibilidade e facilidade de projeto em rela¸c˜ ao ao processamento anal´ ogico. Arquiteturas para proces- samento digital de sinais tornaram-se muito populares na ´ ultima d´ ecada, e impulsionadas pelo mercado de modems e outros equipamentos de comunica¸c˜ ao, chegam ao mercado sob forma de processadores especializados para execu¸c˜ ao de algoritmos espec´ıficos de proces- samento de sinais, com alto desempenho, baixo custo e baixo consumo.

Os algoritmos mais utilizados em DSPs cont´ em, geralmente, diversas opera¸c˜ oes arit- m´ eticas como multiplica¸c˜ oes e somas consecutivas. Filtros digitais, a transformada r´ apida de Fourier (FFT) e a transformada discreta do cosseno (DCT) s˜ ao exemplos de algoritmos que s˜ ao executados em DSPs. Devido ao n´ umero de multiplica¸c˜ oes e somas envolvidos nestes algoritmos, ao inv´ es de se utilizar duas instru¸c˜ oes (multiplica¸c˜ ao seguida de acu- mula¸c˜ ao) e v´ arios registradores, a estrat´ egia utilizada pelos DSPs ´ e o uso da instru¸c˜ ao MAC (multiplica e acumula) que ´ e uma opera¸c˜ ao poderosa dispon´ıvel nestes processado- res.

O microprocessador DSP56F827 ´ e membro da fam´ılia 56800 de Processadores Digitais de Sinais ou Digital Signal Processors da Motorola, da qual s˜ ao membros o DSP56F826, o DSP56F803, dentre outros.

Caracter´ısticas Gerais da Arquitetura.

• Segmentado, at´ e 40 MIPS a 80 MHz de freq¨ uˆ encia. No m´ınimo dois ciclos por instru¸c˜ ao.

• Dissipa¸c˜ ao de potˆ encia de 150 mW a 198 mW.

• 128 Kbytes de mem´ oria Flash de Programa.

• 2 Kbytes mem´ oria RAM de programa.

• 8 Kbytes de mem´ oria Flash de Dados.

• 8 Kbytes de mem´ oria RAM de Dados.

• Possibilidade de expans˜ ao de 128 Kbytes de Mem´ oria RAM para Dados e Programa.

• Dois acumuladores de 36 bits (A e B)

• Trˆ es registradores de ´ındice de 16 bits (X0, Y0 e Y1).

• Quatro registradores de 16 bits (A0, A1, B0 e B1).

• Dois registradores de extens˜ ao de sinal de 4 bits (A2 e B2).

• Quatro temporizadores de prop´ osito geral e um temporizador time-of-day (base de tempo em segundos).

• Trˆ es portas seriais.

• 60 linhas de entrada/sa´ıda.

• Instru¸c˜ oes de tamanho vari´ avel, de 16 a 64 bits.

• Conversores Anal´ ogico-Digital e Digital-Anal´ ogico.

• Interface Join Test Action Group (JTAG) e On-Chip Emulation (OnCE) para pro- grama¸c˜ ao e depura¸c˜ ao de programas.

Os acumuladores A e B podem ser usados em por¸c˜ oes separadas (A0, A1, B0, B1, A2 e B2) e permitem que estes processadores sejam usados tamb´ em para aplica¸c˜ oes comuns.

Arquitetura de Mem´ oria. A arquitetura de mem´ oria da fam´ılia DSP56800 ´ e baseada na arquitetura Harvard [33], com a mem´ oria e os barramentos de c´ odigo e da- dos separados. Endere¸cos separados e barramentos exclusivos para cada espa¸co de en- dere¸camento permitem acessos simultˆ aneos ` a mem´ oria de dados e de programa. Existe um segundo barramento na mem´ oria de dados que ´ e utilizado para mapeamento de dispo- sitivos. Neste caso, podem ser executados duas leituras simultˆ aneas ` a mem´ oria de dados, totalizando trˆ es acessos paralelos ` a mem´ oria.

E poss´ıvel a inclus˜ ´ ao de mem´ oria externa ao n´ ucleo do processador. S˜ ao permitidos 128 Kbytes de expans˜ ao para a mem´ oria de dados e 128 Kbytes para a mem´ oria de programa.

A mem´ oria do DSP56F827 ´ e endere¸cada em palavras de 16 bits.

Satura¸ c˜ ao e Limita¸ c˜ ao de Dados Os algoritmos para DSP muitas vezes ne- cessitam calcular valores maiores que a precis˜ ao do processador. Quando o resultado de uma opera¸c˜ ao ultrapassa o tamanho de um registrador o procedimento padr˜ ao ´ e sinali- zar um overflow. Um exemplo de overflow ocorre na opera¸c˜ ao 0x7fff + 0x5 = 0x8004.

Neste caso o resultado extrapola o limite do registrador e muda de um n´ umero grande positivo (correto) para um n´ umero grande negativo (incorreto).

A ocorrˆ encia de overflow cria problemas em sistemas com processamento de sinais em tempo real. Para contornar este problema o microprocessador DSP56F827 utiliza a t´ ecnica de satura¸ c˜ ao, que converte o valor excedido para o m´ aximo valor de mesmo sinal que ´ e suportado pelo processador.

A satura¸c˜ ao ´ e especialmente importante quando os dados s˜ ao processados por um filtro e a sa´ıda vai para um conversor digital/anal´ ogico (DAC), por exemplo. Neste caso, a sa´ıda ´ e limitada ao inv´ es de gerar um overflow. Sem a satura¸c˜ ao, a sa´ıda pode ser incorretamente alterada de um valor grande positivo para um valor grande negativo e pode causar problemas na sa´ıda de um DAC e conseq¨ uˆ entemente na aplica¸c˜ ao embarcada.

A satura¸c˜ ao na arquitetura DSP56800 ´ e opcional e pode ser aplicada a dois limitadores, o limitador de dados que satura quando o dado ´ e movido para um dos acumuladores, e o limitador de sa´ıda da multiplica¸c˜ ao que satura a sa´ıda das unidades de multiplica¸c˜ ao.

Segmenta¸ c˜ ao. A execu¸c˜ ao das instru¸c˜ oes ´ e segmentada para permitir que a maio- ria das instru¸c˜ oes execute em dois ciclos de rel´ ogio. Por´ em certas instru¸c˜ oes requerem mais ciclos para executar, s˜ ao elas: (i) instru¸c˜ oes com tamanho maior que dois bytes, (ii) instru¸c˜ oes que utilizam modo de endere¸camento que necessitam mais de um ciclo para executar, (iii) instru¸c˜ oes que acessam a mem´ oria de programa; e (iv) instru¸c˜ oes de desvio. No caso de desvio, ´ e necess´ ario um ciclo para drenar o pipeline caso o desvio seja tomado.

A segmenta¸c˜ ao do DSP56F827 consiste em trˆ es est´ agios: (1) Busca, (2) Decodifica¸c˜ ao

e (3) Execu¸c˜ ao. Enquanto uma instru¸c˜ ao ´ e executada, a pr´ oxima instru¸c˜ ao ´ e decodificada

e a seguinte ´ e buscada. Se uma instru¸c˜ ao possui tamanho de quatro bytes, a palavra