Trabalho de Conclusão de Curso Desnes A N do Rosário

•

UNIP

Flavio Loss

28/10/2018

E aí, curtiu este material?

Ajude a incentivar outros estudantes a melhorar o conteúdo

Gostou desse material? Compartilhe! 🧡

Engenharia da Computação

5.614 Materiais compartilhados

Baixe o app para aproveitar ainda mais

Leia os materiais offline, sem usar a internet. Além de vários outros recursos!

Prévia do material em texto

UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE
CENTRO DE TECNOLOGIA
DEPARTAMENTO DE ENGENHARIA DE COMPUTAÇÃO E AUTOMAÇÃO
TRABALHO DE CONCLUSÃO DE CURSO

Desenvolvimento e aplicações de sistemas embarcados em FPGA

Aluno: Desnes Augusto Nunes do Rosário
Orientador: Prof. Dr. Gláucio Bezerra Brandão

Natal/RN, 02 de Julho de 2010

UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE
CENTRO DE TECNOLOGIA
DEPARTAMENTO DE ENGENHARIA DE COMPUTAÇÃO E AUTOMAÇÃO
TRABALHO DE CONCLUSÃO DE CURSO

Desenvolvimento e aplicações de sistemas embarcados em FPGA

Trabalho de Conclusão de Curso
Submetido ao Departamento de
Engenharia de Computação e
Automação do Centro de
Tecnologia da Universidade
Federal do Rio Grande do Norte,
como parte dos requisitos
necessários para obtenção do grau
de Engenheiro de Computação
com habilitação em Automação
Industrial.

Aluno: Desnes Augusto Nunes do Rosário
Orientador: Gláucio Bezerra Brandão

Natal/RN, 02 de Julho de 2010

UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE
CENTRO DE TECNOLOGIA
DEPARTAMENTO DE ENGENHARIA DE COMPUTAÇÃO E AUTOMAÇÃO
TRABALHO DE CONCLUSÃO DE CURSO

Trabalho de conclusão de curso apresentado à banca examinadora composta pelos
seguintes membros:

__________________________________________________________________
Prof. Dr. Gláucio Bezerra Brandão (Orientador)
Professor do Departamento de Engenharia Biomédica – UFRN

__________________________________________________________________
Prof. Dr. Alberto Nicolau
Professor do Departamento de Engenharia Elétrica – UFRN

__________________________________________________________________
Prof. Dr. George Carlos do Nascimento
Professor do Departamento de Engenharia Biomédica – UFRN

AGRADECIMENTOS

Agradeço a Deus, que me carregou nos braços nestes cinco anos de luta e me
permitiu escolher a cidade do Natal para residir e a UFRN para ser realizar este curso.

À minha mãe Luciene S. Nunes, que lutou diariamente nos EUA durante anos,
para me proporcionar a oportunidade de estudar e de me dedicar aos estudos. Mesmo
com toda esta distância, agradeço por todo amor, carinho, apoio, investimento e
compreensão, sem os quais jamais seria possível concluir este curso sem grandes
dificuldades.

Ao meu pai Augusto F. Rosário e minha irmã Lyna K. Rosário, por todo amor e
carinho.

À minha namorada Ana M. B. Barufi, que muito além de proporcionar diversos
momentos felizes ao seu lado, tem me apoiado e dado forças em uma fase difícil, e
auxiliou nas correções ortográficas deste trabalho.

Ao Brasil, que me proporcionou a oportunidade de receber uma educação
superior gratuita e de qualidade. Oportunidade esta que não recebi nos anos em que
morava nos EUA.

À minha universidade que me proporcionou além da educação, a oportunidade
de intercâmbio no período de um ano na McMaster University em Hamilton, ON -
Canadá. O intercâmbio proporcionou o conhecimento necessário para realizar este
trabalho de conclusão de curso, assim como permitiu que eu conhecesse a minha
namorada.

Aos meus professores do DCA, em especial ao Professor Glaúcio, por este ano
de orientação tanto na pesquisa de iniciação científica quanto neste trabalho de
conclusão de curso.

À FAPERN, pelo auxílio financeiro neste último ano que permitiu a minha
dedicação ao projeto que contribuiu para a composição deste trabalho.

À amiga Alyana C. M. de Barros, por ter lutado arduamente em busca de minha
carteira de reservista militar no ano de 2005, enquanto eu estava nos EUA. Sou grato,
pois sem este documento, ela não poderia realizar minha matricula na UFRN nas
últimas horas do último dia de inscrição. Agradecendo aqui, cumpro uma antiga
promessa.

Aos demais familiares, amigos do Brasil e dos EUA, e colegas de curso, por
estarem sempre ao meu lado em todos os momentos, assim como por me
acompanharem nos momentos de trabalho e estudo como também diversão e alegria em
algumas horas vagas.

RESUMO

Este trabalho apresenta o estudo das aplicações e metodologias de
desenvolvimento de sistemas embarcados nas placas de estudo com FPGA’s da
Empresa Altera. Esta companhia adota uma metodologia modular de desenvolvimento
de sistemas embarcados. Tal metodologia foi abordada junto com o detalhamento das
IDE’s e etapas realizadas neste processo, o qual modela a criação de camadas de
hardware formadas por componentes tais como a CPU Nios II, memórias, LED’s e
outros periféricos. A camada de hardware tem o intuito de executar códigos em uma
camada de software em C, também embarcada nestes sistemas. Consequentemente, a
metodologia discutida foi aplicada na criação de um sistema digital dedicado a vídeo na
placa de estudo DE2. Este sistema tem a função de enviar sinais de vídeo à saída VGA
da placa, que são configurados na camada de software. Por fim, o trabalho propõe uma
nova modelagem ao sistema desenvolvido, que integra o sistema digital dedicado a
vídeo com a linguagem de computação gráfica OpenGL. Assim, também se propõe que
o sistema de modelagem gráfica em 3D seja integrado aos dispositivos de E/S (GPIO)
destas placas, com o intuito de realizar aplicações voltadas para as áreas biomédica e
petrolífera.

ABSTRACT

This paper presents the study of applications and development methodologies
applied to the creation of embedded systems in the Development and Education
Boards with FPGA’s from the Altera Corporation. The process of creation of embedded
systems follows a modular development methodology, which makes use of the IDE's
provided by Altera itself. This development methodology, which is discussed in detailed
steps, is intended to model hardware layers formed by components such as CPU Nios
II, Memories, LEDs and other devices as required by the system project design. This
hardware layer has as its purpose the execution of codes in a software layer also
embedded in these systems which make use of the high level C language. Consequently,
this methodology is applied to create a dedicated digital video system on the DE2 Board
from Altera. This system has the functionality of sending video signals to the VGA
output from DE2. These signals are configured in the software layer. Finally, this paper
proposes a new modeling for the system here developed, which integrates the dedicated
digital video system with a known Computer Graphics Language, the OpenGL. Thus, it
is also proposed that this 3D embedded modeling system, complemented by the use of
the GPIO, can be of use in applications related to the biomedical and petroleum field.

SUMÁRIO
SUMÁRIO ................................................................................................................................... I
LISTA DE FIGURAS ............................................................................................................ III
LISTAS DE TABELAS .......................................................................................................... V
LISTA DE SÍMBOLOS E ABREVIATURAS ................................................................ VI
1.0 INTRODUÇÃO............................................................................................................. 1
1.1 Objetivos ..................................................................................................................................2
1.2 Motivação ................................................................................................................................. 3
1.3 Organização do Trabalho ........................................................................................................ 5
2.0 SISTEMAS EMBARCADOS (OU SISTEMAS EMBUTIDOS) ....................... 7
2.1 Sistemas Embarcados nas placas da Altera ............................................................................. 7
2.1.1 Breve histórico das linguagens de descrição de hardware ..................................................... 8
2.1.2 Linguagem de descrição de hardware e seu funcionamento .................................................. 9
2.1.3 A integração e funcionamento de sistemas embarcados nas placas de estudos da Altera 11
2.2 Etapas de desenvolvimento de sistemas embarcados para as FPGA’s da Altera ................ 13
2.2.1 Etapa I: A criação e modelagem dos componentes do sistema e inserção dos mesmos na
IDE SOPC ............................................................................................................................................. 13
2.2.2 Etapa II: Componentes especiais e mais complexos através do programa University
Cores 14
2.2.3 Etapa III: A integração da camada de hardware feita na IDE Quartus II ......................... 17
2.2.3.1 Subetapa I: Modelagem do sistema através dos sinais de entrada, saída e conexões
18
2.2.3.2 Subetapa II: “Pinagem” dos sinais de entrada e saída ................................................ 19
2.2.3.3 Subetapa III: Compilação e descarregamento da camada de hardware na placa .... 21
2.2.4 Etapa IV: A camada de software na IDE Nios II .................................................................. 22
2.2.4.1 Sistemas Embarcados em Assembler/C/C++ para placas da Altera .......................... 23
2.2.4.2 A arquitetura de desenvolvimento, o uso das Bibliotecas Abstração de Hardware
(HAL), tipagem dos tipos de dados na codificação e a biblioteca do sistema embarcado ......... 24
2.2.5 Etapa V: A execução total do sistema através da IDE Altera Debug Program ................. 26
3.0 IMPLEMENTAÇÃO DE UM SISTEMA DIGITAL EMBARCADO
DEDICADO A VÍDEO COM O USO DA CPU NIOS II EM UMA FPGA
CYCLONE II ......................................................................................................................... 28
3.1 Etapas I & II de desenvolvimento: Modelagem com os componentes e inserção dos mesmos
através da IDE SOPC e do patch University Cores. ........................................................................... 28
ii

3.2 Etapa III: integração do hardware feita na IDE Quartus II (Subetapas de Modelagem,
“pinagem” e compilação) ................................................................................................................... 32
3.2.1 A resolução da imagem, a estrutura da informação dos pixels e o frame-buffer de pixels
embarcado ............................................................................................................................................ 36
3.3 Etapa III: A camada de software na IDE Nios II ................................................................... 37
3.3.1 O uso da biblioteca “system.h” no sistema digital dedicado a vídeo .................................. 37
3.3.2 O uso das bibliotecas HAL no sistema digital dedicado a vídeo ......................................... 38
3.3.3 Código demonstrativo do sistema digital dedicado a vídeo embarcado em FPGA ........... 40
3.4 Etapa IV: A execução e demonstração do sistema dedicado a vídeo, alvo deste TCC .......... 43
4.0 APLICAÇÕES PROPOSTAS DO SISTEMA EMBARCADO DEDICADO
A VÍDEO ................................................................................................................................. 45
4.1 A evolução proposta do sistema digital dedicado a vídeo ...................................................... 45
4.1.1 O que é OpenGL? ................................................................................................................... 46
4.1.2 A proposta: OpenGL Embarcado ......................................................................................... 46
4.1.3 Dúvida relativa ao desempenho do OpenGL Embarcado ................................................... 47
4.1.4 Uma solução proposta em caso de fraco desempenho do OpenGL Embarcado................ 48
4.2 Aplicações do OpenGL Embarcado proposto ....................................................................... 49
4.2.1 Aplicação BioFeedArt ............................................................................................................. 49
4.2.2 Aplicação de sistemas embarcados da Altera na criação de sistemas de tempo real
petrolíferos ............................................................................................................................................ 51
4.2.2.1 Contextualização em relação ao petróleo ..................................................................... 52
4.2.2.2 Proposta de desenvolvimento de um Sistema Gráfico Para o Auxilio do Processo de
Perfuração de Poços Direcionais .................................................................................................... 54
5.0 CONCLUSÃO ............................................................................................................ 57
5.1 Considerações finais ............................................................................................................... 57
5.2 Perspectivas futuras ............................................................................................................... 58
REFERENCIAS BIBLIOGRÁFICAS ............................................................................. 59

iii

LISTA DE FIGURAS

FIGURA 1 - ENIAC X LAPTOP COMUM. APENAS 60 ANOS OS SEPARAM. .................................. 1
FIGURA 2 - SISTEMAS EMBARCADOS EM FPGA. NA FIGURA A ESQUERDA TEM-SE UM
ROBÔ-FPGA QUE USA UMA BATERIA CARRO R/C (REMOTE & CONTROL OU
CONTROLE & REMOTO) E UM SERVORMOTOR R/C. NA IMAGEM DA DIREITA TEM-SE
UM BRINQUEDO R/C CONTROLADO POR FPGA COM SENSORES IR DE DISTANCIA.
[HAMBLEN, 2008] ............................................................................................................................. 3
FIGURA 3 - UMA FPGA STRATIX IV .................................................................................................... 4
FIGURA 4 - ESQUEMÁTICA DA PLACA DE2 QUE TEM UMA FPGA CYCLONE II ....................... 5
FIGURA 5 - PLACA DE2 DA ALTERA COM UMA FPGA CYCLONE II ............................................ 5
FIGURA 6 - TECNOLOGIAS DIFERENTES DE PROGRAMAÇÃO E IMPLEMENTAÇÃO DE
SISTEMAS EMBARCADOS. [HAMBLEN, 2008] ........................................................................... 7
FIGURA 7 - LINHA DE DESENVOLVIMENTO BÁSICA PARA A CRIAÇÃO DA CAMADA DE
HARDWARE OU DO PRÓPRIO SISTEMA EMBARCADO EM SI NAS PLACAS DA ALTERA
[HAMBLEN, 2008]. ............................................................................................................................ 8
FIGURA 8 - ESQUEMATIZAÇÃO DE UM SISTEMA EMBARCADO EM UMA FPGA [ALTERA
CORP.: INTRODUCTION TO THE ALTERA NIOS II SOFT PROCESSOR]. ............................. 12
FIGURA 9 - DESENVOLVIMENTO DE SISTEMAS EMBARCADOS USANDO AS IDE’S
(INTEGRADED DEVELOPMENT ENVIRONMENT OU AMBIENTE DE DESENVOLVIMENTO
INTEGRADO) SOPC, QUARTUS E NIOS II [COE4DS4 EMBEDDED SYSTEMS - LAB #2 -
INTRODUCTION TO EMBEDDED SOFTWARE FOR THE NIOS II PROCESSOR]. ................ 13
FIGURA 10 - COMPONENTES DE UM SISTEMA BÁSICO NO SOPC. TEMOS MEMÓRIA, UMA
CPU NIOS II, O PROTOCOLO SERIAL DE ESCRITA NA PLACA E O DISPLAY LCD DA
PLACA DE2. .....................................................................................................................................14
FIGURA 11 - DESENVOLVIMENTO DE SISTEMAS NA IDE QUARTUS II, NO PRIMEIRO
QUADRO ATRAVÉS DA SINTAXE DO VERILOG, NO SEGUNDO ATRAVÉS DE
DIAGRAMA DE BLOCOS E PORTAS LÓGICAS. ....................................................................... 18
FIGURA 12 - MODELAGEM DE UM SISTEMA BÁSICO NO MÓDULO GRÁFICO DE
PROGRAMAÇÃO DO QUARTUS II .............................................................................................. 19
FIGURA 13 - MÓDULO PIN PLANNER, QUE É USADO PARA A “PINAGEM” DOS
COMPONENTES, COMPONDO A INTEGRAÇÃO DA MODELAGEM DO SISTEMA
EMBARCADO ÀS FPGA'S .............................................................................................................. 20
FIGURA 14 - IDE NIOS II, USADA PARA A PROGRAMAÇÃO DA CAMADA DE SOFTWARE DE
SISTEMAS EMBARCADOS EM FPGA'S ...................................................................................... 22
FIGURA 15 - PESQUISA REALIZADA EM 2006, COM RESPEITO DA PREFERÊNCIA DE
LINGUAGEM DE SISTEMAS EMBARCADOS PELA ALTERA. A LINGUAGEM C LIDERA
COM MAIS DE 60% [HAMBLEN, 2008]. ...................................................................................... 23
FIGURA 16 - ARQUITETURA DE COMUNICAÇÃO DA APLICAÇÃO DE USUÁRIO COM OS
PERIFÉRICOS ATRAVÉS DO HARDWARE DE SISTEMA DE PROCESSAMENTO NIOS II
[HAMBLEN, 2008]. .......................................................................................................................... 24
FIGURA 17 - INTERFACE DA IDE ALTERA MONITOR PROGRAM. .............................................. 27
FIGURA 18 - MODELAGEM DO SISTEMA DIGITAL DEDICADO A VÍDEO ................................. 28
FIGURA 19 - MODELAGEM DA CONFIGURAÇÃO DO CONTROLADOR DE VÍDEO VGA.
[ALTERA CORP.: USING SOPC BUILDER & DSP BUILDER TOOL FLOW, 2005] ................. 32
FIGURA 20 - UM TIPO DE CONTROLADOR DE VÍDEO ORIUNDO DO SOPC. [HAMBLEN, 2008]
........................................................................................................................................................... 33
FIGURA 21 - INTEGRAÇÃO DOS SINAIS DO SISTEMA DIGITAL DEDICADO A VÍDEO A SEUS
RESPECTIVOS PINOS DA FPGA. ................................................................................................. 34
iv

FIGURA 22 - “PINAGEM” DA SAÍDA VGA PARA UM DISPOSITIVO DE SAÍDA DE VÍDEO
COMO UM MONITOR OU UM PROJETOR. [HAMBLEN, 2008] ............................................... 36
FIGURA 23 - À ESQUERDA, O MODO DE ENDEREÇAMENTO X-Y, ÚNICO DISPONIBILIZADO
PARA A PLACA DE2 E A RESOLUÇÃO 640 X 480, QUE FOI A ESCOLHIDA PARA ESTE
TRABALHO. [ALTERA CORP.: VIDEO OUT IP CORES FOR ALTERA DE BOARDS, 2009] 37
FIGURA 24 - CONTEÚDO DE UMA VARIÁVEL DE COR. [ALTERA CORP.: VIDEO OUT IP
CORES FOR ALTERA DE BOARDS, 2009] .................................................................................. 37
FIGURA 25 - EXECUÇÃO DO SISTEMA DIGITAL DEDICADO A VÍDEO EMBARCADO NA
PLACA DE2 UTILIZANDO UMA FPGA CYCLONE II. ............................................................... 44
FIGURA 26 - MODELAGEM DO SISTEMA EMBARCADO DEDICADO A OPENGL. .................... 49
FIGURA 27 - UMA FOLHA DE SAMAMBAIA FORMADA POR UM FRACTAL.
MATEMATICAMENTE CONHECIDO POR FETO-FRACTAL. .................................................. 50
FIGURA 28 - MODELAGEM ESQUEMÁTICA DO BIOFEEDART .................................................... 51
FIGURA 29 - REGIÃO DO PRÉ-SAL BRASILEIRO............................................................................. 53
FIGURA 30 - FORMAÇÕES GEOLÓGICAS ANTES DO PRÉ-SAL.................................................... 53
FIGURA 31 - MODELAGEM DE UM POÇO DIRECIONAL ............................................................... 55

LISTAS DE TABELAS

TABELA 1 - UMA TENTATIVA DE ABSTRAÇÃO ENTRE UMA LINGUAGEM DE AUTO NÍVEL
EM SOFTWARE PARA OUTRA DE BAIXO NÍVEL EM HARDWARE ..................................... 10
TABELA 2 - COMPILADOR MODULAR DE HARDWARE DA ALTERA. ....................................... 21
TABELA 3 - TIPAGEM DE DADOS DA ALTERA ............................................................................... 25
TABELA 4 - COMPONENTES E CONTROLADORES UTILIZADOS PARA A IMPLEMENTAÇÃO
DO SISTEMA DIGITAL DEDICADO A VÍDEO. .......................................................................... 29
TABELA 5 - SINAIS DO CONTROLADOR DE VÍDEO E SUAS RESPECTIVAS CONEXÕES AOS
PINOS DA FPGA CYCLONE II ..................................................................................................... 35
TABELA 6 - TABELA DE ALGUMAS CONSTANTES USADAS NO DESENVOLVIMENTO DA
CAMADA DE SOFTWARE NA IDE NIOS II................................................................................. 38
TABELA 7 - CÓDIGO EMBARCADO NO SISTEMA DIGITAL DEDICADO A VÍDEO .................. 40
TABELA 8 - FUNÇÕES USADAS PARA ESCREVER, LER E COPIAR DADOS DE UMA ÁREA DE
PIXELS NO FRAMEBUFFER DE UM PROGRAMA EM OPENGL. ........................................... 47
TABELA 9 - DADOS QUE PODEM SER UTILIZADOS NA MODELAGEM EM 3D DO SISTEMA
EMBARCADO VOLTADO AO AUXÍLIO DE SISTEMAS PETROLIFEROS. ............................ 56

LISTA DE SÍMBOLOS E ABREVIATURAS

GPS � Global Positioning System
ENIAC � Electronic Numeric Integrator And Calculator
LCD � Liquid Cristal Display
LED � Light Emitting Diode
CPU � Central Process Unit
R/C � Remote & Control
FPGA � Field Programmable Gate Array
ASIC’s � Application Specific Integrated Circuit
VHDL � VHSIC Hardware Description Language
VHSIC � Very High Speed Integrated Circuits
DARPA � Defense Advanced Research Projects Agency
IEEE � Institute of Electrical and Electronic Engineering
DoD � Department of Defense
AIDS � Automated Integrated Design Systems
GDA � Gateway Design Automation
CDS � Cadence Design Systems
OVI � Open Verilog Internacional
DE2 � Development and Education Board 2
SOPC � System On a Programmable Chip
JTAG_UART � Join Test Action Group - Interface UART
IDE � Integrated Development Environment
SD � Secure Digital
UART � Universal Asynchronous Receiver/Transmitter
DDR � Double Data Rate
RAM � Random Access Memory
SDRAM � Synchronous Dynamic Random Access Memory
TCP/IP � Transmission Control Protocol / Internet Protocol
HAL � Hardware Abstraction Layer
SRAM � Static Random Access Memory
VGA � Video Graphics Array
RGB � Red-Green-Blue
vii

USB � Universal Serial Bus
FIFO � First-In-First-Out
GPIO � General Purpose I/O
DMA � Direct Memory Access
OpenGL � Open Graphics Library
FAPERN � Fundação de Apoio e Pesquisa do Estado do Rio Grande do
Norte
EEG � Electroencephalogram
ECG � Electrocardiogram
EMG � Electromyography
MWD � Measuring While Drilling
LWD � Logging While Drilling

1.0 Introdução

Nas últimas décadas, o mundo tem passado por uma revolução digital que torna a
sociedade cada vez mais dependente de tecnologia para trabalhar, pesquisar, obter
entretenimento ou simplesmente viver, através de aparelhos diversos como
computadores, celulares, sistemas de GPS (Global Positioning System, ou Sistema
Global de Posicionamento), marca-passos, dentre muitos outros. Este processo está
associado à intensa necessidade de desenvolvimento, qualidade e portabilidade. Cada
vez mais, o consumidor de tecnologia deseja aparelhos que sejam melhores, mais
portáteis e mais diversificados.
Pode-se entender este sentimento ao considerar extremos da evolução dos
computadores, desde o século passado até os dias de hoje.No fim da Segunda Guerra
Mundial, o mundo foi apresentado ao seu primeiro computador, o ENIAC (Eletronic
Numeric Integrator And Calculator, ou Calculadora Integrativa Numérica Eletrônica),
que pesava aproximadamente 30 toneladas e totalizava 180 ��de área construída, ou
seja, ocupava praticamente a área de uma sala completa. Nem o mais otimista dos
cientistas que desenvolveram aquele projeto revolucionário para a época poderia
imaginar que, aproximadamente 60 anos depois desta grande descoberta tecnológica,
pessoas comuns poderiam levar seus computadores portáteis ao trabalho ou escola.
Mais do que isso, não se pensava que os computadores chegariam a pesar menos do que
cinco quilogramas em média, nem que viriam a ser quase que infinitamente mais
poderosos que o antigo ENIAC em capacidade de processamento.
A Figura 1 busca sintetizar esta diferença. Muito já se evoluiu até a atualidade, e a
tendência é de que os engenheiros do Século XXI busquem soluções para problemas
que sequer foram formulados ainda, e assim contribuam de forma produtiva para esta
grande revolução tecnológica.

Figura 1 - ENIAC x Laptop Comum. Apenas 60 anos os separam.
2

Por trás da referida revolução computacional, há um exército de desenvolvedores de
novas tecnologias, que visam atender os novos requisitos e necessidades de produção,
comércio e lazer. Atualmente, não vemos com nenhuma estranheza uma simples padaria
ou mercado utilizar um programa de computador para contabilizar suas finanças, o que
seria inimaginável há mais de dez anos.
Tendo em vista o que foi mencionado acima, este trabalho objetiva agregar novos
conhecimentos à área de sistemas embarcados. O expressivo crescimento do comércio
destes sistemas e dispositivos atualmente é mais do que evidente, com aparelhos que
são geralmente portáteis e têm um ou mais fins específicos para comodidade, lazer e/ou
execução de uma determinada função. Por exemplo, um aparelho celular atual possui
conexão com a internet, transmite sinal de rádio, reproduz mp3, lê GPS, dentre outras
funções. Já o aparelho original, quando foi projetado, possuía somente a função de ligar
para outro telefone através de uma comunicação sem fio. A linha de pesquisa que
permeia este trabalho pode ser muito rentável por estar relacionada com o constante
desenvolvimento voltado ao comércio de videogames, celulares, computadores, entre
outros inúmeros dispositivos.
A importância do tema torna interessante promover avanços para desenvolver a área
de sistemas embarcados. O presente trabalho descreve e discute as atividades realizadas
para se embarcar um sistema digital de vídeo em FPGA, além de apresentar uma
sugestão de evolução deste dispositivo e enunciar duas possíveis aplicações a este
segundo sistema proposto.

1.1 Objetivos

O objetivo do trabalho é projetar e relatar o desenvolvimento de um sistema
embarcado e de quaisquer controladores que sejam necessários para a obtenção de um
bom desempenho de vídeo ao executar programas gráficos em C. A razão da escolha
desta linguagem de alto nível para o tratamento de vídeo será discutida mais adiante
neste trabalho.
Para tal sistema a precisão, exatidão, harmonia, parametrização e temporização dos
componentes e controladores são essenciais, de forma a garantir uma boa comunicação
entre os diversos componentes e periféricos utilizados. Dentre estes, podem ser
destacados: memórias (do programa e a de buffer de vídeo), barramentos, processador,
vídeo; e outros diversos periféricos como LCD (Liquid Cristal Display ou Diplay de
3

Cristal Líquido), chaves e LED’s (Light Emitting Diodes ou Diodos Emissores de Luz)
utilizados como auxiliares ao desenvolvimento.

1.2 Motivação

Uma companhia muito atuante no mercado de sistemas embarcados é a Altera. Seus
produtos são especiais devido ao fato da empresa oferecer diversos sistemas que não
precisam ser ajustados fisicamente, e sim virtualmente através do hardware que é
descrito através de linguagens de descrição especiais, que geram um grande poder de
reconfigurabilidade.
Além disso, esta companhia desenvolve diversas placas de estudo já preparadas para
uma integração que possa proporcionar generalidade para qualquer que seja a
necessidade de seus desenvolvedores. Programando os sistemas em linguagem de
hardware, podem-se integrar componentes como CPU’s (Central Process Unit ou
Unidade de Processamento Central), controladores de memórias, controladores de vídeo
e quaisquer outros periféricos, usando como vantagem o fato de que todos os pontos
importantes das placas já estão previamente conectados e descritos. Estas placas podem
ser utilizadas para diversos projetos; na Figura 2 temos dois exemplos de sistemas
embarcados nas placas da Altera:

Figura 2 - Sistemas embarcados em FPGA. Na figura a esquerda tem-se um robô-FPGA que usa
uma bateria carro R/C (Remote & Control ou Controle & Remoto) e um servormotor R/C. Na
imagem da direita tem-se um brinquedo R/C controlado por FPGA com sensores IR de distancia.
[Hamblen, 2008]

Empresas mundo afora têm percebido o poder oferecido pelas placas da Altera nesta
linha de desenvolvimento, devido à possibilidade de criar nas placas sistemas críticos,
sistemas de tempo real, servidores web, processadores de vídeo, dentre outros sistemas
4

embarcados. No passado, as placas relacionadas a estas funções tinham de ser
modeladas, desenhadas, diagramadas esquematicamente, fabricadas e soldadas desde o
botão de início até o LED de saída, proporcionando uma gama maior de possíveis
elementos nos quais poderiam existir falhas que gerariam danos ao funcionamento
destes sistemas.
Com tais placas especiais de estudo, é possível descarregar o código gerado nas
linguagens de descrição de hardware nas FPGA's (Field Programmable Gate Array, ou
Matriz de Portas Programáveis). As FPGA’s são constituídas por milhares de
transistores e fazem basicamente o que vários circuitos integrados fariam, com a
diferença de que sua matriz é reprogramável como já mencionado anteriormente. Na
Figura 3 temos a foto de uma FPGA da linha Stratix:

Figura 3 - Uma FPGA Stratix IV
Este trabalho foi desenvolvido na placa de estudos DE2 (Development and
Education Board ou Placa de Desenvolvimento e Estudo 2) da Altera que tem uma
FPGA Cyclone II, modelada e exibida nas Figuras 4 e 5.
5

Figura 4 - Esquemática da placa DE2 que tem uma FPGA Cyclone II

Figura 5 - Placa DE2 da Altera com uma FPGA Cyclone II

1.3 Organização do Trabalho

Este trabalho é composto por cinco capítulos, que podem ser resumidos como segue.
O presente capítulo traz uma introdução sobre o papel de sistemas embarcados na
atualidade. Além disso, também são apresentados alguns conceitos de sistemas
embarcados, e de integração de sistemas embarcados nas placas de estudo da companhia
Altera.
6

O Capítulo 2 apresenta uma visão mais profunda sobre sistemas embarcados. Os
tópicos abordados referem-se à contextualização histórica de desenvolvimento para as
placas da Altera, às distinções de linguagens de hardware para as de alto nível, além da
metodologia que deve ser abordada para a criação de qualquer sistema embarcado. Tal
metodologia utiliza as diversas ferramentas disponibilizadas pela Altera para um
desenvolvimento rápido, coeso e preciso.
O Capítulo 3 exibe uma aplicação de todos os passos da metodologia abordada no
capitulo anterior para a criação de um sistema digital embarcado dedicado a vídeo.
O Capítulo 4 discute uma perspectiva futura para uma integração de alto nível no
sistema digital dedicado a vídeo implementado no capítulo anterior. Esta integração tem
como enfoque uma grande melhoria do sistema implementado, visando o retorno
econômico e apontando exemplosde aplicações que poderiam ser realizadas com o
sistema proposto.
O Capítulo 5 apresenta as conclusões obtidas sobre o desenvolvimento de sistemas
embarcados, em especial para o sistema criado neste trabalho. Além disso, são
apontadas as perspectivas futuras da integração de alto-nível do sistema aqui
desenvolvido.

2.0 Sistemas Embarcados (ou Sistemas Embutidos)

Um sistema embarcado é um sistema em que toda a unidade de processamento é
dedicada para a realização de uma devida função, geralmente restrita por computação de
tempo real. Ao contrário dos computadores de propósito geral, os quais trabalham com
diversos periféricos e processos, os sistemas embarcados se especializam em funções
para as quais se necessita um processamento melhor e dedicado a uma única função.
Em geral os sistemas embarcados são usados quando o desempenho aprimorado é
uma necessidade, ou quando um processo exige exclusividade. Os sistemas de lógica
digital embarcados podem ser implementados através de diferentes tecnologias, tais
como lógica padrão, lógica programável, ASIC’s (Application Specific Integrated
Circuit ou Circuito Integrado de Aplicação Específica), ou de personalização completa.
A Figura 6 subdivide as tecnologias de desenvolvimento, e no caso deste trabalho, foi
utilizada a lógica programável, por meio da tecnologia de FPGA’s da Altera.

Figura 6 - Tecnologias diferentes de programação e implementação de sistemas embarcados.
[Hamblen, 2008]

2.1 Sistemas Embarcados nas placas da Altera

As placas da Altera trabalham prioritariamente com as linguagens VHDL (VHSIC
Very High Speed Integrated Circuits Hardware Description Language ou Linguagem
de Descrição de Hardware de Circuitos Integrados de Velocidade Muito Alta) e o
Verilog HDL. Para trabalhar em tais placas deve ser utilizada uma dessas duas
linguagens de descrição de hardware para programar e executar os devidos códigos de
configuração de hardware. De posse destas linguagens e algumas ferramentas da Altera,
8

é possível criar sistemas embarcados ou ainda criar a camada de hardware para sistemas
mais complexos. Na Figura 7 é apresentado um diagrama de passos básicos para criar e
trabalhar com sistemas embarcados nas placas de estudo da Altera:

Figura 7 - Linha de desenvolvimento básica para a criação da camada de hardware ou do próprio
sistema embarcado em si nas placas da Altera [Hamblen, 2008].

2.1.1 Breve histórico das linguagens de descrição de hardware

Existem duas principais linguagens de descrição de hardware: o VHDL e o Verilog
HDL. O VHDL foi originalmente desenvolvido sob o comando do DARPA (Defense
Advanced Research Projects Agency, ou Agência de Pesquisa Avançada de Defesa dos
Estados Unidos) para substituir os complexos manuais de diagramas esquemáticos dos
ASICS (Application Specific Integrated Circuit, ou Circuito Integrado de Aplicação
Especifica). Em 1987, o IEEE (Institute of Electrical and Electronic Engineering, ou
Instituto Elétrico e Eletrônico de Engenharia) padronizou o VHDL. Esta linguagem não
é sensitiva à caixa alta (case sensitive), e tem uma sintaxe baseada na primitiva
linguagem Ada. Esta última foi desenvolvida pelo DoD (Department of Defense, ou
Departamento de Defesa) dos Estados Unidos em 1970, com o objetivo de padronizar a
programação e substituir as centenas de linguagens de programação de hardware usadas
na época. A denominação Ada tem origem em Ada Lovelace, que é conhecida como a
primeira programadora da história da computação.
9

Já a outra linguagem de descrição de hardware aqui estudada, o Verilog HDL, é
também disponibilizada pela Altera para modelar sistemas eletrônicos, foi criada por
Phil Moorby e Prabhu Goel durante o inverno de 1983/1984 como AIDS (Automated
Integrated Design Systems, ou Sistema de Design de Integração Automatizada). Esta
sigla, por estar relacionada à outra definição posteriormente utilizada no vocabulário
médico foi alterada para GDA (Gateway Design Automation, ou Automação de Design
de Portas) em 1985. Esta linguagem foi adquirida pela companhia CDS (Cadence
Design Systems, ou Sistemas de Design Cadence) em 1990. Devido ao crescente
sucesso do VHDL, a Cadence observou a necessidade da disseminação do
conhecimento da linguagem, e assim colocou o Verilog HDL em domínio público
através do projeto OVI (Open Verilog Internacional, ou Verilog Aberto Internacional)
também conhecido como projeto Accellera. Desta forma, com as correções
oficializadas, em 2001 o IEEE padronizou o uso do Verilog HDL como outra de
linguagem oficial de descrição de hardware.
A linguagem escolhida para este trabalho foi a segunda aqui discutida, o Verilog
HDL.

2.1.2 Linguagem de descrição de hardware e seu funcionamento

Estas linguagens de descrição de hardware diferem muito das linguagens de alto
nível tais como C/C++, Java, entre outras pelo fato das primeiras executarem sua lógica
não somente de acordo com o fluxo do algoritmo, mas também seguindo a
temporização de um ou mais clocks de processamento durante a execução.
As variáveis dos algoritmos de baixo nível são tratadas de maneira completamente
distinta das variáveis nas linguagens de alto nível. Isso porque no primeiro caso estamos
modelando virtualmente circuitos, o que implica que ao invés de fazermos acesso a um
endereço na memória em uma pilha de execução, estamos fazendo acesso a um bloco de
registradores e/ou fios elétricos virtuais. Neste nível de hardware, a temporização de
atribuição, o tempo de processamento, o bloqueio de acesso e o barramento formam
novos tipos de parâmetros e restrições a serem considerados, os quais geralmente não
significam empecilhos nas linguagens de alto nível.
Na Tabela 1 , para se distinguir uma linguagem de baixo nível de hardware de uma
de alto nível de software, tenta-se sem sucesso abstrair um programa em Verilog HDL
para C. No Verilog HDL, apresentado na coluna à direita, a cada subida do sinal do
10

reset ou do clock, executamos o bloco always, o que se busca fazer por meio do bloco if
à esquerda da Tabela (em C). Entretanto, o tempo de acesso a uma variável em software
é “infinitamente” maior do que em hardware, e se este sinal for rápido demais para o
software reconhecer, o bloco C possivelmente jamais será executado. É menos provável
que isto aconteça no caso do código em hardware descrito em Verilog HDL na segunda
coluna.
Outra diferença extremamente pertinente é o operador “<=” do Verilog HDL, que é
conhecido como non-blocking (ou não-bloqueador), o que significa que esta ação só
será executada no próximo ciclo de clock. Isto implica na indiferença de ordem de
atribuição, como é feito nas linguagens de alto nível, ou seja, tanto faz, por exemplo,
que o trecho “flop1 <= 0” venha antes ou depois do trecho “flop2 <= 1”, pois ambos
serão executados simultaneamente no próximo ciclo de clock ou do reset. Tal ação é
impossível de ser abstraída nas linguagens de alto nível como C/C++, Java, C#, etc.,
devido à forma de compilação e execução sequencial destas linguagens. As linguagens
de hardware como o VHDL ou o Verilog HDL, podem configurar a não ou
simultaneidade das instruções em seu código.

Tabela 1 - Uma tentativa de abstração entre uma linguagem de auto nível em software para outra
de baixo nível em hardware
C Verilog
void toplevel (int clock, int reset)
{
int flop1;
int flop2;

if ( (reset==1) || (clock==1) )
{
if (reset==1)
{
flop1=0;
flop2=1;
}
else
{
module toplevel(clock,reset);

input clock;
input reset;

reg flop1;
reg flop2;

always @ (posedge reset or posedge
clock)
if (reset)
begin
flop1 <= 0;flop2 <= 1;
11

flop1=flop2;
flop2=flop1;
}
}
}

end
else
begin
flop1 <= flop2;
flop2 <= flop1;
end
endmodule

Entretanto, mesmo com estes diversos empecilhos de programação e temporização,
temos uma forma poderosa de criar e reconfigurar componentes e periféricos
eletrônicos, em função dos circuitos que já estão previamente conectados às placas de
estudo da Altera. Com isso, torna-se possível unir desempenho e praticidade relacionada
ao desenvolvimento e integração do sistema embarcado ou da camada de hardware em
si.

2.1.3 A integração e funcionamento de sistemas embarcados nas placas
de estudos da Altera

No contexto dos sistemas embarcados nas placas da Altera, percebe-se o forte grau
de integração destas placas quando se estuda os manuais das FPGA’s, onde é fácil
observar que todos os periféricos importantes estão fisicamente conectados às FPGA’s.
Logo, para realizar qualquer tarefa e ter o desempenho desejado, precisa-se criar o
código orientado à estrutura de desenvolvimento, para obter o desempenho requerido
pelos periféricos. Isto é, criar os componentes e/ou drivers necessários para que se
realize a comunicação entre os sinais de software e hardware de uma tarefa desejada no
sistema embarcado modelado.
Na Figura 8, tem-se uma modelagem abstrata desta linha de desenvolvimento. Ela
mostra que os controladores, barramentos, sistemas de Debug e o processador Nios II
estão carregados dentro do chip FPGA, o qual se comunica com o computador e os
chips de memórias, periféricos de E/S e/ou outros externamente, através das ligações
físicas dos periféricos e da interface de comunicação com o computador (USB-Blaster
(Universal Serial Bus ou Barramento Universal Serial) no caso).

Figura 8 - Esquematização de um sistema embarcado em uma FPGA [Altera Corp.: Introduction
to the Altera Nios II Soft Processor].

Como se pode observar, todos os periféricos tais como as memórias (exceto a
“Memória No Chip”, que é uma pequena memória interna construída na FPGA), portas
paralelas e seriais, vídeo e áudio, entre outros, necessitam de seus respectivos
controladores embarcados na FPGA. Estes controladores são programados nas
linguagens de hardware e descarregados nas FPGA’s através de uma interface USB
(USB-Blaster no caso de algumas placas para Windows) conectada ao um computador.
Esta interface também é controlador interno na FPGA, que no caso corresponde a
interface JTAG-UART (Join Test Action Group ou Grupo de Testes de Ações
Unificadas - UART Universal Asynchronous Receiver/Transmitter, ou
Receptor/Transmissor Universal Assíncrono). A comunicação para a escrita e/ou leitura
de dados nas placas, ocorre através destas interfaces USB-BLASTER e JTAG-UART
através de uma estrutura cliente-servidor parecida com a convencional de serviço web.
13

Desta forma, é possível descarregar os códigos de hardware, verificar dados durante
uma execução e enviar comandos, o que implica em efetuar o desejado controle dos
dispositivos e periféricos no sistema embarcado modelado.

2.2 Etapas de desenvolvimento de sistemas embarcados para as FPGA’s da
Altera

O desenvolvimento de sistemas embarcados da Altera da forma que foi realizado
neste trabalho é um processo complexo e modular. O funcionamento desta linha de
desenvolvimento modular está ilustrado na Figura 9. Nesta seção serão descritas todas
as etapas necessárias para o desenvolvimento de qualquer sistema embarcado para as
placas da Altera seguindo esta linha de desenvolvimento modular e utilizando suas
ferramentas de desenvolvimento: SOPC (System On a Programmable Chip ou Sistema
Em um Chip Programável), University Cores, Quartus II, Nios II e Altera Debug
Program.

Figura 9 - Desenvolvimento de sistemas embarcados usando as IDE’s (Integraded Development
Environment ou Ambiente de Desenvolvimento Integrado) SOPC, Quartus e Nios II [COE4DS4
Embedded Systems - Lab #2 - Introduction to Embedded Software for the NIOS II Processor].

2.2.1 Etapa I: A criação e modelagem dos componentes do sistema e
inserção dos mesmos na IDE SOPC

Sistemas embarcados em geral são compostos por componentes como CPU,
memória, LED’s e outros periféricos, conhecidos pelo seu uso bastante comum. A
Altera, visando a praticidade, disponibiliza alguns dos componentes comumente
14

utilizados para este desenvolvimento, no intuito de automatizar o processo de
implementação em suas FPGA’s.
O uso destes componentes mais comuns é possível por meio da IDE do SOPC, que
está conectada à IDE Quartus II. A interface do SOPC pode ser visualizada na Figura
10.

Figura 10 - Componentes de um sistema básico no SOPC. Temos memória, uma CPU Nios II, o
protocolo serial de escrita na placa e o display LCD da Placa DE2.

Nesta IDE, podem-se selecionar os mais diversos componentes básicos necessários
para o desenvolvimento de qualquer sistema embarcado nas placas da Altera. No
sistema básico da imagem acima, por exemplo, foram escolhidos apenas os quatro
componentes descritos a seguir:
� Memória No Chip (32 Kbytes).
� CPU Nios II (tipo f).
� JTAG_UART (tem a utilidade de escrita na placa através da interface no
computador utilizado para o desenvolvimento).
� Controlador de LCD de Caracteres (16 colunas x 2 linhas).

2.2.2 Etapa II: Componentes especiais e mais complexos através do
programa University Cores
15

Visando um desenvolvimento educacional mais prático e efetivo, a companhia
Altera disponibilizou alguns componentes mais específicos e complexos do que os mais
usuais encontrados no SOPC, por meio do programa University Cores. Do mesmo
modo que os do SOPC, estes componentes já têm seu hardware definido pela Altera,
sendo necessário apenas realizar as devidas conexões necessárias para configurar o
sistema.
As University Cores são acessadas como um patch na IDE SOPC, isto é, os
componentes especiais são integrados e configurados no seu sistema através da IDE
SOPC.
Na lista abaixo, temos exemplos de componentes especiais disponibilizados apenas
pelo programa University Cores:

� VGA Output Especial (controladores de vídeo).
� Áudio Output Especial (controlador de som).
� Entradas para clocks externos
� Controlador de LCD de Caracteres especial (16 colunas x 2 linhas).
� Controlador de Ethernet.
� Controlador Debounce dos Pushbuttons.
� Controlador de USB.
� Controlador de cartão SD (Secure Digital ou Seguro digital).
� Protocolos UART especiais (IrDA (Infrared Data Association ou Associação de
Dados Infravermelhos) UART e RS232 UART)
� Controladores de memória SDRAM e memória FLASH (Transformam o chip
SDRAM da DE2, por exemplo, em uma memória DDR (Double Data Rate ou
Dupla Taxa de Dados) ou DDR2).
� Pontes de memórias especiais (Bridges).
� Controladores de entradas PS2.
� Diversos outros.

Embora alguns destes componentes já estejam “prontos” para o uso, muitos outros
necessitam de componentes auxiliares para seu funcionamento. Por exemplo, os
componentes de memórias especiais sempre necessitam de controladores de
barramentos em pontes, para fazer acesso aos bancos de memórias (um caso é o do chip
16

de memória SDRAM (Synchronous Dynamic Random Access Memory ou Memória de
Acesso Aleatório e Dinâmico), que tem quatro bancos). Já os controladores das
memórias, tais como os das DDR, necessitam de períodos de clock distintos e defasados
do período de clock da CPU para poder realizar o acesso de escrita e/ou leitura na
subida desse clock, e o fim de tais atividades nas descidas de clock. Uma adversidade
adicional que pode ser mencionada é o fato da saída de vídeo necessitar de outro clockmais lento que o da CPU para sincronizar os sinais de vídeo corretamente. Todos os
dados referentes a estes controladores e seus componentes auxiliares podem ser
encontrados nos manuais disponibilizados no site da Altera.
A etapa de modelagem, estipulação e parametrização dos componentes de um
sistema vem a ser uma das áreas mais importantes e possivelmente uma das mais
trabalhosas deste tipo de desenvolvimento, pois qualquer parâmetro errado pode até não
influenciar na geração do sistema, mas certamente será descoberto na hora de carregar o
sistema de hardware na FPGA. Por exemplo, a quantidade máxima da Memória No
Chip quando se utiliza uma CPU Nios II do tipo mais simples, é de 38 Kbytes
(normalmente, os sistemas usam 32 Kbytes), embora o SOPC tenha o poder de estipular
a capacidade de 128 Kbytes para esta memória. Este erro de modelagem passará
despercebido até a etapa anterior à escrita (etapa de fitter, quando o compilador do
Quartus monta a simulação do circuito que será carregado na FPGA) do sistema na
FPGA, o que pode acarretar em uma grande perda de tempo e esforço.
Vários destes componentes foram criados para o simples uso dos periféricos, dentre
os quais as pontes e os controladores de memória, que simplesmente buscam mais
espaço de memória de execução dos processos que a simples Memória No Chip. Na
placa DE2, a memória Flash tem 4MB e a SDRAM tem 8MB, enquanto que a Memória
No Chip tem apenas 32 KB, como mencionado anteriormente. Embora mais simples de
usar, ela é muito restrita e um algoritmo pode facilmente estourar a pilha de execução de
uma tarefa com algumas chamadas a uma função recursiva, por exemplo.
Entretanto, outros componentes foram especificamente implementados para a
realização da comunicação simples ou melhorada entre os programas na camada de
software, executados na CPU Nios II, e os mais diversos controladores de periféricos de
hardware integrados no sistema. Um simples exemplo seria que através do controlador
de LCD de caractere é possível enviar uma string pelo barramento do sistema
embarcado e escrever frases de tamanho de 16 caracteres no painel de LCD, disponível
em algumas placas de estudo da Altera. Outro exemplo mais complexo pode ser a
17

leitura de vários pacotes TCP/IP (Transfer Control Protocol ou Protocolo de Controle
de Transporte / Internet Protocol ou Protocolo de Internet) que chegam ao controlador
da porta Ethernet da placa de estudo, com o intuito de construir uma mensagem através
do desencapsulamento dos pacotes TCP/IP enviados ao servidor embarcado na placa.
Toda a temporização de acesso e envio pelo barramento de informações já estão
previamente implementados pelos componentes controladores de LCD e Ethernet. A
comunicação dos programas na camada de software com os periféricos especiais na
camada de hardware é realizada por chamadas de sistema, disponíveis através das
bibliotecas que a Altera denominou HAL (Hardware Abstraction Layer, ou Camada de
Abstração de Hardware), que são bibliotecas em C que têm o poder de controlar o
hardware embarcado nestas placas de estudo. Tais bibliotecas serão abordadas mais
especificamente em uma seção posterior do texto.
A versão do programa University Cores usada neste trabalho foi a versão 9.0.

2.2.3 Etapa III: A integração da camada de hardware feita na IDE
Quartus II

Seguindo a linha de desenvolvimento modular, nos sistemas desenvolvidos para
placas da Altera o hardware pode ser descrito em forma de texto como citado
anteriormente, ou de forma gráfica através de portas lógicas na IDE Quartus II
proveniente da Altera exibida na Figura 11:

Figura 11 - Desenvolvimento de sistemas na IDE Quartus II, no primeiro quadro através da
sintaxe do Verilog, no segundo através de diagrama de blocos e portas lógicas.

Nos sistemas digitais criados através dos componentes do SOPC e University Cores,
a parte principal da camada de hardware vira uma caixa preta com os componentes
provenientes das etapas anteriores, sem qualquer sinal de entrada e saída e quaisquer
conexões necessárias. Em função disso, a etapa de integração é dividida em três
Subetapas descritas a seguir.

2.2.3.1 Subetapa I: Modelagem do sistema através dos sinais de
entrada, saída e conexões

A primeira Subetapa da integração do hardware é a definição dos sinais de
entrada e saída do sistema através da IDE Quartus II. Isto pode ser feito utilizando o
código na linguagem de hardware escolhida no SOPC. Contudo, este método torna-se
muito mais prático e dinâmico ao ser realizado no editor de diagrama de blocos que está
incorporado à IDE Quartus II. Nesta Subetapa, podemos usar as caixas pretas criadas no
SOPC, como é apresentado na demonstração da modelagem de um sistema embarcado
básico na Figura 12.

Figura 12 - Modelagem de um sistema básico no módulo gráfico de programação do Quartus II

Como o SOPC criou o sistema de componentes, é necessário definir todos os
sinais de entrada e saída necessários para conectá-lo posteriormente a todos os pontos
de uso da FPGA. Esta ação implica em realizar as devidas conexões para que o sistema
se comunique com a placa de estudo corretamente. No exemplo da Figura 12 acima,
temos diversos sinais de entrada e saída sendo conectados. Na entrada temos os sinais
de clock, reset e o de switch já conectados. Por outro lado, na saída da caixa preta está o
sinal dos LED’s vermelhos já conectados e os sinais necessários para controlar o LCD
de caracteres necessários prestes a serem conectados.

2.2.3.2 Subetapa II: “Pinagem” dos sinais de entrada e saída

Após a etapa de modelagem do sistema através da criação dos sinais de entrada e
saída, a próxima etapa é a conexão dos sinais do sistema aos pontos reais da FPGA, ou
seja, a devida integração da modelagem do sistema à placa.
Como já mencionado anteriormente, nas placas de estudo da Altera todos os
periféricos estão fisicamente ligados à FPGA por meio das respectivas placas de estudo.
Desta forma, devem-se ligar os sinais de entrada e saída criados na Subetapa I aos pinos
da FPGA. A Altera disponibiliza para todas as suas placas de estudo um arquivo em
Excel, que traz a identificação de todos os pinos que possam ter alguma utilidade aos
sistemas que venham a ser criados para suas FPGA’s.
Por exemplo, na Figura 13 modela-se um sinal de clock como entrada do
hardware, o qual deve ser ligado ao pino PIN_50 da FPGA. Este, por sua vez, é
conectado a um cristal que emite clock em onda quadrada de 50 MHz que está
20

incorporado à placa DE2. Também por conveniência pode-se conectar o sinal de reset
modelado na Figura 5 ao PIN_G26 da FPGA, que está conectado ao primeiro botão no
canto inferior direito da placa DE2, mostrado anteriormente nas Figuras 4 e 5, para que
quando este botão for acionado, o sistema seja reiniciado.
A etapa de “pinagem” é uma etapa realizada pelo módulo do Quartus chamado
de Pin-Planner (ou Planejador de Pinos), que é apresentado na Figura 13. Esta Subetapa
pode vir a ser muito exaustiva se for preciso realizar a “pinagem” de cada pino
individualmente. Todavia, uma estratégia de automatização é a modelagem dos pinos na
Subetapa II, com os mesmos nomes dados pela Altera a eles no seu arquivo de pinos,
realizando a importação deste último. Mesmo que seja mais atrativo nomear os pinos de
acordo com a funcionalidade que os mesmos terão no sistema embarcado, isto custará
muito mais tempo de nomeação dos pinos nessa Subetapa.

Figura 13 - Módulo Pin Planner, que é usado para a “pinagem” dos componentes, compondo a
integração da modelagem do sistema embarcado às FPGA's

Neste ponto do desenvolvimento, a camada de hardware do sistema está pronta
para ser compilada. Se esta fase for realizada com sucesso, pode-seenfim descarregar a
camada de hardware na placa. A Subetapa III apresentará estes passos.

2.2.3.3 Subetapa III: Compilação e descarregamento da camada
de hardware na placa

Apesar das diferenças expressivas da forma de programação das linguagens de
hardware e de software, elas possuem uma semelhança: a compilação. Embora sejamos
induzidos a acreditar que o hardware deveria ser interpretado e não compilado, os
sistemas criados devem passar por um compilador modular dedicado, feito pela Altera,
que está incorporado à IDE Quartus II.
Na Tabela 2 , estão descritos os módulos do compilador de hardware. Os que
porventura estiverem marcados por um asterisco representam etapas de compilação
opcionais, que somente serão executadas de acordo com as configurações de sistema
para complementar, verificar ou otimizar o processo de compilação.

Tabela 2 - Compilador modular de hardware da Altera.
Componente Função
Analise e Síntese Analisa os arquivos de design e cria a base de dados do
projeto de acordo com o design descrito no projeto.
Analise de tempo Analisa a desempenho de toda a lógica de seu design e
ajuda a guiar o Fitter para cumprir com os requerimentos
de seu design.
Fitter (ou “encaixador”) Usa a base de dados criada no modulo de compilação
anterior para ligar a lógica com os requisitos de
temporização do projeto de acordo com a disponibilidade
de recursos no dispositivo.
Assembler Cria os arquivos programáveis que serão posteriormente
utilizados pelo Programador Quartus II, para configurar o
dispositivo.
Assistente de Design* Permite a verificação da confiança de seu design, baseado
em várias regras de desenvolvimento.
EDA Netlist Writer* Permite a execução de simulações funcionais de
temporização do design.
Compiler Database
Interface*
Assistência à especificação das restrições de compilação
do sistema.
22

2.2.4 Etapa IV: A camada de software na IDE Nios II

A IDE Nios II é o ambiente de programação das linguagens de alto nível, que será
executado nos sistemas de hardware embarcados nas FPGA’s da Altera, provenientes
das etapas anteriores. Nesta IDE, pode-se programar de uma forma mais prática e nítida
para alcançar o objetivo inicial, que é a integração total de software com hardware em
um sistema embarcado. Ou seja, é possível aproveitar a viabilidade e facilidade de
programar em software ao mesmo tempo em que se utiliza a velocidade do hardware,
realizando quaisquer adaptações que sejam necessárias.
O projeto da IDE Nios II da Altera é um patch a uma conhecida IDE, o projeto
Eclipse proveniente da Java Sun. Isto se deve à parceria entre a Altera e a Java Sun,
uma união de uma das melhores companhias de sistemas embarcados do mundo com
uma das IDE’s de melhor aceitação mundial de programação do mercado. Desta forma,
quem já trabalhou com a IDE Eclipse, verá a enorme semelhança entre o Nios II e o
Eclipse. A interface da IDE Nios II está exibida na Figura 14.

Figura 14 - IDE Nios II, usada para a programação da camada de software de sistemas
embarcados em FPGA's

Na etapa I, a IDE SOPC criou um arquivo muito especial para a etapa aqui
apresentada, que é o arquivo que faz a descrição de todos os componentes e
controladores do sistema. Este arquivo tem um nome requerido pela IDE SOPC (que
23

deve ser diferente daquele do projeto da camada de hardware no Quartus II) na criação
da primeira etapa, e tem uma extensão “.ptf”.

2.2.4.1 Sistemas Embarcados em Assembler/C/C++ para placas
da Altera

Neste ponto, tem-se um hardware descarregado na placa, esperando a camada de
software ser escrita. Esta camada de software pode ser implementada em Assembler, C
ou C++. Este processo de implementação da camada de software se torna mais
agradável devido ao poder de realizar o acesso aos periféricos graças a descrição dos
sinais do hardware feita pela compilação da CPU Nios II munida das bibliotecas HAL e
a biblioteca “system.h” (será abordada mais adiante no texto), que podem ser usadas
neste ponto para exercer conexões de alto nível com os dispositivos e periféricos
embarcados em baixo nível assim que se fizer necessário.
Seguindo a tendência de mercado atual, a linguagem escolhida para esta tarefa foi o
C. Mesmo depois de tantos anos em um mercado repleto de linguagens inovadoras com
novos recursos e facilidades, o C ainda é a linguagem mais leve, consistente e soberana.
Com isso, se apresenta como a mais usada linguagem por desenvolvedores de sistemas
embarcados no mundo. Na Figura 15 está o resultado de um levantamento apontado no
Hamblen (2008), – referência em prototipagem rápida de sistemas embarcados para
placas da Altera – relativa à preferência de linguagem para programação de camadas de
software para os desenvolvedores no mundo.

Figura 15 - Pesquisa realizada em 2006, com respeito da preferência de linguagem de sistemas
embarcados pela Altera. A linguagem C lidera com mais de 60% [Hamblen, 2008].
24

2.2.4.2 A arquitetura de desenvolvimento, o uso das Bibliotecas
Abstração de Hardware (HAL), tipagem dos tipos de
dados na codificação e a biblioteca do sistema embarcado

Nesta etapa de desenvolvimento, a aplicação do usuário usa a biblioteca padrão
em C, munida das bibliotecas HAL, para assim exercer uma comunicação com os
periféricos do sistema projetado da maneira desejada e coesa.
No mesmo nível da biblioteca padrão C, faz-se o estudo dos kernels embarcados,
que no caso dos sistemas embarcados da Altera podem ser representados pelo ��/
�� –
e o ����
��. Estes kernels integram o módulo de API Micro C/OS-II que são
kernels portáteis, escalares, preêmptivos, de tempo real e de multitarefas. A finalidade
de um kernel em um sistema embarcado consiste em serviços como semáforos,
semáforos de exclusão mútua, alarmes, caixa de mensagens (mailbox), filas, gerência de
tarefas, gerência de blocos de memória de tamanho fixo e gerência de temporização do
sistema.
A Figura 16 exibe este tipo de projeto de arquitetura de funcionamento dos
sistemas embarcados da Altera.

Figura 16 - Arquitetura de comunicação da aplicação de usuário com os periféricos através do
hardware de sistema de processamento Nios II [Hamblen, 2008].
25

As bibliotecas HAL são bibliotecas em C, disponibilizadas pela Altera e
codificadas nesta linguagem, que servem para executar chamadas de funções na camada
de software em componentes embarcados na camada de hardware. A seção 3.3.2 mais
adiante no texto, explica em detalhes um exemplo de uso de uma biblioteca HAL. Para
o uso correto destas bibliotecas, o projetista deve pesquisar e obedecer as instruções
encontradas nos manuais também disponibilizados pela Altera através de seu site.
Outra informação muito pertinente para o desenvolvimento é que a Altera,
também por convenção, usa um cast (ou tipagem) de dados para programação de seus
sistemas. Estas redefinições de variáveis são encontradas na biblioteca “alt_types.h” que
deve ser importada na aplicação de usuário. O desenvolvedor está livre para usar a
tipagem de dados da linguagem C para a programação; entretanto, por convenção, os
programas e funções desenvolvidos pela Altera seguem a tipagem de dados descrita na
Tabela 3 a seguir:

Tabela 3 - Tipagem de dados da Altera
typedef signed char
typedef unsigned char
typedef signed short
typedef unsigned short
typedef signed long
typedef unsigned long
typedef long long
typedef unsigned long long
alt_8;
alt_u8;
alt_16;
alt_u16;
alt_32;
alt_u32;
alt_64;
alt_u64;

Neste ponto, a IDE Nios II se diferencia da IDE Eclipse abordada anteriormente
devido ao fato de quena hora de se criar um projeto na primeira, ela exigirá o arquivo
“.ptf” criado pela IDE SOPC. Sob um ponto de vista mais aprofundado, este arquivo
descreverá para a CPU Nios II como acessar os endereços-bases (endereços de memória
de acesso direto tais como o endereço inicial e final de uma memória SRAM (Static
Random Access Memory ou Memória de Acesso Estático e Aleatório), por exemplo), e
todas as outras diretrizes dos componentes e periféricos, assim como criar a biblioteca
de descrição do hardware em auto nível, para ser usada nesta camada de software; esta
biblioteca é denominada “system.h”. As outras diretrizes de sistema estão relacionadas
26

com a definição de constantes importantes ao sistema, que no caso de um sistema digital
dedicado a vídeo seriam, por exemplo, a altura e largura de uma imagem na saída VGA.
.
2.2.5 Etapa V: A execução total do sistema através da IDE Altera
Debug Program

Por fim, após todas as etapas de modelagem e integração anteriormente descritas,
pode-se enfim executar por completo o sistema embarcado formado por uma camada de
hardware e de software. A execução em modo de desenvolvimento é feita pelo
Programa Altera Debug, que será introduzido nesta seção. Embora exista a
possibilidade de executar o programa através da IDE Nios II, é mais prático e
interessante fazê-lo através desta outra IDE, devido ao fato de que ela apresenta vários
detalhes referentes à execução. Nesta IDE pode-se ver o “Assembler” da Altera, que é a
própria linguagem de maquina utilizada para execução de tarefas pelas placas, assim
como ver as posições na memória e seus respectivos conteúdos. Como outra grande
finalidade, é possível colocar breakpoints na execução com o objetivo de encontrar
erros, através do método de Debug incorporado nas opões da CPU’s Nios II escolhidas
no SOPC ainda na primeira etapa de desenvolvimento.
Na criação de uma tarefa de execução nesta IDE, também precisa-se do arquivo
“.ptf” usado pela IDE Nios II da Etapa anterior. No fim da compilação da camada de
software também da etapa anterior, a IDE Nios II gerá um arquivo “.elf” (Executable
Linking File, ou Arquivo de Lincagem Executável) que é o arquivo executável da
camada de software, que será executado pela camada de hardware embarcada na FPGA.
A interface do altera Debug Program é apresentada na Figura 17.

Figura 17 - Interface da IDE Altera Monitor Program.

3.0 Implementação de um sistema digital embarcado dedicado a vídeo com o uso da
CPU Nios II em uma FPGA Cyclone II

3.1 Etapas I & II de desenvolvimento: Modelagem com os componentes e
inserção dos mesmos através da IDE SOPC e do patch University Cores.

A arquitetura do sistema que será desenvolvido neste trabalho está ilustrada na
Figura 18.

Figura 18 - Modelagem do Sistema Digital Dedicado a vídeo

No sistema realizado, foi necessário utilizar dois componentes especiais do
patch University Cores: o componente especial VGA, que lida com o conteúdo do RGB
pixels e o posicionamento dos pixels na tela, e também foi usado o componente Pixel
Buffer, que usa a memória SDRAM da placa DE2 para tratar o delay e envio de cada
pixel da saída VGA ao monitor.
29

Opcionalmente, foram colocados switches para chamadas de funções, LED’s
para a verificação destes switches, LCD de caracteres para a escrita de strings referentes
à aplicação dos programas, e um medidor de performance de trechos de software.
Todos os componentes e controladores utilizados no sistema digital dedicado a
vídeo integrado neste trabalho estão descritos na Tabela 4 :

Tabela 4 - Componentes e controladores utilizados para a implementação do sistema digital
dedicado a vídeo.
Componente Descrição Função
CPU Nios II – tipo f Processador de 32 bits
de arquitetura RISC,
com cache de
instrução e cache de
dados e uma ULA que
faz multiplicação e
divisão em hardware.
� Executar os processos da
camada de software através das
pilhas de execução com o uso
de 4 Kbytes de memória cache.
� Executar a comunicação com
outros componentes que
gerenciam E/S e controle de
barramento.
JTAG_UART Componente de
comunicação entre a
Interface USB do
computador e o
processador Nios II.
Configurado com uma
FIFO (First In First
Out ou Primeiro a
Entrar é o Primeiro a
Sair) com 64 bytes de
tamanho.
� Comunicação de dados entre
interface USB no computador
(através da FIFO modelada
como cliente-servidor) e a placa
DE2. Este componente é
utilizado para a escrita do
hardware na placa e para a
leitura de dados durante a
execução de uma tarefa no
sistema embarcado.
Memória No Chip Memória do tipo
RAM (Random
Access Memory ou
Memória de Acesso
Aleatório), com
� Usada para armazenar o
processo, pilha de execução e
outros dados relevantes para a
execução do processo. Dispensa
controlador devido a ser criada
30

largura de dados de 32
bits e tamanho total de
32 Kbytes.
na FPGA e controlada pela
CPU Nios II.
Controlador
SDRAM
Controlador de
Memória do tipo
SDRAM de 8 MBytes
com largura de dados
de 16 bits de 1 chip
select e 4 bancos de
dados.
� Controlar o chip de memória
que é utilizado como buffer
para os pixels que são enviados
à saída VGA da placa DE2.
Clocks Controlador de clocks � Controla e gera os sinais de
clock que precisam ser em
frequências diferentes das da
CPU Nios II. Neste caso
utilizou-se este componente
para gerar os seguintes clocks
de memória:
� 50 MHz defazado em -3ns -
SDRAM
� 25 MHz - Core de vídeo VGA
� 25 MHz defazado em 180º -
VGA-DAC
Controlador VGA Controlador da saída
de vídeo VGA
� Controla e coordena os sinais
que serão enviados à saída de
vídeo VGA da placa DE2.
Define o tipo de saída de vídeo
da placa, e qual tipo de saída
será usado. Além da saída
VGA, existe a possibilidade de
enviar sinais para as GPIO
(General Purpose I/O ou E/S de
propósito geral) da DE2, que
pode ser usada para conectar
31

painéis de touch-screens ou
câmeras.
Pixel Buffer Controlador do Buffer
de Pixels da saída
VGA
� Buffer de Pixels para saída
VGA criado na memória
SDRAM, onde se escolhe o
formato de endereçamento na
tela (X-Y ou consecutivo) e a
quantidade de bits na
informação RGB. Mais detalhes
sobre a forma de
endereçamento e conteúdo dos
pixels serão dados na próxima
seção do texto.
PIO – Parallel I/O Saída dos LED’s
vermelhos
� Saída de dados paralela que será
utilizada para enviar dados aos
LED’s vermelhos através da
técnica de mapeamento de
dispositivos de E/S com acesso
direto a memória.
PIO – Parallel I/O Entrada dos switchs � Entrada de dados paralela que
será utilizada para leitura de
dados dos switchs através da
técnica de mapeamento de
dispositivos de E/S com acesso
direto a memória.
Contador de
Desempenho
(Performance
Counter)
Controlador de
performance de 32 e
64 bits
� Contador de ciclos de clocks
realizados pela CPU Nios II.
Utilizado como acessório ao
sistema para medir o
desempenho de trechos de
código. Possibilita a medição de
até sete trechos diferentes de
código, através de contadores
32

de 64 bits (variáveis alt_u64).

3.2 Etapa III: integração do hardware feita na IDE Quartus II (Subetapas de
Modelagem, “pinagem” e compilação)

No caso do sistema digital dedicado a vídeo aqui realizado, dentre os vários
controladores de periféricos utilizados, será descrito com maior detalhe apenas o
controlador de vídeo, o mais importante do sistema embarcado proposto para este
trabalho.
O componente controlador de vídeo foi configurado para exibir imagens com
resolução de 640 x 480 pixelscom dimensões de 16 bits (ilustrado na Figura 19). O
controlador VGA guarda a imagem a ser exibida através da SDRAM externa. O
componente prove duas interfaces Avalon: uma é um controlador DMA (Direct
Memory Access ou de Memória de Acesso Direto), que transfere a imagem linha por
linha da fonte de memória, e a segunda é uma interface que escreve e acessa o banco de
registradores para configurar o controlador DMA e a temporização do circuito VGA.
Esta configuração do componente VGA está ilustrada na Figura 19.

Figura 19 - Modelagem da configuração do controlador de vídeo VGA.
[Altera Corp.: Using SOPC Builder & DSP Builder Tool Flow, 2005]

Após a parametrização e a configuração do componente de vídeo na IDE SOPC,
o mesmo se torna nesta etapa uma entidade gráfica como uma caixa preta, sem nenhuma
33

conexão de qualquer sinal. Um exemplo deste tipo de entidade gráfica está apresentado
na Figura 20.

Figura 20 - Um tipo de controlador de vídeo oriundo do SOPC. [Hamblen, 2008]

Desta forma, são importados quaisquer outros componentes oriundos da IDE
SOPC para o módulo gráfico de desenvolvimento do Quartus II, e assim se são criados
e conectados todos os sinais necessários para a modelagem das conexões que integrarão
o sistema. A modelagem completa do sistema digital dedicado a vídeo, meta deste
trabalho, pode ser encontrada na Figura 21.
34

Figura 21 - Integração dos sinais do sistema digital dedicado a vídeo a seus respectivos pinos da
FPGA.
35

A “pinagem” do hardware deve ser feita de maneira interligada aos sinais de
entrada e saída que foram criados na modelagem gráfica anterior (Figura 21 acima). É
importante que estes sinais sejam conectados corretamente aos pinos da FPGA, os quais
têm a numeração disponibilizada pelos manuais de pinos da devida FPGA da Altera,
como mencionado anteriormente.
Ou seja, para que o controlador de vídeo funcione corretamente, é necessário
que os sinais sejam conectados aos devidos pinos da FPGA Cyclone II. Os pinos de
interesse neste caso têm sua nomenclatura apresentada na Tabela 5 , que será
esquematizada e preenchida no modulo Pin-Planner da IDE Quartus II.

Tabela 5 - Sinais do controlador de vídeo e suas respectivas conexões aos pinos da FPGA Cyclone
II
Sinal Pino
FPGA
Sinal Pino
FPGA
Sinal Pino
FPGA
VGA_R[0] PIN_C8 VGA_G[0] PIN_B9 VGA_B[0] PIN_J13
VGA_R[1] PIN_F10 VGA_G[1] PIN_A9 VGA_B[1] PIN_J14
VGA_R[2] PIN_G10 VGA_G[2] PIN_C10 VGA_B[2] PIN_F12
VGA_R[3] PIN_D9 VGA_G[3] PIN_D10 VGA_B[3] PIN_G12
VGA_R[4] PIN_C9 VGA_G[4] PIN_B10 VGA_B[4] PIN_J10
VGA_R[5] PIN_A8 VGA_G[5] PIN_A10 VGA_B[5] PIN_J11
VGA_R[6] PIN_H11 VGA_G[6] PIN_G11 VGA_B[6] PIN_C11
VGA_R[7] PIN_H12 VGA_G[7] PIN_D11 VGA_B[7] PIN_B11
VGA_R[8] PIN_F11 VGA_G[8] PIN_E12 VGA_B[8] PIN_C12
VGA_R[9] PIN_E10 VGA_G[9] PIN_D12 VGA_B[9] PIN_B12

Sinal Pino
FPGA

VGA_CLK PIN_B8
VGA_BLANK PIN_D6
VGA_HS PIN_A7
VGA_VS PIN_D8
VGA_SYNC PIN_B7

A “pinagem” da FPGA já leva em consideração o modelo de leitura e escrita dos
diversos periféricos que foram implementados pela descrição de hardware do
componente, obtida por meio do SOPC ou desenvolvida pelo próprio projetista do
sistema.
O controlador de vídeo embarcado proveniente do SOPC/University Cores é
responsável por ler/escrever toda essa informação digital processada na CPU Nios II,
também embutida na FPGA. Os comandos de controle são provenientes do código
escrito na camada de software, para que desta forma sejam realizadas quaisquer
conversões, discretizações e filtros necessários para obter a comunicação desta camada
com a camada de hardware, e, portanto, com o periférico envolvido em questão. No
caso da saída VGA, os sinais de saída estão disponibilizados na Figura 22.

Figura 22 - “Pinagem” da saída VGA para um dispositivo de saída de vídeo como um monitor ou
um projetor. [Hamblen, 2008]

3.2.1 A resolução da imagem, a estrutura da informação dos pixels e o
frame-buffer de pixels embarcado

A configuração do controlador de vídeo na IDE SOPC foi onde a configuração
do modo de endereçamento e a resolução da imagem do sistema digital dedicado a
vídeo foram estipulados. O modo de endereçamento de um pixel na tela ocorre em um
eixo de abscissas e ordenadas X-Y que cresce para a direita e para baixo. O tamanho
desses eixos de abscissas e ordenadas delimita a resolução da imagem a ser exibida na
tela. Na Figura 23, são ilustradas estas duas informações.

Figura 23 - À esquerda, o modo de endereçamento X-Y, único disponibilizado para a placa DE2 e a
resolução 640 x 480, que foi a escolhida para este trabalho. [Altera Corp.: Video Out IP Cores for
Altera DE Boards, 2009]

A cor de cada pixel que é escolhida em software pode ser imposta como uma
variável de 32 bits, com uma variável unsigned int em C; entretanto, para sistemas da
Altera, utiliza-se o tipo “alt_u32”. A cor será formada pela codificação binária do
conteúdo da variável “alt_u32” de cor. Esta codificação está ilustrada na Figura 24.

Figura 24 - Conteúdo de uma variável de cor. [Altera Corp.: Video Out IP Cores for Altera DE
Boards, 2009]

3.3 Etapa III: A camada de software na IDE Nios II

3.3.1 O uso da biblioteca “system.h” no sistema digital dedicado a
vídeo

Como explanado na metodologia abordada no capítulo anterior, a compilação na
IDE Nios gera, por meio do arquivo “.ptf”, a “system.h”, que é crucial para o
desenvolvimento da camada de software. Na Tabela 6 são encontradas algumas
constantes utilizadas na implementação do código do projeto:

Tabela 6 - Tabela de algumas constantes usadas no desenvolvimento da camada de software na
IDE Nios II.
Contante Definição na “system.h”
Endereço de memória
dos LED’s vermelhos
#define RED_LEDS_BASE 0x00811090
Endereço de memória
dos botões de switch
#define SWITCH_BASE 0x008110a0
Endereço de memória
do contador de
performance
#define PERFORMANCE_COUNTER_0_BASE
0x00811000
String que nomeia o
buffer de pixels
#define PIXEL_BUFFER_NAME “/dev/pixel_buffer”

3.3.2 O uso das bibliotecas HAL no sistema digital dedicado a vídeo
Para o uso das funções HAL para o sistema digital dedicado a vídeo, deve-se incluir
a seguinte linha no código:

#include “altera_up_avalon_pixel_buffer.h”

Esta biblioteca HAL permite o uso das seguintes funções no código de auto nível:

� int alt_up_pixel_buffer_draw (alt_up_pixel_buffer_dev *pixel_buffer, unsigned
int color, unsigned int x, unsigned int y)
o Função que desenha um pixel de acordo com a codificação binária da
variável color nas coordenadas (x,y) da tela.

� alt_up_pixel_buffer_dev* alt_up_pixel_buffer_open_dev (const char *name)
o Função que abre e retorna um ponteiro à estrutura
alt_up_pixel_buffer_dev. Esta estrutura indexada por tal ponteiro
armazena todos os dados referentes ao buffer de pixels do sistema que
são prioritariamente utilizado nas várias chamadas de funções HAL para
a saída de vídeo. Retorna NULL se houver falha ao abrir o dispositivo de
vídeo.

� int alt_up_pixel_buffer_change_back_buffer_address (alt_up_pixel_buffer_dev
*pixel_buffer, unsigned int new_address)
o Função que muda o endereço inicial do back_buffer para o new_address.
Retorna 0 se a mudança foi realizada com sucesso.

� int alt_up_pixel_buffer_swap_buffers (alt_up_pixel_buffer_dev *pixel_buffer)
o Função que troca o buffer que está sendo enviado para o controlador
VGA. Retorna 0 se a mudança foi realizada com sucesso.

� int alt_up_pixel_buffer_check_swap_buffers_status (alt_up_pixel_buffer_dev
*pixel_buffer)
o Função que