Desenvolvimento de Sistemas Embarcados Co-Design - DCA - UFRN

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
Aluno: Desnes Augusto Nunes do Rosário
Orientador: Gláucio Bezerra Brandão
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.
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.
carinho.
Ao meu pai Augusto F. Rosário e minha irmã Lyna K. Rosário, por todo amor e
À 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
i

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
ii

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
iii

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
iv

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
v

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
vi

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
vii

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

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
2

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
3

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

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

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 exemplos de 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.
6

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,
7

é 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.
8

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.
HDL.
A linguagem escolhida para este trabalho foi a segunda aqui discutida, o Verilog
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
9

eset 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 “

}
}
}
flop1=flop2;
flop2=flop1;
end
else
begin
flop1

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

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
13

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
14

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
15

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 clock
mais 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
16

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:
17

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

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á
19

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-se enfim descarregar a
camada de hardware na placa. A Subetapa III apresentará estes passos.
20

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.
Componente Função
Tabela 2 - Compilador modular de hardware da Altera.
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
Compiler Database
Interface*
temporização do design.
Assistência à especificação das restrições de compilação
do sistema.
21

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
22

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].
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
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].
24

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 que na 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
25

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

Figura 17 - Interface da IDE Altera Monitor Program.
27

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
Figura 18.
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 - 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.
28

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.
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.
Memória No Chip Memória do tipo
RAM (Random
Access Memory ou
Memória de Acesso
Aleatório), com
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.
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.
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
29

Controlador
SDRAM
largura de dados de 32
bits e tamanho total de
32 Kbytes.
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.
na FPGA e controlada pela
CPU Nios II.
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
Controlador VGA Controlador da saída
de vídeo VGA
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
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
30

Pixel Buffer Controlador do Buffer
de Pixels da saída
VGA
PIO – Parallel I/O Saída dos LED’s
vermelhos
painéis de touch-screens ou
câmeras.
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.
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
Contador de
Desempenho
(Performance
Counter)
Controlador de
performance de 32 e
64 bits
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 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
31

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 pixels com 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
32

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

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

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
35

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.
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]
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:
37

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
Endereço de memória
dos botões de switch
Endereço de memória
do contador de
performance
String que nomeia o
buffer de pixels
#define RED_LEDS_BASE 0x00811090
#define SWITCH_BASE 0x008110a0
#define PERFORMANCE_COUNTER_0_BASE
0x00811000
#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.
38

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 verifica se o controlador de vídeo ainda está efetuando a
troca do buffer de pixels. Retorna 0 se já tiver completado e 1 caso
contrário.
void alt_up_pixel_buffer_clear_screen (alt_up_pixel_buffer_dev *pixel_buffer,
int backbuffer)
o Função que limpa a tela do monitor. Retorna 0 se já tiver completado e 1
caso contrário.
void alt_up_pixel_buffer_draw_box (alt_up_pixel_buffer_dev *pixel_buffer, int
x0, int y0, int x1, int y1, int color, int backbuffer)
o Função que desenha uma caixa da dada cor, no dado buffer, entre os
pontos (x0,y0) e (x1,y1). Se a opção do backbuffer for 1, a caixa será
desenhada no backbuffer, caso a opção seja 0, a caixa será desenhada na
tela corrente. Retorna 0 se já tiver completado e 1 caso contrário.
void alt_up_pixel_buffer_draw_hline (alt_up_pixel_buffer_dev *pixel_buffer,
int x0, int x1, int y, int color, int backbuffer)
o Função que desenha uma linha horizontal da dada cor entre os pontos
(x0, y) e (x1,y). Se a opção do backbuffer for 1, a linha será desenhada
no backbuffer, caso a opção seja 0, a caixa será desenhada na tela
corrente. Retorna 0 se já tiver completado e 1 caso contrário.
39

void alt_up_pixel_buffer_draw_vline (alt_up_pixel_buffer_dev *pixel_buffer,
int x, int y0, int y1, int color, int backbuffer)
o Função que desenha uma linha vertical da dada cor entre os pontos (x,
y0) e (x,y1). Se a opção do backbuffer for 1, a linha será desenhada no
backbuffer, caso a opção seja 0, a caixa será desenhada na tela corrente.
Retorna 0 se já tiver completado e 1 caso contrário.
void alt_up_pixel_buffer_draw_rectangle (alt_up_pixel_buffer_dev
*pixel_buffer, int x0, int y0, int x1,int y1, int color, int backbuffer)
o Função que desenha um retângulo da cor determinada, no buffer
especificado, entre os pontos (x0,y0) e (x1,y1). Se a opção do backbuffer
for 1, o retângulo será desenhado no backbuffer; caso a opção seja 0, o
retângulo será desenhada na tela corrente. Retorna 0 se já tiver
completado e 1 caso contrário.
void alt_up_pixel_buffer_draw_line (alt_up_pixel_buffer_dev *pixel_buffer, int
x0, int y0, int x1, int y1, int color, int backbuffer)
o Função que desenha uma linha da cor determinada entre os pontos (x0,
y0) e (x0,y1). Se a opção do backbuffer for 1, a linha será desenhada no
backbuffer; caso a opção seja 0, a caixa será desenhada na tela corrente.
Retorna 0 se já tiver completado e 1 caso contrário.
3.3.3 Código demonstrativo do sistema digital dedicado a vídeo
#include “system.h”
#include “alt_types.h”
#include “sys/alt_stdio.h”
#include “time.h”
#include “io.h”
embarcado em FPGA
Tabela 7 - Código embarcado no sistema digital dedicado a vídeo
40

#include “altera_up_avalon_pixel_buffer.h”
#include “altera_avalon_performance_counter.h”
void *performance_name = PERFORMANCE_COUNTER_0_BASE;
int main(void)
{
/*Estrutura do buffer de pixels*/
alt_up_pixel_buffer_dev *pixel_buf_dev;
/*Função para a inicialização do contador de performance embarcado*/
PERF_RESET(PERFORMANCE_COUNTER_0_BASE);
/*Inicialização do buffer de pixel embarcado*/
pixel_buf_dev=alt_up_pixel_buffer_open_dev(PIXEL_BUFFER_NAME);
/*Verificação da abertura com sucesso do buffer de pixel*/
if (pixel_buf_dev==NULL)
else
{
alt_printf("Erro: Falha ao abrir o pixel buffer!\nAbortando Sistema!");
alt_printf("Pixel buffer aberto com sucesso!\n");
/*Variáveis de controle de chamada de função*/
alt_u16 sentinela0, sentinela1;
sentinela0=sentinela1=0;
/*Variável do switch embarcado; utilizado para chamar de funções*/
alt_u32 var_switch;
/*Variável que conta a quantidades de ciclo de clocks da CPU Nios II*/
41

egister unsigned long n_clocks;
/*Limpeza de tela*/
alt_up_pixel_buffer_clear_screen(pixel_buf_dev);
while(1) /*Loop Eterno do Sistema*/
{
alt_u32*/
/* Ler os valores da SWITCH_BASE, e converte-los para o tipo
var_switch = IORD(SWITCH_BASE, 0);
/* Escreve os valores da var_switch para o barramento dos LED’s
vermelhos; usado para observação se os switchs estão em nível lógico alto*/
IOWR(RED_LEDS_BASE, 0, var_switch);
/*Neste trecho do código, se pinta dois quadrados na tela e se mede
quantos ciclos de clocks cada trecho requisitou da CPU. Esta escolha é dada
pelas chamadas de função de acordo com o valor lido pelo switch da placa DE2*/
switch(var_switch)
{
case 0:
160, 160, 63488, 0);
if(sentinela0==0)
{
PERF_START_MEASURING(performance_name);
PERF_BEGIN(performance_name, 1);
alt_up_pixel_buffer_draw_box(pixel_buf_dev, 20, 20,
PERF_END(performance_name,1);
PERF_STOP_MEASURING(performance_name);
printf(“O trecho 1 do código levou %ld ciclos de clock
para ser desenhada\n, perf_get_section_time(performance,1) );
sentinela0=0;
42

}
case 1:
150, 150, 100, 0);
break;
if(sentinela1==0)
{
PERF_START_MEASURING(performance_name);
PERF_BEGIN(performance_name, 2);
alt_up_pixel_buffer_draw_box(pixel_buf_dev, 30, 30,
PERF_END(performance_name,2);
PERF_STOP_MEASURING(performance_name);
printf(“O trecho 2 do código levou %ld ciclos de clock
para ser desenhada\n, perf_get_section_time(performance,2) );
}
default:
break;
break;
}//fim do switch
}//fim do while
}//fim do else
}//fim do int main
sentinela1=0;
3.4 Etapa IV: A execução e demonstração do sistema dedicado a vídeo, alvo
deste TCC
A aplicação de toda esta metodologia modular descrita para a integração do sistema
digital dedicado a vídeo teve sucesso, e é apresentada na Figura 25.
43

Figura 25 - Execução do sistema digital dedicado a vídeo embarcado na placa DE2 utilizando uma
FPGA Cyclone II.
44

4.0 Aplicações propostas do sistema embarcado dedicado a vídeo
Para este trabalho, a meta de implementação do sistema embarcado dedicado a
vídeo foi alcançada, como apresentado no capítulo anterior. Também foram descritos
todos os passos necessários e realizados para desenvolver qualquer sistema embarcado
nas placas da Altera através do uso das IDE’s Nios II e SOPC no terceiro capítulo.
Entretanto, mesmo com o êxito desta implementação, também há o interesse em
desenvolver uma possibilidade de evolução de integração do mesmo projeto. Desta
forma, este capítulo apresenta uma proposta para a transformação deste sistema
embarcado, desenvolvido puramente para fins estudantis, em um sistema mais
complexo, robusto e audacioso que detenha maior valor econômico e maior
possibilidade de incorporação no mercado comercial atual de sistemas embarcados.
4.1 A evolução proposta do sistema digital dedicado a vídeo
Atualmente existem vários sistemas que modelam objetos, ações e meios das
mais diversas formas gráficas possíveis. Por exemplo, videogames que modelam o mais
complexo dos movimentos dos cabelos de um personagem quando o mesmo pula de
uma colina para um helicóptero em 3D. Também existem aparelhos de celular que
funcionam com o uso de aparelhos auxiliares como os acelerômetros para modelar o
movimento de uma bolinha de pong em um jogo. Todos estes, e outros inúmeros
exemplos, funcionam como sistemas que, através de uma entrada, seja o sinal do
acelerômetro ou o de um botão no controle do jogador, reagem e proporcionam uma
saída ao vídeo do usuário.
Propõe-se nesta seção uma embarcação de uma linguagem de computação
gráfica no sistema produzido neste trabalho. Durante a implementação deste projeto, foi
feita uma reflexão que permitiu perceber que as estruturas do controlador e do
dispositivo de vídeo VGA da Altera favorecem tal proposta. A maioria das linguagens
de computação gráfica atuais, funcionam através do mesmo princípio de composição de
cores e do uso de frame-buffers, depth-buffers e/ou double-buffers, que armazenam
informações referentes aos pixels a serem exibidos na tela pela saída de vídeo. Essa
estrutura é semelhante às discutidas na seção 3.2.1, que explicou o uso do frame-buffer
e a codificação dos pixels do sistema digital dedicado a vídeo implementado neste
trabalho.
45

Devido ao fato da linguagem C ter sido escolhida para o sistema, pelas razões
explanadas na seção 2.2.4.1, optou-se pela linguagem de computação gráfica OpenGL
(Open Graphics Library ou Biblioteca Gráfica Aberta) para esta proposta. Esta
linguagem de computação gráfica open source se constitui na mais atuante e abrangente
em modelagem gráfica no presente momento, utilizada em videogames, modelagem
arquitetônica 3D e animações gráficas em 3D. Nos tópicos a seguir deste capítulo, serão
descritas as vantagens e desafios de tal proposta, intitulada “OpenGL Embarcado”.
4.1.1 O que é OpenGL?
O OpenGL é uma interface de software para aplicações gráficas que é incorporada a
programas em C. Esta interface tem aproximadamente 250 comandos distintos (200 no
core do OpenGL e mais outros 50 na biblioteca de utilidades do OpenGL), que podem
ser utilizados para especificar operações e objetos necessários para produzir aplicações
interativas em tridimensionais.
4.1.2 A proposta: OpenGL Embarcado
No OpenGL, o frame-buffer é o buffer final de imagem enviado à tela. Da mesma
forma que qualquer processo sendo executado em um computador, o buffer consiste em
uma região de memória, onde é armazenada e processada toda uma vasta gama de dados
referente à imagem que deve ser exibida na saída de vídeo.
A proposta para a criação do OpenGL Embarcado consiste dos seguintes requisitos
básicos para o seu funcionamento:
Todo processo tem uma saída padrão de execução e uma saída padrão de erro, e nos
processos gráficos, existe uma saída extra de vídeo, aberta através das chamadas de
sistema no sistema operacional. O OpenGL Embarcado deve desabilitar a saída
padrão de vídeo do processo, devido ao fato da saída padrão de vídeo não ser
controlada pelo sistema operacional como de costume, e sim pelo sistema dedicado
a vídeo embarcado na placa. Simplesmente não desabilitando esta saída faria a CPU
Nios II perder tempo fazendo uma tarefa que nesta modelagem vem a ser sem
sentido.
Em um loop infinito ou com alta frequência, deve-se copiar o conteúdo da região de
memória do frame-buffer do processo OpenGL, executado na CPU Nios II, para a
46

egião do pixel-buffer do sistema digital dedicado a vídeo. Isto é feito na etapa final
em hardware, mas em primeira instância, em software.
Em software, o OpenGL proporciona funções que copiam trechos de memória do
frame-buffer do processo. Esta tarefa pode ser realizada através das seguintes chamadas
de função apresentadas na Tabela 8 .
Tabela 8 - Funções usadas para escrever, ler e copiar dados de uma área de pixels no framebuffer
de um programa em OPENGL.
Chamada de função Função
glReadPixels() Ler uma área retangular em forma de vetor de pixels do
framebuffer e o guardar na memória do processador.
glDrawPixels() Escrever uma área retangular em forma de vetor de
pixels de dados guardados na memória do processador
para o framebuffer na corrente posição de rasterização.
glCopyPixels() Copiar uma área retangular em forma de vetor de pixels
de uma parte do framebuffer para outra. Este comando
funciona de maneira similar a uma chamada de
glReadPixels() seguida por uma chamada de
glDrawPixels(), mas desta forma os dados jamais
passam pela memória do processador.
4.1.3 Dúvida relativa ao desempenho do OpenGL Embarcado
Uma imagem em movimento precisa no mínimo, de acordo com o teorema de
Nyquist (Enuncia que a freqüência de amostragem de um sinal analógico deve ser igual
ou maior a duas vezes a maior frequência do espectro desse sinal para que haja somente
o mínimo de perdas possíveis na reconstrução do sinal, isto é, ≥ 2), ser
redesenhada em uma frequência de 30 vezes por segundo para que o olho humano não
sinta efeitos de movimentação (motion-effect). Consequentemente, sabendo que o
OpenGL é uma ferramenta poderosa e pesada de design em 3D, fica uma dúvida
significativa relativa ao processamento destes dados no Nios.
O OpenGL usa bastante tempo de processamento de uma CPU, devido às suas
renderizações, translações e rotações serem calculadas matematicamente em forma
47

vetorial. Caso o poder de processamento da CPU Nios II não seja suficiente para
executar as tarefas pesadas do OpenGL, assim como copiar todos estes dados para a
tela, surge a questão de como fazer para que este sistema realize os cálculos vetoriais
necessários e também fique constantemente copiando o frame-buffer para o pixel-buffer
que é exibido na tela. Uma solução proposta para evitar a sobrecarga de uma CPU Nios
II será dada na seção a seguir.
4.1.4 Uma solução proposta em caso de fraco desempenho do OpenGL
Embarcado
Partindo de que uma das maiores vantagens de uma FPGA, que é a
reconfigurabilidade, questiona-se como solução a possibilidade de adicionar outra CPU
Nios ao sistema. Isto é, usar a FPGA da placa DE2 como um processador dual-core
através de uma nova modelagem, onde as duas CPU Nios II se complementariam a
tarefa em fluxos distintos, de forma que uma seria especifica para a cópia de dados de
uma memória partilhada e envio a saída VGA enquanto a outra realizaria os cálculos
vetoriais e escrita na mesma memória partilhada.
Uma CPU Nios II do tipo f calcularia todo o processamento vetorial requerido pelo
OpenGL, enquanto outra CPU Nios II do tipo e (simples acesso a pontos flutuantes)
realizaria a cópia dos dados processados no frame-buffer ao pixel-buffer do sistema
dedicado a vídeo.
Mesmo que a cópia dos dados de um setor da memória para o sistema de vídeo seja
um algoritmo de complexidade ( ∗ ) (onde l representa largura e a representa altura
da imagem), ter um processador exclusivo para esta tarefa unido a outro para os
cálculos vetoriais do OpenGL, torna o sucesso desta hipótese de execução muito
pertinente. A comunicação proposta entre os processadores seria realizada através das
técnicas de exclusão mútua (uso de Mutex, o que em C não seria algum problema), para
que assim os processadores não entrem em conflito ao ler e/ou escrever dados na área
da região crítica de memória do funcionamento deste sistema.
A arquitetura do sistema dual-core de processamento do OpenGL Embarcado
proposto, está ilustrada na Figura 26.
48

Figura 26 - Modelagem do Sistema Embarcado Dedicado a OpenGL.
4.2 Aplicações do OpenGL Embarcado proposto
Após a implementação com sucesso deste sistema aqui proposto, são diversas as
vantagens que podem alcançadas, sejam estas acadêmicas ou inclusive de mercado.
Dedicando este sistema a modelagens especiais tem-se uma gama de variedades de uso
bem abrangente graças a reconfigurabilidade da FPGA e agora da modelagem em 3D
também. Nesta parte do texto, serão expostas e descritas duas atividades completamente
distintas, onde se acredita que a implantação do OpenGL Embarcado poderia influenciar
ao ponto de trazer grandes contribuições aos respectivos projetos projetos.
4.2.1 Aplicação BioFeedArt
A aplicação BioFeedArt que está em desenvolvimento, vinculada à FAPERN
(Fundação de Apoio e Pesquisa do Estado do Rio Grande do Norte), tem como enfoque
a controlabilidade de arte gráfica abstrata em uma saída de vídeo, de tal forma que este
49

controle seja baseado na aquisição de biopotenciais. Os biopotenciais em destaque nesta
atividade são: o EEG (Eletroencefalograma), o ECG (Eletrocardiograma) e EMG
(Eletromiograma).
Os pesquisadores desse projeto objetivam utilizar os potenciais humanos para
gerenciar algoritmos gráficos abstratos de Fractais. Cores, iluminação e velocidade de
um Fractal são algumas grandezas possíveis de serem gerenciadas por um pulso R de
um ECG ou da subida das ondas de um EEG, por exemplo.
Fractais são figuras da geometria não-Euclidiana que podem ser criadas
algoritmicamente. Embora existir a ciência (geometria fractal) que estuda o
comportamento dos mesmos, a característica mais notória de alguns fractais, quais se
pretendem usar neste projeto, se dá devido ao fato que mesmo constituindo imagens em
2D, fractais tem a capacidade de serem interpretados em 3D ou em movimento pelo
cérebro humano. O desenvolvimento algorítmico de diversos Fractais é realizado por
equações de diferenças que escolhem a posição de novos pontos () em relação ao
ponto anterior ( − ). Por detrás da linda arte de Fractais podem existir complexas
análises matemáticas, que chegam a envolver processos estocásticos e teoria do Caos
dentre outros modelos matemáticos. Na Figura 26, se é exibido um exemplo de Fractal
que mostra uma folha de samambaia que foi desenhada por um sistema de equações de
diferenças.
Figura 27 - Uma folha de samambaia formada por um Fractal. Matematicamente conhecido por
Feto-Fractal.
50

Com o sistema dedicado a vídeo para pesquisa biomédicas (principalmente o fato da
possível interferência dos sinais vitais no que é exibido e no que é visto pelo paciente),
pensa-se em criar circuitos de aquisição dos biopotenciais que seriam acoplados a um
componente especial de aquisição do sistema embarcado na FPGA, que seja capaz de
receber os biopotenciais através das GPIO.
Figura 28 - Modelagem esquemática do BioFeedArt
Para aumentar o grau de realidade virtual, entra a possibilidade do estudo de Fractais
em 3D, onde novas grandezas como espessura, tamanho, largura, altura, distancia,
ângulo da visualização e outras, permitirão que este projeto tenha uma maior gama de
dados que influenciariam os sinais vitais do individuo em teste. Para o devido uso destas
grandezas, o projeto OpenGL Embarcado pode ser de suma importância.
Finalmente, este projeto visa expandir a interdisciplinaridade entre medicina,
instrumentação biomédica, sistemas embarcados e artes gráficas. Atualmente, o projeto
BioFeedArt está em andamento, supervisionado pelo Sr. Mathieu Duvignaud do
Departamento de Artes da UFRN para o auxílio do desenvolvimento artístico gráfico
abstrata, e pelos Prof. Dr. Gláucio Bezerra Brandão e Prof. Dr. George Carlos do
Nascimento, ambos do Departamento de Engenharia Biomédica da UFRN, quanto ao
desenvolvimento tecnológico.
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
O petróleo atualmente se constitui na principal matriz energética do mundo.
Alimentar energeticamente siderúrgicas, fornecer matéria prima para indústrias e
abastecer automóveis são alguns dos inúmeros exemplos da utilização do petróleo no
cenário global atual. O petróleo e seus derivados se constituem em matéria prima para
mais de 3.000 produtos petroquímicos e materiais de construção, dentre vários outros.
Consequentemente, a descoberta de novas jazidas de petróleo tem uma grande
importância para que a reserva energética mundial seja mantida, de forma a suprir a
demanda das atividades petrolíferas dos países. Entretanto, ao considerar que a
exploração de petróleo nas bacias sedimentares se constitui em uma atividade muito
dispendiosa, o desenvolvimento de tecnologia para esta área torna-se de suma
importância. Descobertas inovadoras tanto na área de perfuração de poços quanto na
área de descoberta de reservatórios são necessárias para que esta tarefa de exploração
seja mais rentável e tenha maior valor agregado para o investidor, o qual pode ser
privado ou estatal.
Ultimamente, em um cenário de atenção nacional, tem-se ouvido muito a
respeito das novas descobertas de fontes imensas de petróleo na Bacia de Campos, onde
se encontra a mais relevante área da região do Pré-sal brasileiro. A Petrobras prevê
atingir a marca de 1,8 milhão de barris diários de petróleo extraído da camada pré-sal
nos próximos 12 anos.
No Brasil o Pré-sal por lei vai do estado de Santa Catarina até o Espírito Santo;
geologicamente, entretanto, esta área vai até a Bahia. Mais especificamente, por lei esta
área marítima é definida a partir de 300 km da costa leste brasileira de Santa Catarina
até o Espírito Santo, com 800 km de extensão por até 200 km de largura que totalizam
149 mil km 2 . Esta localização está ilustrada na Figura 26.
52

Figura 29 - Região do Pré-sal brasileiro.
Sob uma lâmina de 2.000 metros de água somada a uma camada de 5.000 metros
de sal, existe uma jazida muito farta de petróleo o que acarreta na perfuração offshore
(no mar) de poços que excedem 7.000 metros de profundidade. A grande diferença na
exploração do Pré-sal se deve ao fato de que, nos demais países, o processo de
exploração era interrompido quando se alcançava uma camada de sal. Entretanto, esta
camada de sal funcionou como uma armadilha adicional para o petróleo, que não
conseguiu escoar a superfície (fluxo natural).
Figura 30 - Formações geológicas antes do Pré-sal
53

Estudos sísmicos da região sempre mostravam imagens sísmicas de péssima
qualidade. Entretanto, a Petrobrás realizou um grande investimento em
desenvolvimento voltado para a tecnologia de imagens, perfuração e robótica. Os
estudos da robótica são amplamente conhecidos no mundo, mas somente a Petrobrás é
detentora da tecnologia robótica remota que suporte altas pressões como as encontradas
a 2.000 metros, no fundo do mar da Bacia de Campos.
A evolução maciça da tecnologia de processamento de imagens acarretou nas
atuais descobertas da Bacia de Campos. Neste escopo das atuais necessidades da área,
após uma pesquisa dos sistemas atuais com alguns engenheiros da área do departamento
de Engenharia de Petróleo da UFRN (Prof. Dr. José Romualdo Dantas Vidal e Prof. Dr.
Edney Rafael Viana Pinheiro Galvão), propõe-se desenvolver sistemas embarcados de
modelagem em 3D de tempo real para o auxilio de perfuração de poços direcionais, uma
área que carece deste tipo de sistema.
4.2.2.2 Proposta de desenvolvimento de um Sistema Gráfico Para
o Auxilio do Processo de Perfuração de Poços Direcionais
Um poço é denominado direcional quando o reservatório a ser atingido se
encontra em uma direção inviável de ser atingida verticalmente, isto é, torna-se
necessário utilizar técnicas especiais, distintas das empregadas na perfuração de poços
verticais, com o objetivo de realizar o desvio necessário para atingir o poço.
Estes poços, mesmo exigindo mais investimentos em perfuração, no projeto, em
material e na preservação do meio ambiente (principalmente na exploração offshore,
que acarreta diversos riscos de vazamento como os vistos no caso recente do Golfo do
México em um poço offshore da companhia British Petrolium), geralmente resultam em
bons resultados de extração.
Diferentemente dos poços verticais, os poços direcionais requisitam um projeto
de perfuração mais complexo. Este projeto consiste na determinação da trajetória que o
poço deverá seguir para atingir o reservatório desejado. Para elaborar este projeto, deve-
se coletar e montar um banco de dados de adequação da forma de perfuração em relação
aos diversos perfis de formações geológicas que serão atravessadas durante a
perfuração. Na Figura 28, é apresentada a ilustração de um poço direcional.
54

Figura 31 - Modelagem de um poço direcional
A modelagem gráfica desta trajetória é realizada após a perfuração dos poços. Os
dados referentes à direção e angulação da trajetória de perfuração são adquiridos já no
formato digital e são enviados a uma central de controle, para que seja modelada a
trajetória realizada após a perfuração.
A idéia proposta nesta seção é a da integração de um componente no sistema do
OpenGL Embarcado para a aquisição destes sinais digitais através das GPIO numa
placa DE2, por exemplo. Na camada de software no OpenGL, seriam modelados
objetos gráficos em 3D como as formações geológicas, os diversos tipos de brocas
(tungstênio com dentes de aço, diamantadas, etc.), colunas de perfuração e quaisquer
outros objetos gráficos que sejam necessários para representar graficamente o processo
de perfuração de um poço. O sistema deve receber os dados da perfuração e assim
modelar as atividades em tempo real.
Através de cálculos de mecânica dos solos e dos fluídos, seria possível implementar
estes ambientes graficamente, os quais são de suma importância para o auxilio de uma
perfuração direcional, que em média não pode variar mais que 5% da trajetória
planejada, porém não visualizada.
Os dados a serem utilizados são os colhidos de acordo com a técnica atual de
perfuração conhecida como MWD (Measuring While Drilling, ou Medindo Enquanto
Perfurando), que faz uma aquisição e digitalização dos dados de perfuração em tempo
55

eal de acordo com a dinâmica do processo. Alguns dos dados coletados pela tecnologia
atual são listados a seguir:
• Direção da perfuração.
• Inclinação de perfuração.
• Velocidade de rotação da coluna de perfuração.
• Grau de suavidade da rotação da broca.
• Tipo vibrações da formação no poço.
• Temperaturas do poço.
• Torque e peso da broca.
• Volume para o controle da injeção de lama.
Dos dados relacionados acima, os principais e de extrema necessidade para o auxílio
da perfuração de poços direcionais são os dois primeiros, isto é, a direção e a inclinação
da perfuração. Estes dados podem ser alimentados em um sistema de simulação e
modelagem de imagens em 3D qual pode exercer grande serventia a este processo. Com
isso, pode-se criar um banco de dados em tempo real que auxilie a perfuração dos poços
direcionais para manter tanto a trajetória da perfuração destes poços como a segurança
durante tal procedimento. Estes dados de perfuração serão mais detalhados na Tabela 9.
Tabela 9 - Dados que podem ser utilizados na modelagem em 3D do sistema embarcado voltado ao
auxílio de sistemas petroliferos.
Nomenclatura dos dados de
perfuração
Descrição
Direção (x,y,z) - ângulo de direção
entre a trajetória do poço e o norte
geográfico
Grau de inclinação entre a trajetória e
a direção do vetor gravidade
Outra técnica de aquisição de dados que trabalha com o MWD é o LWD
(Logging While Drilling ou Anotando Enquanto Perfura), que registra dados referentes
aos reservatórios petrolíferos, tais como porosidade, BSW, dentre outros. Como o
56

projeto objetiva auxiliar especificamente a perfuração de poços direcionais, tais dados
não são pertinentes para esta modelagem.
5.0 Conclusão
Este trabalho teve como enfoque o estudo, pesquisa e desenvolvimento de sistemas
embarcados, fazendo uso das ferramentas tais como as placas de desenvolvimento da
corporação Altera, uma das empresas mais atuantes, abrangentes e fortes do mercado.
Através da pesquisa aqui realizada, foram explanados todos os passos necessários
para a realização da modelagem, desenvolvimento e integração de sistemas embarcados
utilizando as ferramentas e as IDE’s disponibilizadas pela corporação Altera. Além
disso, abordou-se a metodologia modular de desenvolvimento que a Altera propõe para
seus sistemas. Partindo desta forma de desenvolvimento, foram discutidos todos os
passos necessários para a integração de um sistema digital de vídeo. Este sistema digital
dedicado a vídeo foi integrado com sucesso e demonstrado na defesa do trabalho, com o
auxilio do uso da placa de estudo DE2 também proveniente da Altera.
Através de códigos em auto nível na IDE Nios II na linguagem C, e das bibliotecas
de abstração de hardware (HAL) disponibilizadas pela Altera, foi criada uma camada de
software que tornou possível a leitura/escrita de dados nos diversos periféricos da placa
DE2, assim como na saída de vídeo VGA, através da camada de hardware integrada.
Esta camada de hardware foi modelada com os componentes disponíveis das IDE’s
SOPC e University Cores, quais têm como finalidade automatizar e tornar mais eficaz o
processo de desenvolvimento de sistemas embarcados nos sistemas desenvolvidos para
produtos Altera. Através da IDE Quartus II e seus módulos, esta camada de hardware
pôde ser integrada com os periféricos e seus respectivos controladores. Os principais
periféricos utilizados foram as memórias, processadores, contadores, clocks, além de
botões, LED’s e o mais especial para este projeto, a saída de vídeo VGA.
5.1 Considerações finais
A área de sistemas embarcados tem uma demanda significativa no mercado
atualmente. Celulares, videogames, marca-passos e muitos outros dispositivos nos
mostram que estes sistemas, por diversas vezes de dimensão reduzida, são de extrema
importância. A necessidade de desenvolvimento destes sistemas obriga os
57

pesquisadores da área de tecnologia a inovar sobre criações anteriores, para que desta
forma encontrem soluções para problemas que sequer ainda foram formulados. A
possibilidade de contribuir para a presente revolução tecnológica se mostra como um
elemento adicional de motivação para a elaboração de trabalhos nesta área.
5.2 Perspectivas futuras
Espera-se seguir com esta linha de pesquisa, pois a mesma vai além das linhas
traçadas neste projeto. Na etapa final deste trabalho, foi proposto um grau maior de
integração do sistema digital de vídeo embarcado aqui implementado, com uma
conhecida linguagem de programação de ambientes gráficos em 3D, o OpenGL. Esta
proposta visa à integração de um sistema mais robusto, complexo e poderoso em
processamento, já que propõe o uso de um sistema dual-core de Nios II. Uma CPU Nios
teria a responsabilidade de realizar o processamento gráfico vetorial que o OpenGL
requer, enquanto a outra seria responsável pela cópia continua dos dados dos pixels do
frame-buffer do OpenGL da primeira CPU para o pixel-buffer desta CPU e assim,
consequentemente, para a saída de vídeo VGA também conectada ao processador Nios
II desta CPU.
O sistema dual-core Nios II é formado pelo forte acoplamento de processadores
Nios II, os quais, munidos de todos os benefícios dos controladores e periféricos das
placas de estudo da Altera, podem ser aplicados a outras diversas linhas de pesquisas
como a de sistemas paralelos distribuídos a sistemas embarcados.
58

REFERENCIAS BIBLIOGRÁFICAS
Adam Kinsman, Nicola Nicolici(2009), COE4DS4 Embedded Systems - Lab #2 -
Introduction to Embedded Software for the NIOS II Processor. Hamilton, ON –
CA: McMaster University.
Addison-Wesley (1999), OpenGL Programming Guide: The official guide to
learning OpengGL, Third Edition, Version 1.2. Massachusetts, USA: Sylicon
Graphics.
ALTERA CORPORATION. (2010), Nios II Performance Benchmarks. DS-
N28162004-5.0.
ALTERA CORPORATION. (2009), Introduction to SOPC Builder, QII54001-9.1.0
ALTERA CORPORATION. (2009), SOPC Builder Components, QII54004-9.1.0.
ALTERA CORPORATION. (2009), SOPC Builder Memory Subsystem
Development Walkthrough, QII54006-9.1.0.
ALTERA CORPORATION. (2009), System Interconnect Fabric for Streaming
Interfaces, QII54019-9.1.0.
ALTERA CORPORATION. (2009), Avalon Streaming Interconnect Components,
QII54021-9.1.0.
ALTERA CORPORATION. (2009), VGA Out IP Cores for Altera DE Boards,
QII54004-9.1.0.
ALTERA CORPORATION. (2009), Avalon Interface Specifications, Version.1.2,
MNL-AVABUSREF-1.2.
ALTERA CORPORATION. (2009), Instantiating the Nios II Processor in SOPC
Builder, NII51004-9.1.0.
59

ALTERA CORPORATION. (2009), Nios II Processor Reference Handbook,
NII5V1-9.0.
ALTERA CORPORATION. (2008), Pixel Buffer for Altera DE2/DE1 Boards,
Version 8.0.0.1.
ALTERA CORPORATION. (2008), Quartus II Introduction Using Schematic
Design.
ALTERA CORPORATION. (2008), Introduction to the Altera Nios II Soft
Processor, 6XX-40020R.
ALTERA CORPORATION. (2008), DE2 Using C.
ALTERA CORPORATION. (2007), Nios Development Board: Cyclone II Edition
Reference Manual, 6XX-40020R.
ALTERA CORPORATION. (2006), Using the SDRAM Memory on Altera’s DE2
Board.
ALTERA CORPORATION. (2006), VGA Core for Altera DE2/DE1 Boards
ALTERA CORPORATION. (2005), Using SOPC Builder & DSP Builder Tool Flow,
Version.1.0, Aplication Note 394.
ALTERA CORPORATION. (2005), Using DDR/DDR2 SDRAM With SOPC
Builder, Version.1.1, Aplication Note 398.
ALTERA CORPORATION. Mason Woo, Jackie Neider, Tom Davis, Dave Shreiner
(2004), Introduction to Quartus II, Version 4.1. California, USA.
Luis Alberto Santos Rocha, Denize Azuaga, Renata Andrade, João Luiz Bastos Vieira,
Otto Luiz Alcântra Santos (2008), Perfuração direcional. Editora Interferência.
60

James O. Hamblen, Tyson S. Hall, Michael D. Furman (2008), Rapid prototyping of
digital systems SOPC Edition. New York: Springer Science + Business Media, LLC.
61