BACHARELADO EM ENGENHARIA DE COMPUTAÇÃO
FLADMY ALVES DE SOUZA
IMPLEMENTAÇÃO EM FPGA DE DETECÇÃO DE BORDAS EM IMAGENS DIGITAIS
FEIRA DE SANTANA 2012
IMPLEMENTAÇÃO EM FPGA DE DETECÇÃO DE BORDAS EM IMAGENS DIGITAIS
Trabalho de Conclusão de Curso apresentado ao Colegiado de Engenharia de Computação como requisito parcial para obtenção do grau de Bacharel em Engenharia de Computação da Universidade Estadual de Feira de Santana.
Orientador: Prof. Dr. Anfranserai Morais Dias
FEIRA DE SANTANA 2012
esta pequena vitória a vocês, pai e mãe, por me ensinarem a força do trabalho, dedicação e perseverança, por me ensinarem a importância do caráter e pelo apoio em todos os momentos da minha vida. Dedico também aos meus irmãos Francisco Alves Filho, Cleidiana Alves de Souza e Elialdo Alves de Souza pela fonte de admiração que são para mim.
Agradeço aos meus pais, Francisco Alves Sobrinho e Maria Ferreira Calado, pelo suporte, carinho e amor incondicional.
Agradeço a minha namorada, Isabela Santos Gonçalves, pela companhia, carinho e respeito. Obrigado pelos momentos de alegria e tristeza que passamos ao longo desses quase cinco anos de curso e namoro. Obrigado pela companhia nas várias horas de estudo noite a dentro tomando café e comendo biscoito, obrigado pela paciência nos momentos de stress e ajuda nos momentos de dificuldade.
Agradeço aos meus colegas pela oportunidade de convivência e troca de experiências, em especial a Luiz Bernardo, Igor Leonardo e Carlos Emanuel por se revelarem grandes companheiros de PBL e grandes amigos dentro e fora da Universidade. João Carlos Nunes Bittencourt, por ter disponibilizado o template da monografia em latex facilitando o trabalho de todos. Fernando Alberto Correia, por ter dividido a casa comigo por mais de três anos sem nenhum tipo de problema. Agradeço também ao meu amigo de infância Lucas Lima Batista pela amizade e por ter me apresentado o curso.
Agradeço aos professores que compartilharam um bem precioso conosco, o seu conhecimento, pela paciência e boa vontade em ensinar. Em especial agradeço ao professores Angelo Conrado Loula e Antonio Lopes Apolinário Jr. por quase dois anos de orientação em projeto de pesquisa e ensinamentos que vão além da sala de aula. Obrigado também ao professor Anfranserai Morais Dias pela orientação nesse trabalho de conclusão de curso, pela ajuda preciosa nos momentos de dificuldade.
O processamento digital de imagens tem aplicação em várias áreas do conhecimento, desde o entretenimento, como games, até exames médicos capazes de identificar vários tipos de doenças. No entanto, algumas aplicações, como em robótica, geralmente necessitam de sistemas que possam ser embarcados e sejam capazes de fornecer uma alta taxa de processamento. Nos últimos anos o uso de FPGAs em projeto de circuitos integrados, possibilitando que se façam testes ainda no ambiente de desenvolvimento, antes dos ASICs equivalentes serem colocados em produção, tem facilitado esse tipo de aplicação. O presente trabalho descreve o processo de desenvolvimento de um IP-Core para detecção de bordas em imagens digitais em tempo real com prototipação em FPGA. Bem como os resultados alcançados e evolução do IP-Core devido a verificação funcional.
The digital image processing can be used in several kind of applications. However some applications such as robotics, usually needs systems that can be embedded and must provide a high processing rate. In recent years the use of FPGAs in integrated circuit design, enabling them to make tests in the fiels before ASIC production has facilitated such application. This paper describes the process of developing a IP-Core for detecting edges in digital images in real time with prototyping in FPGA.
Figura 1 Passos Fundamentais em Processamento Digital de Imagens 12
Figura 2 Digitalizando uma Imagem 14
Figura 3 Transformada de Fourier de uma Imagem. 15
Figura 4 Filtragem no Domínio da Frequência. 15
Figura 5 Ilustração do Processo de Convolução. 17
Figura 6 Região de uma Imagem 3x3. 18
Figura 7 Resultado Obtido com Operador de Sobel. 18
Figura 8 Arquitetura do ipPROCESS. 20
Figura 9 Fases do ipPROCESS. 20
Figura 10 Ilustração do Fluxo de Atividades da Disciplina Requisitos. 22
Figura 11 Detalhamento da Atividade Analisa o Problema 23
Figura 12 Ilustração do Fluxo de Atividades da Disciplina Análise e Projeto. 23
Figura 13 Fluxos da Implementação RTL e Verificação Funcional. 24
Figura 14 Fluxos da Prototipagem. 24
Figura 15 Arquitetura do Testbench 25
Figura 18 Diagrama de Classes (Fase Inicial) 29
Figura 19 Kit de Desenvolvimento DE2 30
Figura 20 Diagrama de Blocos da Proposta do Trabalho 31
Figura 21 Caso de Uso da Convolução 33
Figura 22 Diagrama de Classes da Convolução 33
Figura 23 Arquitetura Final do Sistema 34
Figura 24 Ilustração do Uso dos Buffers 36
Figura 25 Troca de Buffer em Uso na Convolução 36
Figura 26 Controle dos Buffers de Linhas 37
Figura 27 Evolução do Resultado com a Verificação Funcional 41
Figura 28 Imagem de Saída em Escala de Cinza 42
Figura 29 Imagem de Saída em Estágio Intermediário de Desenvolvimento 42
Figura 30 Imagem de Saída na Versão Final 43
Figura 31 Protótipo em Funcionamento no Kit 43
Tabela 1 Requisitos Funcionais do Sistema 32
Tabela 2 Requisitos Não Funcionais do Sistema 32
Tabela 3 Teste Para Detectar Bordas em uma Imagem 39
Tabela 4 Teste Para Detectar Bordas em um Vídeo 39
CI Circuito Integrado
ipPROCESS Processo de Desenvolvimento para IP-Core
SoC System-on-Chip
IP-Core Intellectual Property Core
DUV Design Under Verification
UML Unified Modeling Language
1 INTRODUÇÃO. . . 10
2 FUNDAMENTAÇÃO TEÓRICA . . . 12
2.1 PROCESSAMENTO DIGITAL DE IMAGENS . . . 12
2.1.1 FILTRAGEM NO DOMÍNIO DA FREQUÊNCIA . . . 14
2.1.2 FILTRAGEM ESPACIAL . . . 15
2.1.2.1 CONVOLUÇÃO ESPACIAL . . . 16
2.1.2.2 FILTROS ESPACIAIS DE AGUÇAMENTO NÃO LINEAR . . . 16
2.2 IPPROCESS . . . 19 2.2.1 AS FASES DO IPPROCESS . . . 20 2.2.2 AS DISCIPLINAS DO IPPROCESS . . . 21 2.2.3 VERIFICAÇÃO FUNCIONAL . . . 25 3 METODOLOGIA . . . 27 3.1 FASES DO DESENVOLVIMENTO . . . 27 3.1.1 CONCEPÇÃO . . . 27 3.1.2 ARQUITETURA . . . 28 3.1.3 IMPLEMENTAÇÃO RTL . . . 28 3.1.4 PROTOTIPAGEM . . . 29
3.2 PRINCIPAIS FERRAMENTAS UTILIZADAS . . . 31
4 RESULTADOS. . . 32
4.1 CONCEPÇÃO . . . 32
4.2 ARQUITETURA . . . 33
4.2.1 SOLUÇÃO APLICADA NA IMPLEMENTAÇÃO DA CONVOLUÇÃO . . . 35
4.3 IMPLEMENTAÇÃO RTL . . . 37 4.3.1 VERIFICAÇÃO FUNCIONAL . . . 37 4.3.1.1 MODELO DE REFERÊNCIA . . . 37 4.3.1.2 FONTE . . . 38 4.3.1.3 VERIFICADOR . . . 38 4.3.1.4 CASOS DE TESTE . . . 38
4.3.1.5 RESULTADO FINAL DA VERIFICAÇÃO FUNCIONAL . . . 40
4.4 PROTOTIPAGEM . . . 41
5 CONSIDERAÇÕES FINAIS . . . 45
1 INTRODUÇÃO
A representação e processamento da informação visual tem papel fundamental na vida do ser humano. A versatilidade dessa característica biológica, impulsionou o desenvolvimento do processamento digital de imagens. Geralmente o resultado de tal processamento deve levar em consideração algumas importantes características da visão humana, tais como:
• O olho humano, pode se adaptar a uma quantidade de níveis de intensidade luminosa na órdem de 1010
• O brilho percebido não é função apenas da intensidade, ou seja, a visão pode subestimar ou superestimar os contornos entre regiões de diferentes intensidade a depender da transição entre estas (GONZALEZ, 2010).
Tais características são de extrema importância no desempenho de atividades do dia a dia das pessoas, como por exemplo, identificar um objeto em diferentes condições de iluminação.
As técnicas de computação visual são utilizadas em sistemas de segurança, reconhecimento automático de pessoas, filtragem de imagens, detecção de queimadas em imagens de satélites, entre outros (GONZALEZ, 2010). O processamento digital de imagens possibilita a um sistema computacional extrair a partir de imagens capturadas as informações necessárias à aplicação desejada (PRATT, 2007). Apesar de ser custoso do ponto de vista computacional, as técnicas de processamento de imagens estão sendo cada vez mais utilizadas, devido a evolução e barateamento do projeto de circuitos integrados. Atualmente, o projeto a ser disponibilizado em um Circuito Integrado ( CI ) pode ser testado no ambiente de testes antes de ser colocado em produção, pelo uso de Field-Programmable Gate Arrays (FPGA). O FPGA é um circuito reconfigurável que possibilita a prototipação e testes no desenvolvimento de projetos de circuitos integrados com um baixo custo (KILTS, 2007).
Como principais vantagens em implementar o processamento de imagens embarcado, destacam-se:
• Aquisição e processamento são realizados em um único dispositivo dispensando um computador externo para efetuar o processamento;
• A programação é feita em baixo nível (diretamente no hardware), geralmente sem um sistema operacional, possibilitando a aplicação em sistemas que necessitem de resposta rápida na análise das imagens; e
• A possibilidade de fácil adaptação do dispositivo para que este possa ser acoplado a um sistema robótico, por exemplo, para auxiliar em tomadas de decisão com base nas informações extraídas do processamento das imagens adquiridas.
Deste modo, o objetivo do presente trabalho é desenvolver um hardware capaz de fazer detecção de bordas em tempo real, em FPGA, que possa ser acoplado a outros projetos que necessitem desse tipo de informação proveniente de uma imagem, como um robô que precisa identificar uma porta por exemplo.
Esse projeto é a continuação de um trabalho iniciado em um dos componentes curriculares do curso de Engenharia de Computação da Universidade Estadual de Feira de Santana(BRANCO et al., 2010), que especificou e documentou um Intellectual Property Cores (IP-Core) para detecção de bordas, baseado na metodologia ipPROCESS . Neste foram produzidos os documentos referentes ao IP-Core que serviram como ponto de partida para a pesquisa aqui descrita. Com base neste trabalho foi possível continuar o desenvolvimento fazendo ajustes e revisando a documentação a cada iteração no processo de desenvolvimento. Dessa forma, chegou-se então à implementação RTL e verificação funcional do IP-Core.
A abordagem utilizada neste estudo envolve a descrição das etapas de desenvolvimento do projeto. O capítulo 2 detalha os principais conceitos envolvidos ao longo de todas as etapas de desenvolvimento. No capítulo 3 é descrito o que foi feito para se chegar ao objetivo final do estudo e as principais ferramentas utilizadas para isso. O capítulo 4 mostra os resultados alcançados ao final do desenvolvimento e, finalmente, o capítulo 5 apresenta as conclusões e considerações finais sobre o projeto.
2 FUNDAMENTAÇÃO TEÓRICA
Neste capítulo serão abordados os principais conceitos envolvidos no desenvolvimento do trabalho. Na primeira seção será abordada a teoria básica sobre processamento digital de imagens, mais especificamente a segmentação através de técnicas de filtragem. Na seção seguinte serão abordados os conceitos envolvidos na metodologia de desenvolvimento utilizada e na verificação funcional do IP-Core.
2.1 PROCESSAMENTO DIGITAL DE IMAGENS
Uma imagem monocromática pode ser definida por uma função de duas dimensões f (x, y), onde x e y são as coordenadas do plano espacial, e a amplitude de qualquer par de coordenada é chamado de intensidade ou nível de cinza (h) naquele ponto (GONZALEZ, 2010). Sendo x, y e h discretos e finitos, estes, podem ser manipulados e processados por um computador.
O processamento de imagens digitais envolve a aplicação de uma série de técnicas e algoritmos, com o objetivo de retirar informações úteis a uma determinada aplicação. A figura 1 mostra de forma geral os passos fundamentais em processamento digital de imagens.
Figura 1: Passos Fundamentais em Processamento Digital de Imagens
Fonte: Adaptada de Gonzalez (2010)
• Aquisição da Imagem: Para tornar possível o processamento digital, a imagem precisa passar por um processo de aquisição, amostragem e quantização.
– O processo de aquisição consiste no uso de sensores que convertem a intensidade da luz que inside sobre ele em um valor de tensão proporcional. – A amostragem e quantização vão definir, respectivamente, a dimensão espacial da imagem e a quantidade de níveis de cinza que serão usados para representá-la.
• Pré-Processamento: Esse passo consiste em manipular a imagem a fim de adequar à aplicação específica (GONZALEZ, 2010). Isso significa que as técnicas utilizadas nessa etapa serão totalmente orientadas de acordo com o problema. Qual quer operação feita na imagem com o objetivo de prepará-la para o próximo passo pode ser considerado um pré-processamento, como por exemplo, uma simples conversão de cores em RGB para escala de cinza.
• Segmentação: Consiste em subdividir a imagem em regiões ou objetos que a compõem de acordo com o interesse da aplicação. Ou seja, a imagem a partir desse ponto começa a ser analisada do ponto de vista da informação que ela pode fornecer. A identificação de tais regiões é feito com base em duas propriedades básicas dos valores de intensidade dos pixels: similaridade e descontinuidade. Na primeira, a região é selecionada com base na similaridade dos valores de intensidade, a segunda se baseia no oposto, na mudança brusca dos valores de intensidade para identificar os contornos de tais regiões(GONZALEZ, 2010). Uma das técnicas utilizadas nesse passo é a filtragem de baixas frequências da imagem destacando essas mudanças no valor da intensidade, a qual está inserida no escopo deste trabalho.
• Representação e Descrição: Esse passo converte os dados primários em formato adequado para posterior processamento. Geralmente parte do resultado obtido com a segmentação, que normalmente, os dados ainda não estão adequados ou representados de forma ideal para a extração de informação. • Reconhecimento e Interpretação: Aplica técnicas de classificação e
identificação de objetos para retirar a informação desejada, como por exemplo, as dimensões e posição de um obstáculo encontrado por um robô autônomo.
Na figura 2 é ilustrado o processo de geração de uma imagem digital a partir do espaço contínuo. Na figura 2(a) tem-se a imagem contínua, a 2(b) é o gráfico da função unidimensional com a variação da intensidade do nível de cinza que vai de A a B, o processo de amostragem e quantização são apresentados na figura 2(c). O intervalo é dividido em pequenos espaços iguais que representam os pontos da função discretizada e os níveis de cinza são divididos em oito intervalos discretos que
vão do preto ao branco. Finalmente, na figura 2(d), é apresentado o resultado da amostragem e quantização representada pela função discreta. Portanto, uma imagem digital pode ser representada quantitativamente por uma matriz, onde cada posição contem um valor de cinza e é indexado por x e y, conforme equação 1. Essas unidades formadoras da imagem digital são denominadas pixel (PRATT, 2007).
Figura 2: Digitalizando Uma Imagem.
(a) Imagem no Espaço Contínuo (b) Função que Descreve a Linha AB
(c) Amostragem e Quantização (d) Função Discreta
Fonte: Gonzalez (2010) f(x, y) = f(0, 0) f(0, 1) ... f(0, N − 1) f(1, 0) f(1, 1) ... f(1, N − 1) f(M − 1, 0) f(M − 1, 1) ... f(M − 1, N − 1) (1)
2.1.1 Filtragem no Domínio da Frequência
A filtragem no domínio da frequência consiste em transformar o domínio espacial da imagem para o domínio da frequência através da transformada de Fourier (OPPENHEIM; WILLSKY; NAWAB, 1997). Uma vez a imagem estando no domínio da
frequência é possível aplicar filtros, de acordo com o objetivo. Caso o objetivo seja eliminar ruídos de alta frequência, por exemplo, pode-se aplicar um filtro passa-baixa. Finalmente, após a aplicação do filtro calcula-se a transformada inversa de Fourier obtendo a imagem filtrada no dimínio espacial novamente(GONZALEZ, 2010). Na figura 3 é possível visualizar a aplicação da transformada, na figura 3(a) tem-se a imagem original e na figura 3(b) é mostrado o seu espectro de frequência após a aplicação da transformada de Fourier. Um exemplo de filtragem no domínio da frequência é ilustrado na figura 4.
Figura 3: Transformada de Fourier de uma Imagem.
(a) Imagem Original (b) Espectro de Frequência da Imagem
Fonte: UNICAMP (2003)
Figura 4: Filtragem no Domínio da Frequência.
(a) Imagem Original (b) Filtro Passa-Baixa (c) Imagem Filtrada
Fonte: UNICAMP (2003)
2.1.2 Filtragem Espacial
As técnicas de processamento no domínio espacial, ou seja, no próprio plano da imagem, baseiam-se na manipulação direta dos pixels. Contrastando
com o processamento no domínio da frequência, como visto na seção anterior, precisa realizar a transformada de Fourier, realizar o processamento, e então fazer a transformada inversa para obter a imagem processada.
O processamento no domínio espacial pode ser expresso pela equação 2, onde f(x, y) é a image de entrada, g(x, y) é a imagem de saída e T é um operador em f definido em uma vizinhança do ponto (x, y)(GONZALEZ, 2010).
g(x, y) = T [ f (x, y)] (2)
2.1.2.1 Convolução Espacial
O processo de convolução consiste em mover uma máscara(Matriz de convolução) rotacionada de 180 graus sobre a imagem. A convolução é fundamental na teoria de sistemas lineares e conseguentemente de filtros lineares espaciais, e é expressa pela equação 3 (GONZALEZ, 2010).
w(x, y) f (x, y) = a
∑
s=−a b∑
t=−b w(s,t) f (x − s, y − t) (3) Assim, para filtrar uma imagem através de convolução é necessário especificar a máscara do filtro de forma a corresponder a operação pretendida. Para criar um filtro de suavização, por exemplo, pode ser usado a máscara da equação 4, sendo z a intensidade dos pixel da região coberta pelo filtro. A saída de um filtro espacial linear de suavização á a média dos pixels contidos na vizinhança da mascara de filtragem. Esse tipo de filtro é conhecido como filtro de média ou passa-baixa por corresponder ao filtro passa baixa no domínio da frequência (GONZALEZ, 2010).R=1 9 9
∑
i=1 zi (4)A imagem da figura 5, ilustra o processo de deslocar o filtro sobre a imagem no processo de filtragem, mostrando em um determinado instante a região afetada pela máscara.
2.1.2.2 Filtros Espaciais de Aguçamento Não Linear
Para realçar as variações de intensidade os filtros usam a magnitude do gradiente. Para uma função f (x, y), o gradiente de f nas coordenadas (x, y) é definida como o vetor coluna bidimensional, mostrado na equação 5.
Figura 5: Ilustração do Processo de Convolução.
Fonte: Adaptada de Gonzalez (2010)
grad( f ) = " d f dx d f dy # (5)
O vetor 5 tem a importante propriedade de apontar em direção à maior taxa de variação de f na posição (x, y). O módulo da magnitude do vetor é dado pela equação 6, onde M(x, y) é o módulo no ponto, gx é a variação na direção x e gy na direção y. No entanto, para efeito de cálculo a fim de reduzir o custo computacional em sistemas de processamento digital de imagem o módulo pode ser aproximado para a equação 7.
M(x, y) =pgx2+ gy2 (6)
M(x, y) = |gx| + |gy| (7)
Sendo a figura 6 a região de uma imagem 3 × 3 onde z é o valor de intensidade, gxe gy são:
gy= (z3+ 2z6+ z9) − (z1+ 2z4+ z7) (9)
Figura 6: Região de uma Imagem 3x3.
Fonte: Gonzalez (2010)
As matrizes dos coeficientes das equações 8 e 9, mostradas em 10 e 11 respectivamente, são denominadas operadores de Sobel.
W(x, y)x= −1 −2 −1 0 0 0 1 2 1 (10) W(x, y)y= 1 0 −1 2 0 −2 1 0 −1 (11)
A figura 7 mostra um resultado obtido através do gradiente descrito acima.
Figura 7: Resultado Obtido com Operador de Sobel.
(a) Imagem ótica de uma lente de contato
(b) Gradiente de Sobel
2.2 IPPROCESS
Ao longo das últimas décadas houve uma crescente demanda por sistemas embarcados que agregam muitas funcionalidades, como tratamento de informação, entretedimento e comunicação. Porém o desenvolvimento de tais dispositivos é complexo e caro, impondo grandes desafios principalmente quanto a integração em um sistema, surgindo assim a necessidade de reuso dos componentes para projetos de circuitos integrados(CIs). Os avanços das técnicas de integração possibilitou a existência de vários sistemas complexos em um único chip, são os chamados System-on-Chip ( SoC ) (SALEH. et al., 2006). Os SoCs baseiam-se na idéia do reuso de componentes pré-existentes ou desenvolvidos, denominados Intellectual Property Cores ( IP-Core ), com o objetivo de reduzir o esforço e tempo do projeto. Por isso os desenvolvedores de IP-Core, precisam garantir alta qualidade e sucesso da integração.
Nesse contexto, o ipPROCESS (BRAZIL-IP, 2008) é uma alternativa de processo de desenvolvimento de IP-Core com prototipação em FPGA, baseado em RUP (KRUCHTEN, 2003). Assim o processo propõe um conjunto de disciplinas onde cada uma é definida como uma coleção de atividades relacionadas (LIMA et al., 2005). A figura 8 mostra a arquitetura do processo, onde a dimensão horizontal representa os aspectos dinâmicos do projeto, indicando como as atividades estão distribuidas no tempo e define as fases e marcos, enquanto a vertical mostra o aspecto estrutural do projeto, isto é, como este está descrito em termos das disciplinas. A figura mostra ainda a ênfase dada a cada disciplina em cada fase e como isso varia ao longo do tempo.
Figura 8: Arquitetura do ipPROCESS.
Fonte: Adaptada de Lima et al. (2005)
2.2.1 As Fases do ipPROCESS
O ipPROCESS é um processo com ciclo de vida iterativo e incremental, onde cada iteração gera um build (versão funcional). Do ponto de vista gerencial é dividido em quatro fases sequenciais e cada uma possui um marco principal, como visto na figura 9.
Figura 9: Fases do ipPROCESS.
Fonte: Adaptada de Lima et al. (2005)
As fases são difinidas de acordo com os objetivos e marcos a seguir:
do projeto e definir o seu escopo. O marco dessa fase é um documento de especificação funcional estável do projeto (LIMA et al., 2005).
• A fase Arquitetura tem por objetivo elaborar uma arquitetura estável para o IP-core que servirá de base para o projeto e implementação. O marco para a passagem para a próxima fase é apresentar tal arquitetura (LIMA et al., 2005). • Implementação RTL, tem como objetivo desenvolver um protótipo do IP-core
amplamente verificado baseado na arquitetura desenvolvida na fase anterior. O marco da fase é apresentar a codificação em nível RTL (LIMA et al., 2005). • Prototipagem, foca a criação do protótipo físico em FPGA para ter certeza que o
IP-core pode ser distribuído para os usuários finais (os integradores do sistema). O marco dessa fase é o protótipo em FPGA do IP-core (LIMA et al., 2005).
2.2.2 As Disciplinas do ipPROCESS
As disciplinas definem um fluxo geral, determinando as atividades a serem executadas, bem como sua ordem de execução. Cada atividade, por sua vez, é definida em termos de tarefas a serem executadas com seus respectivos papéis, que define o perfil necessário para sua execução, responsáveis e artefatos de entrada e saída (LIMA et al., 2005). A seguir serão descritas as disciplinas do processo, bem como os objetivos que seus respectivos conjuntos de atividades propõem atingir.
• Requisitos: os principais propósitos desta disciplina são: 1. Entender as necessidades do cliente.
2. Garantir que toda a equipe de desenvolvimento entenda os requisitos. 3. Definir a interface externa do IP-core de acordo com as necessidades e
objetivos do usuário final.
• Análise e Projeto: Os objetivos desta disciplina são: 1. Projetar a arquitetura do IP-core.
2. Especificar a funcionalidade dos componentes da arquitetura. • Implementação RTL: Como principais objetivos essa disciplina têm:
1. Implementar os componenetes definidos na arquitetura. 2. Definir como tais componentes devem ser integrados.
• Verificação Funcional: Essa disciplina será detalhada na próxima seção, devido sua importância no contexto de desenvolvimento de um IP-Core e consequente relevância no presente projeto. Seus objetivos básicos são:
1. Verificar se os requisitos estão sendo atendidos pelo modelo RTL.
2. Encontrar, documentar e corrigir problemas encontrados no modelo RTL. • Prototipagem: Objetivos:
1. Transformar o modelo RTL em um protótipo físico.
2. Validar a implementação dos requisitos no protótipo físico.
A figura 10 mostra o fluxo de trabalho e as atividades relacionadas à disciplina Requisitos, Como exemplificação, a figura 11 mostra o detalhamento da atividade Analisar o Problema.
Figura 10: Ilustração do Fluxo de Atividades da Disciplina Requisitos.
Figura 11: Detalhamento da Atividade Analisa o Problema
Fonte: Adaptada de Lima et al. (2005)
Na figura 12 é mostrado o fluxo de atividades da disciplina Análise e Projeto.
Figura 12: Ilustração do Fluxo de Atividades da Disciplina Análise e Projeto.
Fonte: Adaptada de Lima et al. (2005)
Veja na figura 13 o fluxo de atividades pertecentes às disciplinas Implementação RTL e Verificação Funcional, bem como a interação entre estas.
Figura 13: Fluxos da Implementação RTL e Verificação Funcional.
Fonte: Adaptada de Lima et al. (2005)
Na figura 14 pode-se visualizar o fluxo de atividades da disciplina Prototipagem.
Figura 14: Fluxos da Prototipagem.
2.2.3 Verificação Funcional
O maior desafio no desenvolvimento de um IP-Core é torna-ló confiável, de forma que os projetistas de SoCs possam incorporá-los em seus projetos sem causar problemas possibilitando o resuso. Nos últimos anos com a crescente complexidade dos projetos a verificação funcional se tornou o foco da maior parte do projeto e consequentemente, a parte mais cara deste. A qualidade e tempo de desenvolvimento de um IP-core dependem de como a verificação é feita (SILVA, 2007).
Verificação funcional é um processo utilizado para verificar se o módulo implementado está de acordo com suas especificações ou requisitos (BERGERON, 2003). Tal processo utiliza simulação para verificar o Design Under Verification ( DUV ), ou Modelo Sob Verificação. Para tornar isso possível é necessário que haja um conjunto de procedimentos capaz de gerar os estímulos e comparar as respostas do DUV com as de um modelo de referência, esse conjunto de procedimentos é denominado Testbench (BERGERON, 2003). Na figura 15 é mostrada a arquitetura de um Testbench típico.
Figura 15: Arquitetura do Testbench
Fonte: Adaptado de Silva (2007)
Cada componente tem uma função específica no processo de verificação do módulo a ser testado ou DUV. A seguir é apresentada a função de cada componente mostrado na figura 15.
do IP-Core.
• Modelo Sob Verificação é a implementação RTL do IP-Core.
• A fonte é responsável por gerar as transações que serão aplicadas tanto ao modelo de referência quanto ao DUV.
• O Driver é responsável por converter os estímulos gerados pelo source em sinais lógicos que possam ser aplicados à entrada do DUV, caso isso seja necessário.
• O Monitor converte os sinais de saída do DUV em formato que possa ser usado pelo verificador,caso isso seja necessário.
• Verificador compara as saídas do modelo de referência com as saídas do DUV, podendo assim identificar possíveis erros.
3 METODOLOGIA
O desenvolvimento do projeto amparou-se nas fases do ipPROCESS, descrito no capítulo 2. Neste capítulo será descrito o que foi feito, bem como as principais ferramentas utilizadas com base nas fases do processo de desenvolvimento.
3.1 FASES DO DESENVOLVIMENTO
É importante frisar que o processo de desenvolvimento é dinâmico e interativo, em cada fase todas as disciplinas do ipPROCESS são executadas, porém com intensidade diferente conforme figura 16. As partes em destaque na figura, mais escura, mostra as disciplinas que terão uma maior ênfase em cada fase.
Figura 16: Dinâmica do ipPROCESS
Fonte: BRAZIL-IP (2008)
3.1.1 Concepção
Na etapa de concepção os principais artefatos gerados são: o documento de requisitos do sistema e o diagrama de casos de uso. O primeiro define os requisitos funcionais e não funcionais, enquanto o segundo define graficamente um cenário que mostra as funcionalidades do sistema e seus principais atores. (BOOCH; RUMBAUGH; JACOBSON, 2000). A figura 17 mostra o diagrama de casos de uso elaborado nessa fase.
Figura 17: Diagrama de Casos de Uso (Fase Inicial)
Como dito anteriormente o processo é interativo, por isso, a figura 17 mostra o diagrama ainda em fase inicial do desenvolvimento. A evolução do desenvolvimento e resultados finais serão detalhados no capítulo 4.
3.1.2 Arquitetura
O próximo passo no desenvolvimento foi definir a arquitetura do sistema. Essa arquitetura se tornou a base para todo o restante do projeto, principalmente para a implementação. Para definir a arquitetura do sistema foi elaborado um diagrama de classe com o abjetivo de definir o relacionamento entre as entidades do projeto. Todos os diagramas utilizados durante o desenvolvimento do projeto foram baseados na linguagem de modelagem UML , por fazer parte de práticas de engenharia de software já disseminadas e consolidadas (BOOCH; RUMBAUGH; JACOBSON, 2000). A figura 18 mostra o diagrama de classe do sistema gerado na primeira interação do processo de desenvolvimento.
3.1.3 Implementação RTL
Nessa etapa, o projeto foi codificado com base na arquitetura, nos diagramas e requisitos elaborados nas fases anteriores. Uma atividade importante desenvolvida nessa fase foi a verificação funcional do protótipo, a qual foi essencial para verificar se os requisitos estavam sendo contemplados e certificar também se o algoritmo de
Figura 18: Diagrama de Classes (Fase Inicial)
detecção de borda tinha sido implementado corretamente. Na implementação do protótipo foi usado a linguagem de descrição de Hardware Verilog. Para implementar o testbench da verificação funcional foi utilizado a linguagem SystemVerilog.
Para a implementação do algoritmo de detecção de borda, foi necessário escolher a máscara/filtro a ser utilizado. Optou-se pela máscara de Sobel por possuir operações matemáticas mais simples de se implementar em hardware. Durante os estudos da técnica percebeu-se que os cálculos poderiam ser feito com soma simples e deslocamento de bits, adaptando-se assim, melhor ao projeto.
3.1.4 Prototipagem
Por fim, o código do IP-Core implementado foi embarcado em FPGA, com a utilização dokit de desenvolvimento DE2 da Altera. A escolha de tal equipamento se deve ao fato que ele possui recursos de hardware adequados ao funcionamento do IP-Core desenvolvido e possui uma FPGA Cyclone II EP2C35F672C6 and EPCS16 serial configuration device with 33.216 LEs. Veja na figura 19 a imagem do referido equipamento.
Figura 19: Kit de Desenvolvimento DE2 da Altera
Fonte: Altera (2006)
Uma vez que o Kit de desenvolvimento possui toda a parte de aquisição e conversão analógica digital da imagem, foi utilizado uma câmera analógica CCDSH 1/4 de 0.1 Lux com 420L e lentes de 3.6mm, padrão NTSC, com taxa de atualização de 60Hz. Foram utilizados também os seguintes recursos do kit:
• I/O Devices:
– Built-in USB Blaster for FPGA configuration: para fazer a gravação da FPGA – Video Out (VGA 10-bit DAC): para gerar a saída dos pixels processados no
monitor VGA.
– Video In (NTSC/PAL/Multi-format): conta com um chip que identifica automaticamente o padrão do vídeo e converte para o formato digital ITU-R BT.656, que por sua vez, extrai os valores YCbCr do pixel através do bloco também existente no kit chamado ITU-R 656.
• Memory:
– 8-MB SDRAM: utilizada para armazenar a imagem que está sendo decodificada.
– 18 toggle switches: utilizados para definir o modo de exibição e threshold. – 1 debounced pushbutton switche: para resetar todo o sistema.
– Eight 7-segment displays: mostra o frame rate em hexadecimal. – 27-MHz and 50-MHz oscillators: clocks usados no sistema.
Dessa forma, a proposta do trabalho é colocar o módulo de processamento desenvolvido entre a aquisição e saída da imagem, ambos já existentes no kit. Como pode ser visto na figura 20, o bloco mais escuro representa o módulo de processamento a ser desenvolvido.
Figura 20: Diagrama de Blocos da Proposta do Trabalho
3.2 PRINCIPAIS FERRAMENTAS UTILIZADAS
Nas duas primeiras fases, Concepção e Arquitetura, foi utilizada basicamente a IDE Netbeans 7.0, para confeccionar os modelos de casos de uso e classes do sistema.
Nas duas últimas fases, Implementação RTL e Prototipagem, foi utilizado as seguintes ferramentas de software:
• Quartus II Web Edition 9.0; foi utilizado para a codificação do protótipo, síntese do código em verilog e programação da FPGA.
• ModelSim Student Edition; foi utilizado para a implementação e execução da verificação funcional.
• Matlab R2009a; foi utilizado para implementar em software alto nível o algoritmo de detecção de borda com Sobel, servindo assim de parâmetro para o modelo de referência na verificação funcional.
4 RESULTADOS
Para um melhor entendimento, serão apresentados os principais resultados obtidos em cada etapa do desenvolvimento.
4.1 CONCEPÇÃO
Os principais resultados dessa fase são os requisitos do sistema e o diagrama de casos de uso. Os principais requisitos funcionais e não funcionais do sistema estão nas tabelas 1 e 2, respectivamente.
Tabela 1: Requisitos Funcionais do Sistema Classificação Requisito
Essencial Calcular a detecção de bordas em tempo real de vídeo proveniente de uma câmera
Importante O valor da borda deve ser o gradiente das direções horizontal e vertical
Desejável Possibilitar a visualização do vídeo em bordas ou escala de cinza
Tabela 2: Requisitos Não Funcionais do Sistema Requisitos
O processamento não pode afetar o frame rate da câmera O módulo de processamento não deve armazenar todo o frame
Para facilitar no gerenciamento e ajudar a determinar prioridades ao longo do projeto os requisitos funcionais foram classificados como pode ser visto na tabela 1 como:
• Essencial - O requisito deve ser implementado para o funcionamento do sistema;
• Importante - Sem esse requisito o sistema pode funcionar, mas não necessariamente da forma esperada;
• Desejável - O não atendimento do requisito não compromete o funcionamento do sistema.
Com base nos requisitos foi gerado o caso de uso da funcionalidade principal do sistema, como pode ser visto na figura 21.
Figura 21: Caso de Uso da Convolução.
4.2 ARQUITETURA
Com base na definição das funcionalidades definidas anteriormente chegou-se então nessa etapa à arquitetura final do sistema. Na figura 22 tem-se o diagrama de classes da funcionalidade definida no caso de uso da figura 21.
Figura 22: Diagrama de Classes da Convolução
A arquitetura geral do sistema está representada pelo diagrama de blocos na figura 23.
Figura 23: Arquitetura Final do Sistema.
Os três blocos em destaque na figura, BUFFER DA PROXIMA LINHA, CONVOLUÇÃO E CONTROLE, compõem o IP-Core desenvolvido, os outros blocos são fornecidos com o Kit DE2 da Altera. As setas preenchidas mostram o fluxo de dados, as não preenchidas mostram os sinais de controle mais importantes para o funcionamento. O fluxo que os dados percorrem é o seguinte:
1. O bloco DECODIFICADOR DE TV converte o sinal analógico em digital. Este sinal vem de uma câmera ligada na entrada RCA do kit respeitando o protocolo ITU-R 656 (UNION, 2008).
2. O decodificadorITU-R 656 extrai os valores YCbCr de cada pixel e os envia para um buffer.
3. O buffer que armazena temporariamente os pixels recem decodificados está representado pelo bloco SDRAM FRAME BUFFER, que é composto por uma memória SDRAM e um controlador que é responsável por fazer todo o controle de acesso e o refresh da mesma.
4. O bloco MUX serve para controlar e alternar entre as linhas pares e ímpares. Isso é necessário porque oITU-R 656 é entrelaçado.
5. O bloco YCbCr P/ RGB/CINZA converte o pixel para RGB e em seguida para escala de cinza com cada pixel representado por 10 bits. A parte de conversão para escala de cinza foi implementada, pois o bloco só convertia para RGB. 6. Finalmente o pixel em escala de cinza chega ao bloco BUFFER DA PROXIMA
LINHA, que é um estágio de preparação para a convolução, os detalhes desse processo serão explicados a frente.
7. O bloco CONVOLUÇÃO é o bloco responsável por processar o pixel, ou seja, efetua o calculo em si.
8. O bloco CONTROLE é provalvemente o mais importante no processo da detecção da borda, pois ele gera todos os sinais de controle para sincronizar o processamento com o fluxo de bits.
9. O bloco CONTROLADOR VGA recebe o pixel processado e envia para o decodificador D/A, representado pelo bloco VIDEO DAC 7123, além de gerar os sinais de sincronização horizontal e vertical para a saída no monitor.
4.2.1 Solução Aplicada na Implementação da Convolução
Para detectar as bordas no vídeo foi necessário implementar a convolução da máscara de Sobel sobre cada frame. O clock da convolução é o sinal de dado válido gerado pelo bloco ITU-R 656, indicando que tem um pixel válido na saída do bloco, a cada pulso desse sinal um pixel é processado. Assim, a quantidade de pixels processados por segundo pelo IP-Core fica limitado à taxa de atualização do padrão de vídeo, que no caso é de 60Hz.
Para satisfazer o requisito de um pixel processado por pulso foi pensado uma abordagem que só precisa de três linhas por vez do frame, e mais uma que será a próxima a entrar no cálculo da convolução. Dessa forma foram criados quatro bufers internos na FPGA usando um total de 640X 4X 10 = 26.500 bits: em paralelo, faz-se o cálculo do pixel atual e armazena-se o pixel da próxima linha que está chegando, pois o fluxo é contínuo. As figuras 24 e 25 ilustram a abordagem desenvolvida. Os buffers foram nomeados comolinha 1, linha 2 , linha 3 e linha 4. Assim, é necessário
controlar quais buffers estão sendo usadas para a convolução no momento e qual está armazenando a próxima linha.
Figura 24: Ilustração do Uso dos Buffers
Figura 25: Troca de Buffer em Uso na Convolução
No exemplo mostrado na figura 24 a linha 4 armazena o que será a próxima linha a entrar no cálculo, o que acontecerá quando a máscara de Sobel chegar ao fim da linha atual. Essa troca é mostrada na figura 25, a linha 4 agora está envolvida na convolução e a próxima linha será armazenado na linha 1. O controle dessas trocas está respresentado na máquina de estados da figura 26 que faz parte do bloco de CONTROLE, o qual informa ao bloco CONVOLUÇÃO quais linhas estão sendo usadas no momento. Um detalhe a ser observado no controle é a ordem que as linhas são lidas para a convolução, pois, esta influencia no resultado consequentimente a máquina de estados do controle deve defini-la corretamente.
Figura 26: Controle dos Buffers de Linhas
4.3 IMPLEMENTAÇÃO RTL
Com base no projeto descrito anteriormente, nessa etapa o IP-Core foi implementado em nível RTL. A implementação foi feita de forma incremental com a verificação funcional do IP-Core, ou seja, implementa, verifica, corrige, verifica, e assim sucessivamente até o componente satisfazer os requisitos definidos. Para isso, foi desenvolvido um plano de verificação com os casos de testes e todos os scripts necessários para automatizar os testes. Os resultados desse processo será detalhado nas seções a seguir.
4.3.1 Verificação Funcional
Para a verificação funcional foi iplementado o testbench com base no modelo explicado no capítulo 2.
4.3.1.1 Modelo de Referência
Para garantir a corretude do modelo de referência, primeiramente foi feito um script no software Matlab, por ser amplamente usado para cálculos matemáticos e processamento de imagem. O script lê uma imagem faz a detecção de bordas implementando a máscara de Sobel e escreve em um arquivo texto os valores dos
pixels processados, posteriormente foi implementado em linguagem Systemverilog e o resultado verificado através dos arquivos gerados.
4.3.1.2 Fonte
Para gerar os estímulos tanto para o modelo de referência quanto para o módulo(DUV), o bloco fonte lê um arquivo texto com os valores dos pixels de uma imagem e envia pixel a pixel para esses dois módulos.
4.3.1.3 Verificador
O script desenvolvido para checar o resultado da saída dos módulos de referência e do DUV monitora a saída dos módulos verificando os valores, ao final gera um relatório que indica a quantidade total de pixels testados e quantos estavam iguais em valores e em percentagem.
4.3.1.4 Casos de Teste
Com base nos requisitos foram definidos os casos de teste das tabelas 3 e 4 para a verificação.
Tabela 3: Teste Para Detectar Bordas em uma Imagem Nome do Caso de Teste Detectar Bordas em uma Imagem
Descrição Objetiva testar a corretude da implementação do algoritmo usando um único frame
Caso de Uso Relacionado Calcula G
Pré-Condição Deve haver um arquivo texto com os valores dos pixels da imagem em 640X480 na forma de matriz Pós-Condição Todos os pixels processados
Procedimento de Teste
1- Ler o arquivo texto contendo os pixels da imagem
2- Enviar pixel a pixel para o modelo de referência e DUV
3- Comparar a saída de ambos 4- Emitir relatório de acertos
Tabela 4: Teste Para Detectar Bordas em um Vídeo Nome do Caso de Teste Detectar Bordas em um Vídeo
Descrição Objetiva testar a corretude da implementação do algoritmo usando um vídeo. Tornando o teste mais próximo do real
Caso de Uso Relacionado Calcula G
Pré-Condição Deve haver um arquivo de vídeo em formato AVI de 640X480
Pós-Condição Todos os pixels processados
Procedimento de Teste
1- Ler o arquivo de vídeo usando o software Matlab 2-Enviar pixel a pixel para o modelode de referência e DUV
3- Comparar a saída de ambos 4- Emitir relatório de acertos
Para o caso de teste da tabela 3, foram usados arquivos de texto contendo 1,2,3 e 5 imagens em sequência. Os referidos arquivos texto foram gerados através de um script em Matlab que lê uma imagem e escreve os valores dos pixels no arquivo em
um formato de matriz semelhante à imagem. Veja na tabela 5 alguns resultados.
Tabela 5: Resultados do Caso de Teste da Tabela 3
NoFrames NoPixels Acertos Erros Taxa de acerto em (%)
1 307.202 305.284 1.918 99
2 614.402 610.564 3.838 99
3 921.602 915.844 5.758 99
5 1.536.002 1.526.404 9.598 99
A taxa de acerto em 99% se deve ao fato de não estar sendo feito o tratamento das bordas laterais da imagem no cálculo. O efeito disso é que as três colunas da esquerda e a última coluna da direita de cada frame tem seus valores diferentes do modelo de referência. Os valores são diferentes por que noDUV, escrito em Verilog, os valores armazenados nos buffers nesse momento são indefinidos e no modelo de referência, escrito em Systemverilog, são por default iguais a zero. Veja na tabela 5 que para um frame processado a quantidade de erros é aproximadamente igual a 4x480, para dois frames é igual a 4x480x2 e assim sucessivamente.
4.3.1.5 Resultado Final da Verificação Funcional
No decorrer dessa fase foram feitos várias modificações no DUV decorrentes de erros encontrados pela verificação funcional. Na figura 27 é possível visualizar a evolução do resultado durante o processo de verificação, na 27(a) é mostrado uma imagem processada pelo IP-Core em um momento intermediário do desenvolvimento e na figura 27(b) é possível ver a mesma imagem processada pela versão final. É visível a diferença na melhora do resultado na definição das bordas encontradas.
Essa evolução no resultado deve-se a mudanças feitas na implementação do IP-Core. As mais importantes foram:
• A latência na leitura da momória do buffer é de dois pulsos de clock, e estava sendo feita em apenas um pulso, isso causava uma leitura errada, deslocando um pixel no cálculo da convolução.
• O deslocamento da máscara de Sobel na direção horizontal estava sendo feito de forma errada, devido a um pequeno erro no contador do controlador. Dessa forma, a região da imagem que a máscara horizontal cobria era um pouco diferente da coberta pela máscara vertical, isso causava uma pequena diferença no valor do gradiente em relação ao modelo de referência.
• O módulo de controle estava utilizando dois contadores, um para cada máscara, depois percebeu-se que isso era desnecessário e passou-se a utilizar apenas um contador para ambos, eliminando qualquer probelma de sincronismo.
Figura 27: Evolução do Resultado com a Verificação Funcional
(a) Resultado Intermediário (b) Resultado Final
4.4 PROTOTIPAGEM
Nessa fase foi embarcado o código desenvolvido na FPGA do Kit de desenvolvimento DE2 da Altera. Como já explicado anteriormente, foi feito a integração com outros módulos fornecidos com o kit, podendo ser visto na prática o funcionamento do IP-Core. Na prototipagem também foi possível verificar o melhoramento possibilitado pela verificação. As figuras 28, 29 e 30 mostram a saída no monitor VGA de uma imagem em escala de cinza, uma versão intermediária prototipada e a versão final respectivamente. Tem-se ainda, na figura 31 a imagem do kit em funcionamento com a respectiva câmera e a conexão do cabo VGA, nos displays de sete segmentos está sendo mostrado o frame rate do vídeo em hexadecimal.
Figura 28: Imagem de Saída em Escala de Cinza
Figura 30: Imagem de Saída na Versão Final
Figura 31: Protótipo em Funcionamento no Kit
Na figura 32 é possível visualizar o bloco completo gerado pelo software Quartus II mostrando apenas os respectivos sinais de entrada e saída.
Figura 32: Bloco do Módulo Desenvolvido com os Sinais
A seguir uma breve descrição dos sinais. Os sinais de entrada são:
pixel_valido, sinal que vem do conversor analógico digital, informando que um pixel válido está no barramento.
pixel, é o barramento de 10 bits com o valor do pixel, em níveis de cinza.
limiar, é um barramento 10 bits onde pode ser informado um valor de limiar usado para binarizar a imagem. Pode ser usado em conjunto com um outro bloco que calcule automaticamente o limiar. É usado em combinação com os sinaisborda (desabilitado) ebinarizacao (habilitado).
reset, reinicia todo o bloco.
mostra_gray, com esse sinal ativo a imagem de saída será em níveis de cinza, se inativo será mostrado a imagem com as bordas detectadas.
clock_memoria, é o clock usado para os buffers de memória. No caso específico foi utilizada uma frequência de 100MHz.
clock_27 e clock_50, são os clocks de 27MHz e 50MHz usados no cálculo da convolução e no controle da máquina de estados, respectivamente.
O sinal de saída é:
pixel_convoluido, é a saída do pixel processado ou em escala de cinza, a depender do sinal de entrada mostra_gray.
5 CONSIDERAÇÕES FINAIS
A possibilidade de implementação de processamento de imagem em hardware permite inúmeras possibilidades de aplicação. O IP-Core desenvolvido nesse projeto implementa uma parte do passo referente a segmentação. No entanto, este fica pronto para ser acoplado a outros cores que implementam os outros passos do processamento a fim de chegar a um SoC que possa ser embarcado em um robô autônomo capaz de tomar decisões ou assistir outros sistemas.
Com o presente trabalho fica claro também, a importância da verificação na validação do IP-Core, de forma a garantir a qualidade do produto. Isso é essencial para garantir o bom funcionamento de um futuro sistema que irá utilizar o IP-Core. A verificação funcional possibilitou a correção de problemas imperceptíveis, caso fosse observando o vídeo de saída do sistema.
O trabalho possibilitou a vivência de todo o ciclo de vida do processo de desenvolvimento ipPROCESS. O que mostrou-se de fundamental importância para que o produto atendesse aos requisitos.
Contudo, é possível fazer melhoramentos no projeto, tais como:
• Modificar o cálculo para tratar as bordas laterais da imagem ou até mesmo desprezá-las no momento do cálculo, sem a necessidade de pulsos de clock extras;
• Desenvolver outros casos de teste mais dinâmicos que cubram uma quantidade maior de possibilidades, aumentando a confiaça no produto;
• Substituir a câmera analógica por uma digital, eliminando a etapa de conversão analógica/digital e consequentemente eventuais ruídos provenientes desse processo.
Por fim, é importante ressaltar que, ainda durante o desenvolvimento do projeto, foi publicado um artigo no Microeletronics Students Forum(MATOS; SOUZA; DIAS, 2011) e outro está em desenvolvimento para ser submetido ao Multi Conference on Computer Science and Information Systems 2012.
REFERÊNCIAS
ALTERA.DE2 Development and Education Board: User Manual. 2006. Disponível em: <www.terasic.com.tw/cgi-bin/page/archive_download.pl?Language=EnglishNo=3 0FID=ab73908ea64e51be175534c8101942b7>. Acesso em: 11 dez. 2011.
BERGERON, J.Writing Testbenches: Functional Verification of HDL Models. 2. ed. Norwell, MA, USA: Kluwer Academic, 2003.
BOOCH, G.; RUMBAUGH, J.; JACOBSON, I.UML : guia do usuario. 1. ed. Rio de Janeiro-RJ: Campus, 2000.
BRANCO, F. C. et al. Uso de ferramentas e metodologias no projeto de um sistema digital. Trabalho não publicado. 2010.
BRAZIL-IP.Site do BRAZIL-IP. 2008. Disponível em: <www.brazilip.org.br>. Acesso em: 31 ago. 2011.
GONZALEZ, R. C. Processamento digital de imagens. 3. ed. São Paulo, SP: Pearson Prentice Hall, 2010.
KILTS, S. Advanced FPGA Design: Architecture, Impementation and Optimization. 1. ed. [S.l.]: New Jersey, 2007.
KRUCHTEN, P.The Rational Unified Process: An Introduction. 3. ed. Boston: Pearson Education, 2003.
LIMA, M. et al. ipprocess: A development process for soft ip-core with prototyping in fpga.International Conference on Microelectronic Systems, p. 1–2, 2005.
MATOS, J. M. A. de; SOUZA, F. A. de; DIAS, A. M. Designing an ip-core for edge detection in monochrome image using the sobel operator.Microelectronics Students Forum, p. 1–4, 2011.
OPPENHEIM, A. V.; WILLSKY, A. S.; NAWAB, S. H.Signals & System. 2. ed. Upper Saddle River, New Jersey: Prentice Hall, 1997. ISBN 0-13-814757-4.
PRATT, W. R.Digital image processing. 4. ed. New York: John Wiley e Sons, 2007. SALEH., R. et al. System-on-chip: Reuse and integration.Proceedings of the IEEE, v. 94, n. 6, p. 1050–1069, 2006.
SILVA, K. R. G. da.Uma Metodologia de Verificação Funcional para Circuitos Digitais. Tese (Doutorado) — Universidade Federal de Campina Grande, Campina Grande - PB, 2007.
UNICAMP.Fundamentos de Processamento de Imagem Digital. 2003. Disponível em: <http://www.ic.unicamp.br/ cpg/material-didatico/mo815/9802/curso/>. Acesso em: 03 set. 2011.
UNION, I. T. International Telecommunication Union. 2008. Disponível em: <http://www.itu.int/ITU-R/index.asp>. Acesso em: 14 jan. 2012.
