Escolar Documentos
Profissional Documentos
Cultura Documentos
Por
Dissertação de Mestrado
RECIFE, SETEMBRO/2013
UNIVERSIDADE FEDERAL DE PERNAMBUCO
CENTRO DE INFORMÁTICA
PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO
RECIFE, SETEMBRO/2013
Catalogação na fonte
Bibliotecária Jane Souto Maior, CRB4-571
______________________________________________
Prof. Abel Guilhermino da Silva Filho
Centro de Informática / UFPE
______________________________________________
Prof. João Marcelo Natario Teixeira
Departamento de Estatística e Informática / UFRPE
_______________________________________________
Prof. Cristiano Coêlho de Araújo
Centro de Informática / UFPE
___________________________________________________
Profa. Edna Natividade da Silva Barros
Coordenadora da Pós-Graduação em Ciência da Computação do
Centro de Informática da Universidade Federal de Pernambuco.
Dedico este trabalho,
especialmente ao meu pai,a minha mãe,
a toda minha família e aos meus amigos
por todo carinho, compreensão, incentivo.
AGRADECIMENTOS
Aos professores Tsang Ing Ren, Edna Barros, Ricardo Massa, Paulo Maciel e pelos
conhecimentos repassados, especial a Abel Guilhermino e João Marcelo Natario que
apesar de tudo, concordaram em participar da Banca Examinadora e tiveram muita
paciência, atenção e compreenção , meus sinceros muito obrigado.
Aos meus Pais (Luis Carlos da Silva e Maria Cristina Ferreira) e Familiares pelo apoio
em toda minha trajetória.
A todos meus amigos e amigas que me apoiaram nos momentos mais difíceis.
Aos meus amigos do grupo de estudo Paulo Guedes, Zílcio Sales, Marília Lima e
Wilson Gondim que me ajudaram na pesquisa e desenvolvimento deste trabalho.
A Deus por todos os dias da minha vida, pela saúde, paz, amor, família e tudo mais que
Ele me proporcionou.
“Ninguém abre um livro sem que se aprenda alguma coisa”
(Anônimo)
RESUMO
This dissertation introduces a new tool for high level synthesis called SynMaker that
receives as input a high level code written in Object Oriented Java or SystemVerilog
and generates RTL code that can be synthesized for a target board prototyping. The
RTL code generation takes into account the characteristics of object-oriented code such
as classes, abstraction, encapsulation and some restrictions concerning polymorphism,
inheritance, use of constructors among others specified in this work and, finally,
integrates the result with a platform FPGA that includes a camera and a display for
displaying the results. The design flow implemented in SynMaker is specially designed
for applications in image processing and video. One advantage of this approach is that it
completely abstracts the flow of the Quartus II tool, the designer describes the
application of image processing in a high-level language for object orientation, using a
library of platform components and generates code for the Platform development
Terasic DE2-70. This development platform includes a digital camera and display, is an
ideal platform for prototyping applications of image processing filters and video. In its
current state the SynMaker can perform a high-level synthesis in a simplified form,
performing a direct mapping of an AST (Abstract Syntax Tree) to RTL code. The
experimental results for the synthesis of the image processing filters are shown, and
demonstrate the effectiveness of operation of the proposed synthesis tool.
Figura 1. Convenção dos eixos para representação de imagens digitais [24]. ............... 15
Figura 2. Passos fundamentais em processamento de imagens digitais [24]. ................ 17
Figura 3. O Universo dos ASICs. ................................................................................... 19
Figura 4. Seqüência de projeto ASICs. .......................................................................... 19
Figura 5. Representação dos elementos básicos de um FPGA. ...................................... 22
Figura 6. Arquitetura interna de circuitos programáveis FPGA. .................................... 22
Figura 7. Processo de projeto de circuitos. ..................................................................... 25
Figura 8. Diagrama-Y segundo GAJSKI [22]. ............................................................... 26
Figura 9. Processo de síntese no diagrama-Y. ................................................................ 28
Figura 10. Metodologia manual de design de sistema.................................................... 29
Figura 11. Fluxo de projeto RTL. ................................................................................... 31
Figura 12. Desafios do projeto para 65nm e abaixo. ...................................................... 32
Figura 13. Fluxo de síntese de alto nível. ....................................................................... 33
Figura 14. Curva de aprendizagem. ................................................................................ 34
Figura 15. Um benefício da automação: exploração. ..................................................... 34
Figura 16. Entrada e saída do JavaCC. ........................................................................... 36
Figura 17. Compilando o parser gerado pelo JavaCC e usando-o para obter a AST. .... 36
Figura 18. Metodologia de projeto de hardware SystemC. ............................................ 42
Figura 19. Fluxo básico do Impulse C. ........................................................................... 45
Figura 20. Visão global do funcionamento .................................................................... 48
Figura 21. Visão RTL de parte do projeto base utilizado pelo SynMaker. (a) Projeto
base padrão. (b) Projeto Base alterado pelo SynMaker após a síntese. .......................... 49
Figura 22. Fluxograma de síntese do SynMaker. ........................................................... 51
Figura 23. Fluxo de pré-compilação do SynMaker ........................................................ 53
Figura 24. Tela de Simulação. (a) Vídeo de entrada. (b) Vídeo de saída. ...................... 54
Figura 25. Fluxo de otimização. ..................................................................................... 55
Figura 26. Exemplo de código SystemVerilog gerado pela síntese. .............................. 56
Figura 27. Metodologia de síntese do SynMaker para classe, função e sua respectiva
interface RTL.................................................................................................................. 57
Figura 28. Visão geral da metodologia de síntese de alto nível do SynMaker. ............. 58
Figura 29. Seqüência de comandos executados pelo Quartus. ....................................... 59
Figura 30. Arquitetura SynMaker................................................................................... 61
Figura 31. Placa de desenvolvimento Altera D2-70. ...................................................... 64
Figura 32. Estrutura de componentes e comunicação da placa D2-70. .......................... 64
Figura 33. Placa TRDB-D5M......................................................................................... 65
Figura 34. Placa TRDB-LTH. ........................................................................................ 65
Figura 35. Dispositivo FPGA EP2C70F896C6. ............................................................. 66
Figura 36. Estrutura interna do FPGA EP2C70F896C6................................................. 67
Figura 37. Altera DE2-70 Digital Camera Development Platform. (a) Projeto Base. (b)
Projeto base alterado pelo SynMaker com o filtro de sobel. .......................................... 69
LISTA DE TABELAS
1 INTRODUÇÃO .................................................................................................... 13
2 DISCUSSÃO TEÓRICA...................................................................................... 15
2.1 PROCESSAMENTO DIGITAL DE IMAGEM ................................................. 15
2.1.1. Imagem digital ............................................................................................ 15
2.1.2. Passos fundamentais utilizados no processamento de imagens ................. 16
2.2 SISTEMAS DIGITAIS ....................................................................................... 17
2.2.1. Circuitos lógicos programáveis em campo ................................................ 20
2.3 FPGA .................................................................................................................. 21
2.3.1. Elementos básicos de um FPGA................................................................. 21
2.3.2. Estrutura interna ........................................................................................ 22
2.3.3. Aplicações com FPGA ................................................................................ 23
2.3.4. Ferramentas CAE de síntese ...................................................................... 24
2.4 SÍNTESE NO CONTEXTO DE PROJETO DE CIRCUITOS ........................... 25
2.4.1. Fluxo de projeto de circuitos digitais ......................................................... 25
2.4.2. Domínios de representação ........................................................................ 26
2.4.3. Níveis de abstração .................................................................................... 27
2.5 METODOLOGIA MANUAL DE PROJETO DE CIRCUITO .......................... 28
2.6 SÍNTESE DE ALTO NÍVEL .............................................................................. 30
2.7 JAVA PARSER .................................................................................................. 35
2.7.1. JAVACC ...................................................................................................... 35
2.8 REPRESENTAÇÃO INTERMEDIÁRIA E EXTRAÇÃO DE INFORMAÇÃO
(DIAGRAMA) ........................................................................................................... 36
2.8.1. Árvore sintática abstrata (AST).................................................................. 37
2.8.2. Análise léxica e sintática ............................................................................ 37
2.8.3. Análise de fluxo de controle ....................................................................... 38
2.8.1. Análise de fluxo de dados ........................................................................... 38
2.8.2. Grafo de fluxo de controle e dados ............................................................ 39
3 REVISÃO DA LITERATURA ........................................................................... 40
3.1 TRABALHOS RELACIONADOS .................................................................... 40
3.2 FERRAMENTAS DE SÍNTESE DE ALTO NÍVEL.......................................... 40
3.2.1. Systemc ....................................................................................................... 41
3.2.2. Catapult C .................................................................................................. 43
3.2.3. Impulse C .................................................................................................... 44
3.2.4. Análise comparativa ................................................................................... 45
4 FERRAMENTA DE SÍNTESE: SYNMAKER ................................................. 47
4.1 ARQUITETURA ALVO DO SYNMAKER ...................................................... 48
4.2 FLUXO E MODELAGEM DO SISTEMA ........................................................ 49
4.2.1. Descrição comportamental ........................................................................ 51
4.2.2. Processador de comandos de síntese ......................................................... 52
4.2.1. Pré-compilador HLS .................................................................................. 53
4.2.2. Simulação ................................................................................................... 53
4.2.3. Compilador HLS ......................................................................................... 54
4.2.4. Síntese de alto nível .................................................................................... 55
4.2.5. Gerador RTL .............................................................................................. 58
4.2.6. Plataforma FPGA ....................................................................................... 59
4.3 ARQUITETURA DO SYNMAKER .................................................................. 60
5 EXPERIMENTOS E TESTES DE VALIDAÇÃO ............................................ 62
5.1 AMBIENTE ....................................................................................................... 62
5.1.1. Requisitos e instalação ............................................................................... 62
5.1.2. Terasic DE2-70 .......................................................................................... 63
5.1.3. O FPGA EP2C70: Circuito lógico reconfigurável .................................... 66
5.2 EXECUÇÃO ...................................................................................................... 67
5.3 ANÁLISE E INTERPRETAÇÃO ...................................................................... 69
6 CONSIDERAÇÕES FINAIS ............................................................................... 71
6.1 CONTRIBUIÇÕES ............................................................................................ 71
6.2 TRABALHOS FUTUROS ................................................................................. 71
REFERÊNCIAS ........................................................................................................... 72
7 ANEXO .................................................................................................................. 76
1 INTRODUÇÃO
13
aplicações de processamento digital de imagem esta placa FPGA faz parte da Altera
Digital Camera Development Platform, que proporciona ao desenvolvedor acesso e
fácil manipulação a dados e alta qualidade de imagens. Devido a isso o Java foi
escolhido como a linguagem de entrada para ferramenta de síntese e a plataforma para
exibição do resultado final.
Existem muitas ferramentas HLS, mas nenhuma delas é capaz de fazer síntese de
alto nível de um programa Java ou SystemVerilog com nicho em aplicação de
processamento de imagem digital para trabalhar em uma placa Terasic DE2-70 com
uma plataforma de Desenvolvimento de Câmera Digital.
Como pode ser visto, por um lado, há uma falta de metodologia e ferramentas
para programadores de software mais familiarizados com o Java para projetar para uma
plataforma de hardware. Por outro lado, os designers de SystemVerilog são obrigados a
trabalhar no nível RTL para a síntese, aumentando o seu esforço de projeto, tempo e
erros.
Sendo assim, neste trabalho é apresentada uma ferramenta que recebe como
entrada um código de processamento de imagem orientado a objeto, e o mesmo é
sintetizado até seu funcionamento na plataforma de vídeo e câmera da placa DE2-70 da
Altera. Esta ferramenta, chamada SynMaker, é capaz de sintetizar algoritmos de
processamento de imagem desenvolvidos em Java ou SystemVerilog, gerando uma
descrição de hardware que pode ser automaticamente programada na plataforma de
desenvolvimento de Câmera Digital da Altera. Como resultado, é aumentada a
produtividade dos usuários de FPGA atuais, que desejam fazer aplicações específicas de
processamento de imagens aplicadas em plataforma FPGA ou apenas gerar descrição
RTL que pode ser utilizada em outro projeto que o designer desejar.
A contribuição deste trabalho é uma nova ferramenta projetada para realizar a
síntese de alto nível aplicada a algoritmos baseados em FPGA para processamento
digital de imagens utilizando como entrada código Java ou SystemVerilog com algumas
restrições sobre o uso da linguagem, como o uso de a polimorfismo, herança e
utilização de construtores. Além disso, esta ferramenta contém um novo parser
SystemVerilog e uma nova representação intermediária chamada Generic Abstract
Sintax Tree ( GAST) para unificar diferentes árvores de sintaxe abstratas geradas por
diferentes parsers.
Esta dissertação descreve o projeto e desenvolvimento de uma ferramenta para
realização de síntese de alto nível. Ao final do projeto, a ferramenta deverá ser capaz de
receber uma descrição do comportamento do sistema em diferentes linguagens de
descrição (Java e SystemVerilog), realizar algumas otimizações, gerar como saída um
conjunto de arquivos e um projeto do sistema descrito em uma linguagem de descrição
de hardware. Este conjunto de saída poderá então ser processado por uma ferramenta de
prototipação rápida, para compilação e síntese em uma determinada plataforma-alvo.
Em particular, no escopo desta dissertação deverá ser possível sintetizar, realizar síntese
RTL de sistemas para a plataforma Terasic DE2-70 [38].
O resto da dissertação está organizado nos seguintes capítulos. O capítulo de
discussão teórica envolve todo conhecimento necessário que o usuário precisa ter sobre
o tema que consiste desde o básico sobre o FPGA até síntese de alto nível. O capítulo de
revisão da literatura discute os trabalhos relacionados à síntese de alto nível em FPGA e
algumas ferramentas que estão presentes em trabalhos acadêmicos ou no mercado. O
capítulo SynMaker apresenta a ferramenta desenvolvida. O capítulo Experimentos
apresenta como foram executados os experimentos e a análise dos resultados da síntese,
e por fim, o capítulo de considerações finais demonstra uma conclusão de tudo que foi
desenvolvido e aprendido com o trabalho e o que poderá ser feito no futuro.
14
2 DISCUSSÃO TEÓRICA
Uma imagem digital pode ser definida como uma função bidimensional, f(x, y), em
que x e y são coordenadas espaciais, e a amplitude de f, em qualquer par de coordenadas (x,
y) é chamada de intensidade também denominada de nível de cinza da imagem no
determinado ponto. Quando x e y e os valores da amplitude de f são todos finitos,
quantidades discretas, a imagem é chamada de imagem digital. A área de processamento
digital de imagens refere-se ao processamento de imagens por meio de um computador
digital.
A imagem na Figura 1 pode ser representada por uma função bidimensional de f(x,
y), onde x e y indicam as coordenadas espaciais e f(x, y) indica a intensidade do nível de
cinza da imagem na dada coordenada (x, y).
15
A imagem digital é uma imagem f(x, y) discretizada, tanto em coordenadas espaciais
quanto em brilho, e pode ser representada computacionalmente como uma matriz MxN,
onde o cruzamento de linha com coluna indica um ponto na imagem, e o valor contido
naquele ponto indica a intensidade de brilho, ou seja, o nível de cinza contido naquele
ponto. Os pontos em uma imagem são chamados de pixels (“Picture Elements”).
A Matriz 1 abaixo representa um exemplo de um formato descritivo de uma
imagem digital.
16
Representação e descrição: no processo de representação, as
características principais devem ser enfatizadas e extraídas. O processo
de descrição é também conhecido como seleção de características, onde
são extraídas as características principais que resultam em informação
quantitativa, capaz de separar classes de objetos importantes para o
reconhecimento dos padrões.
Reconhecimento e interpretação: consiste em atribuir rótulos aos objetos,
classificando-os a partir das informações encontradas na imagem na
etapa anterior. Esta etapa tenta aproximar o desempenho computacional
ao do ser humano ao reconhecer padrões dentro de uma imagem.
17
Maior segurança de projeto.
Redução de Custos.
Menor tamanho físico.
Para atender estas vantagens hoje temos diversas tecnologias comercialmente que são:
Bipolares em Silício.
Unipolares utilizando a tecnologia MOS em Silício.
Semicondutores compostos tipo III-V como: (GAAS, LNP, etc.).
Cada uma destas tecnologias apresenta vantagens e desvantagens em relação às
outras em função da aplicação específica. Uma das tecnologias que tem se destacado
muito no mercado e a tecnologia CMOS (Complementary Metal Oxide Semiconductor),
estes transistores tem a vantagem de usar quase nenhuma energia quando não é preciso.
Os Circuitos integrados ainda podem ser classificados de acordo com
seu processo de fabricação:
1. Circuitos integrados monolíticos: Os elementos do circuito (diodos, transistores,
resistências, condensadores, indutâncias, etc.) são criados essencialmente na
massa e à superfície de um material semicondutor (por exemplo, silício
impurificado (dopado), arsenieto de gálio, silício-germânio, fosfeto de índio),
formando um todo indissociável.
2. Circuitos integrados híbridos: Reúnem de maneira praticamente indissociável,
por interconexões ou cabos de ligação, sobre um mesmo substrato isolante
(vidro, cerâmica, etc.) elementos passivos (resistências, condensadores,
indutâncias, etc.) obtidos pela tecnologia dos circuitos de camada fina ou
espessa e elementos ativos (diodos, transistores, circuitos integrados
monolíticos, etc.), obtidos pela tecnologia dos semicondutores. Estes circuitos
podem incluir também componentes discretos.
3. Circuitos integrados de múltiplos chips: Constituídos por dois ou mais circuitos
integrados monolíticos interconectados, combinados de maneira praticamente
indissociável, dispostos ou não sobre um ou mais substratos isolantes, mesmo
com elementos de conexão, mas sem outros elementos de circuito ativos ou
passivos.
18
camadas utilizando uma biblioteca que incorpora estruturas de circuitos pré-
caracterizadas.
Full Custom - É um circuito monolítico que pode ser projetado "manualmente",
desde o início.
Onde se pode concluir que o tipo de ASIC mais versátil e com maior capacidade
de integração (Densidade) é o Full-Custom, mas também tem um elevado custo de
desenvolvimento, demora muito tempo para chegar até o mercado e risco de não
funcionar corretamente devido a sua complexidade (Imagine um processador com 9
milhões de transistores).
19
Para projetarem-se circuitos integrados deve-se primeiramente especificar o
projeto a ser executado conforme mostra a Figura 4. Com base nas especificações do
projeto devemos escolher qual tipo de ASICs atende melhor as especificações do
projeto. E finalmente, a ferramenta de CAD apropriada. O FPGA foi escolhido para ser
utilizado nessa dissertação por ser um intermediário entre custo de desenvolvimento e
versatilidade.
20
Possibilidade de desenvolvimento conjunto de hardware e software, sem
interdependências, de modo a aumentar a velocidade com que o produto
final chega à linha de produção.
2.3 FPGA
21
Figura 5. Representação dos elementos básicos de um FPGA.
Nos últimos anos a quantidade de portas lógicas disponíveis num FPGA tem
crescido num ritmo muitíssimo acelerado, possibilitando a implementação de
arquiteturas cada vez mais complexas. Isto permite a implementação não apenas de
protótipos, mas de produtos finais complexos baseados em FPGA’s.
22
A arquitetura sea-of-gates é um circuito composto por transistores ou blocos
lógicos de baixa complexidade. A vantagem dessa arquitetura é a grande
disponibilidade de portas lógicas por área. Porém, como não há uma área dedicada para
o roteamento, é necessário que o mesmo seja feito sobre as células, muitas vezes
inutilizando áreas disponíveis para implementação de uma determinada lógica.
Nos circuitos de arquitetura row-base dos blocos lógicos estão dispostos
horizontalmente. Existe uma área dedicada de roteamento localizada entre as linhas de
blocos lógicos. As arquiteturas row-base de sea-of-gates originaram-se das
metodologias de projeto de ASICs, standard-cells e gate-array.
A arquitetura tipo PLD hierárquico é constituída por uma matriz de blocos
lógicos, denominados logic arrays blocks, sendo interligados através do recurso de
roteamento conhecido como matriz programável de interconexão (PIA). Esse tipo de
dispositivo é dito hierárquico, porque os blocos lógicos podem ser agrupados entre si. A
arquitetura tipo matriz simétrica é flexível no roteamento, pois possui canais verticais e
horizontais.
23
2.3.4. FERRAMENTAS CAE DE SÍNTESE
24
2.4 SÍNTESE NO CONTEXTO DE PROJETO DE CIRCUITOS
A área de projeto de circuitos digitais tem sido o foco de uma grande quantidade
de pesquisa, abordando vários aspectos de fluxo de projeto. Nesta seção serão
apresentadas etapas do projeto de circuitos digitais, isto é, as etapas de modelagem,
síntese e verificação, destacando importantes definições.
25
A saída consiste da implementação final, que resulta da integração heterogênea
de arquiteturas realizada na etapa de síntese. Existem três etapas principais na estratégia
de projeto: modelagem, síntese e validação [20]. Pela modelagem, a especificação
inicial é transformada numa representação interna do projeto, a qual é manipulada
seguidamente pelas tarefas de síntese e validação.
Dentro do contexto do fluxo de projeto introduzido na Figura 7, os elementos
abstratos da Representação Interna (RI) são misturados com a biblioteca da tecnologia,
e com a tarefa de síntese produz uma implementação final do circuito digital, em forma
de hardware/software [1], que satisfaz todos os requisitos. O processo moderno de
síntese é realizado de maneira automática ou semiautomática, usando-se ferramentas de
CAE, e está inserido, atualmente, na abordagem top-down. Visto que o processo de
síntese tem como alicerce a RI usada, ele depende fortemente das características do
modelo abstrato adotado.
Pela validação, o projetista consegue garantir que a funcionalidade de sua
implementação está correta. Tal garantia pode evitar o consumo de tempo na depuração
em níveis inferiores de abstração e na interação para os altos níveis de abstração. A
simulação é o método mais comum de teste da funcionalidade do sistema, ainda que a
utilização de técnicas de verificação formal está crescendo em adoção [42].
26
Existem três domínios de descrição: domínio comportamental, domínio
estrutural e domínio físico. A descrição do projeto pode ser realizada em cada um
desses domínios ou ter partes em diferentes domínios.
No domínio comportamental o projeto é descrito pela funcionalidade desejada
do sistema, definida como uma composição de entidades funcionais abstratas. Os
objetos comportamentais são as peças de funcionalidade e são responsáveis por
processar dados de entrada e produzir dados da saída. Em geral descrições
comportamentais são usadas para modelar os dados e as dependências de controle entre
eles, fazendo transformações funcionais.
No domínio estrutural, a estrutura lógica é descrita freqüentemente como a
interconexão estrutural de um conjunto de blocos abstratos. É o ponto intermediário
entre os domínios comportamental e físico. Os objetos estruturais representam, por
exemplo, modelos de componentes reais ou barramentos que estão processando dado o
tempo todo.
O domínio físico representa a implementação física do projeto, ou a realização
dos componentes estruturais abstratos do domínio estrutural, incluindo também o
posicionamento dos blocos abstratos no plano físico do sistema.
Seguindo o que foi descrito acima, a ferramenta de síntese produzida neste
trabalho é responsável por sintetizar um código que está inicialmente em um domínio
comportamental para um domínio estrutural.
27
No nível de sistemas, as descrições são de um sistema genérico onde os seus
componentes de hardware e softwares podem estar ainda indefinidos, sendo que a
implementação final pode resultar em componentes apenas de cada um dos tipos ou
ambos. A partir do nível algorítmico até os níveis mais baixos da hierarquia as
atividades de projeto tratam de descrições puramente de hardware.
No diagrama-Y, cada ponto indica um modelo diferente de representação. De
acordo com isso é possível dizer que um modelo é definido pelo grau de detalhamento
da descrição do projeto no ponto considerado. O próprio projeto ou o fluxo de projeto
também pode ser observado no diagrama-Y, como o processo de síntese exemplificado
na Figura 9 [4]. Neste caso, no nível de sistemas, a síntese consiste no processo de
derivar uma descrição estrutural do sistema - arquitetura do sistema – composta de
componentes de hardware e software (processadores) a partir de uma descrição
puramente comportamental do sistema, uma especificação do sistema que pode ser em
uma linguagem natural, não sintetizável. Esse processo também é conhecido como
síntese arquitetural ou co-projeto hardware-software, neste nível é onde esta inserida a
proposta desse trabalho.
28
Com a metodologia manual, o designer cria o modelo em alto nível, verifica-se o
modelo funciona como o esperado, e traduz o projeto manualmente em uma HDL. Este
processo é muito tedioso e propenso a erros.
Os testes que são criados para validar a funcionalidade do modelo de alto nível
normalmente não podem ser executados contra o modelo de HDL sem conversão. Não
só o designer tem que converter o modelo de alto nível para HDL, mas o conjunto de
teste tem de ser convertido para o ambiente HDL também.
Para as partes do modelo original serem implementadas em software, o modelo
muitas vezes deve ser reescrito com chamadas para um RTOS ( Real-time operating
system). O modelo é o simulado e verificado com um RTOS emulador. Embora as
partes do código original possam ser reutilizadas, a mudança na abstração do modelo
original, para um modelo baseado em RTOS requer significativa recodificação e
verificando as alterações manuais torna-se um problema significativo.
29
2.6 SÍNTESE DE ALTO NÍVEL
30
A capacidade de explorar um espaço de projeto muito maior. Uma técnica de
síntese eficiente pode produzir várias implementações a partir da mesma
especificação em um curto período de tempo. Isso permite que o designer possa
explorar diferentes trade-offs entre custo, desempenho, consumo de energia,
testabilidade e etc.
Suporte para verificação do projeto. Um pré-requisito para automatizar o
processo de co-projeto de hardware / software, por exemplo, é iniciar o processo
de síntese com uma especificação conjunta de ambos, hardware e software, este
torna possível verificar completamente a consistência do projeto, consistindo em
componentes de hardware e processos de software.
Menos erros. A redução das atividades de concepção manuais significa que o
número de erros humanos será diminuído, se os algoritmos de síntese podem ser
validados. Pode-se ter mais confiança de que o projeto final será corretamente
implementado seguindo a especificação dada.
Aumento do acesso à tecnologia de circuitos integrados. Quanto mais alto o
nível de abstração pode ser capturado e sintetizado automaticamente, mais fácil
para as pessoas que não são especialistas em tecnologia CI’s para projetar chips.
31
A diferença entre a produtividade por designer e por ano e o aumento da
complexidade do SoC, mesmo tendo em conta um número muito conservador de portas
por melhoria de tecnologia, irá ocorrer uma explosão da mão de obra para SoCs para
melhorias de nanotecnologia futuras como mostra a Figura 12.
32
Figura 13. Fluxo de síntese de alto nível.
33
Figura 14. Curva de aprendizagem.
34
A Capacidade das ferramentas de HLS é outro parâmetro a ser reforçado, mesmo
que as ferramentas tenham progredido muito nos últimos anos. A bem conhecida Lei de
Moore existe e ainda as ferramentas tem que seguir a capacidade de integração das
indústrias de semicondutores.
2.7.1. JAVACC
JavaCC (Java Compiler Compiler) é o gerador de parser mais popular para uso
com aplicações construídas em Java [39]. É uma ferramenta que lê uma especificação
de gramática e a converte para um programa Java que pode reconhecer uma descrição
que corresponde à gramática de acordo com a especificação definida pelo criador da
gramática.
JavaCC foi lançado pela Sun com o nome JACK. A última versão foi lançada
pela Metamata Inc. Web Gain1 foi a empresa zeladora dele por um tempo. Atualmente,
JavaCC pode ser obtido a partir da Web a partir do site da Sun Micro system2. Além do
próprio gerador de parser, JavaCC fornece outras capacidades normais relacionadas à
1
http://www.webgain.com
2
http://javacc.dev.java.net/
35
geração de parsers, tais como construção de árvore (via uma ferramenta chamada
JJTree), as ações, depuração e etc. JavaCC não possui bibliotecas de tempo de execução
(como arquivos JAR). Os únicos arquivos que são necessários para o parser são aqueles
gerados pelo JavaCC.
JavaCC é capaz de ler uma descrição de uma linguagem (a gramática) e gerar o
código, escrito em Java, que irá ler e analisar essa linguagem. JavaCC é particularmente
útil quando você tem que escrever código para lidar com uma linguagem de entrada que
tem uma estrutura complexa. Neste caso, elaborar manualmente um módulo de entrada,
sem a ajuda de um gerador de analisador pode ser uma tarefa difícil.
O analisador léxico do parser JavaCC gerado tem um recurso para manter
comentários quando eles são definidos como tokens especiais. Símbolos especiais são
ignorados durante a análise, mas estes tokens estão disponíveis (ao contrário de itens
ignorados, como espaços em branco) para o processamento pelas ferramentas.
Na Figura 16, a entrada é composta de uma descrição da especificação da
gramática da linguagem que é salva em um arquivo com extensão .jj. Uma vez
processados se tem como saída os arquivos Java que tem o código do parser que pode
processar a linguagem que está de acordo com a gramática no processo de
especificação. Estes arquivos Java, quando são compilados, geram um compilador para
a gramática que foi especificada.
Uma vez que o código do parser é gerado, ele é compilado com o compilador
Java (javac) para obter o parser. O código de resultado é usado para analisar a gramática
desejada, veja a Figura 17.
Figura 17. Compilando o parser gerado pelo JavaCC e usando-o para obter a AST.
Nesta seção, apresentamos alguns modelos que usam técnicas para a extração de
informações a partir do código fonte. Uma representação intermediária (RI) é uma
estrutura de dados, geralmente construída a partir de uma descrição de um programa ou
36
sistema, dada na sua respectiva linguagem, que captura parcial ou completamente os
detalhes da informação presente nessa descrição. Por exemplo, no contexto de síntese
de alto nível (High Level Synthesis, HLS), existe o conceito de representação
intermediária canônica [26] para a qual são mapeados os objetos e a semântica de um ou
vários modelo abstratos, como, por exemplo, um CFG (Control Flow Graph), DFG
(Data Flow Graph) ou um CDFG (Control Data Flow Graph).
As RIs são criadas com o objetivo de manipular os dados do sistema, extraindo-
os e alterando-os ou, então realizando medições e estimativas. As RIs podem ser obtidas
tanto por conversão, a partir das linguagens de especificação, ou como resultado de
tarefas realizadas por ferramentas de auxílio de projeto (CAD). Como as RIs são
construções utilizadas por outros programas, elas diferenciam-se das linguagens de
especificação pela inexistência de um conjunto de elementos léxicos com regras
sintáticas e semânticas. Uma RI permite uma exploração do espaço de soluções entre as
possíveis implementações de um projeto; isto significa que ao escolher uma RI
apropriada, pode-se facilitar o uso de diversas ferramentas para os processos
subsequentes.
O problema de extração de conhecimento do código do aplicativo foi
investigado em diversas áreas de pesquisa, como a análise léxica e sintática, análise de
fluxo de controle e dados, que serão detalhados nas próximas seções. Estas
representações, ao exibirem explicitamente o paralelismo ao nível da operação, entre
blocos básicos e entre ciclos considerando sempre a granulosidade da operação,
permitem a exploração eficiente de implementações em hardware específico.
Análise do código fonte requer a conversão para uma forma que pode ser
facilmente processada por um programa. Uma árvore sintática abstrata (AST) é um tipo
de representação de código-fonte que facilita o uso de árvores para a passagem
algoritmos. Análise léxica e sintática de um código fonte, de acordo com a gramática
livre de contexto da linguagem, gera uma AST. Gramáticas próprias são descritas numa
37
notação estilizada chamada Backus-Naur [16], em que as partes do programa são
definidas por normas e, em termos dos seus constituintes. Uma AST é usada para
mostrar como uma sentença em linguagem natural é dividida em seus componentes. O
parser que é gerado pela ferramenta JavaCC produz AST a partir de um código fonte.
Após a AST ser produzida, ela está pronta para ser analisada.
38
2.8.5. GRAFO DE FLUXO DE CONTROLE E DADOS
39
3 REVISÃO DA LITERATURA
40
3.2.1. SYSTEMC
SystemC é uma biblioteca de classes C++ que pode ser utilizada em conjunto
com uma metodologia para a criação de um modelo de ciclo de precisão dos algoritmos
de software, arquitetura de hardware, e interfaces de SoC (System On a Chip) e projetos
de nível de sistema.Uma das principais características de SystemC é que ela pode ser
utilizada em conjunto com ferramentas de desenvolvimento padrão C++ para se criar
um modelo de nível de sistema, simular rapidamente para validar e otimizar o design,
explorar vários algoritmos, e fornecer a equipe de desenvolvimento de hardware e
software uma especificação executável do sistema. Uma especificação executável é,
essencialmente, um programa em C++ que apresenta o mesmo comportamento que o
sistema quando executado.
A biblioteca de classes SystemC fornece as construções necessárias para a
modelagem da arquitetura do sistema, incluindo tempo de hardware, paralelismo e
comportamento reativo que são inexistentes no C++ padrão. A adição dessas
construções na linguagem C exigiria extensões proprietárias para a linguagem, o que
não é uma solução aceitável para a indústria. Desta forma a linguagem de programação
orientada a objetos C++ oferece a possibilidade de estendê-la através de classes, sem a
adição de novas construções sintáticas. A biblioteca SystemC provê essas classes e
permite que os designers continuem a usar o familiar C++ e ferramentas de
desenvolvimento.
SystemC suporta hardware/software co-design e a descrição da arquitetura de
sistemas complexos que consistem em componentes de hardware e software. Ele
suporta a descrição de hardware, software e interfaces em um ambiente C++. As
seguintes características do SystemC versão 2.0 permitem que seja usado como um
idioma codesign:
• Módulos: SystemC tem uma noção de uma classe recipiente chamado de
módulo. Este é uma entidade hierárquica, que pode ter outros módulos ou processos
nela contidas.
• Processos: Processos são usados para descrever a funcionalidade. Processos
estão contidos dentro de módulos. SystemC oferece três abstrações processo diferente
de serem utilizado pelo hardware e desenvolvedores de software.
• Portas: Módulos têm portas através das quais eles se conectam a outros
módulos. SystemC suporta portas única direção e bidirecional.
• Sinais: SystemC suporta sinais resolvidos e não resolvidos. Os sinais
resolvidos podem ter mais de um driver (one bus), enquanto os sinais não resolvidos só
podem ter um driver.
• Rico conjunto de tipos de portas e sinal: Para apoiar a modelagem em
diferentes níveis de abstração, a partir do funcional para a RTL, SystemC suporta um
rico conjunto de porta e tipos de sinais. Isso é diferente de linguagens como Verilog que
só suportam bits e bit-vetores como porta e tipos de sinais. SystemC suporta os tipos de
sinais dois valores e de quatro valores.
• Rico conjunto de tipos de dados: SystemC possui um conjunto de tipos de
dados para suportar múltiplos domínios de design e níveis de abstração. Os tipos de
dados de precisão fixa permitem simulação rápida, os tipos de precisão arbitrária podem
ser utilizados para cálculos com grandes números e os tipos de dados de ponto fixo
podem ser utilizados para aplicações de DSP. SystemC suporta tanto dois valores
quanto quatro valores de tipos de dados. Não há limitações de tamanho para tipos
SystemC de precisão arbitrária.
41
• Clocks: SystemC tem a noção de relógios (como sinais especiais). Relógios são
a cronometristas do sistema durante a simulação. Vários relógios, com arbitrária relação
de fase, são suportados.
• Ciclo de simulação: SystemC inclui um ciclo ultraleve baseado em núcleo de
simulação, que permite a simulação de alta velocidade.
• Vários níveis de abstração: SystemC suporta modelos de duração indetermina-
da em diferentes níveis de abstração, variando de modelos funcionais de alto nível para
modelos de ciclo de relógio precisos de modelos RTL. Ele suporta refinamento iterativo
de modelos de alto nível em níveis mais baixos de abstração.
• Protocolos de comunicação: SystemC permite a comunicação semântica multi-
nível que permitem descrever os protocolos do sistema I/O e SoC com diferentes níveis
de abstração.
• Suporte a depuração: classes SystemC tem verificação de erros em tempo de
execução, que pode ser ligado com uma flag de compilação.
• Forma de onda rastreamento: SystemC suporta rastreamento de formas de onda
em VCD, WIF, e Formatos ISDB.
A metodologia de projeto de hardware baseada em SystemC é mostrada na
Figura 18, abaixo:
Esta técnica tem uma série de vantagens. Com a abordagem SystemC, o projeto não
é convertido de uma descrição em C em uma descrição sintetizavel HDL com um
grande esforço. O projeto é lentamente refinado em pequenas seções para adição do
hardware e o tempo de construção necessário para produzir um bom design. Usando
esta metodologia de refinamento, fica mais fácil de implementar mudanças de projeto e
detectar erros durante refinamento.
Usando a abordagem SystemC, o designer não precisa ser um especialista em
múltiplas linguagens. SystemC permite a modelagem do nível do sistema até RTL, se
necessário.
A abordagem SystemC proporciona maior produtividade, porque o designer
pode modelar a um nível mais elevado. Escrevendo a um nível mais elevado pode
42
resultar em menor código, que é mais fácil de escrever e simula mais rápido do que
ambientes de modelagem tradicionais.
Embora a versão atual do SystemC não tenha as construções adequadas aos
modelos RTOS, isto está sendo previsto para versões futuras. Isso vai permitir que um
refinamento semelhante baseado na metodologia de concepção para as partes do sistema
de software. Os projetistas de software irá colher benefícios semelhantes aos projetistas
de hardware.
Seguindo esta mesma linha de vantagens foi desenvolvido nesse mestrado o
SynMaker que além de aceitar código de entrada puramente Java é especifico para
aplicações de filtro de processamento de imagem e o resultado da sua síntese
funcionando em tempo real numa placa de prototipação.
3.2.2. CATAPULT C
43
hardware. A flexibilidade e facilidade de uso oferecida pela síntese de ANSI C++ puro e
o estilo intuitivo de síntese do CatapultC é um aspecto fundamental deste fluxo.
3.2.3. IMPULSE C
44
oportunidades para otimização do projeto e experimentação, assim reduzindo o custos
do projeto, das fases de alto risco de projeto de hardware, estas são características e
vantagens que em geral são aplicadas as ferramentas de sínteses.
Apesar de o Impulse C proporcionar uma gama de vantagens para o usuário, o
mesmo não oferece suporte a paradigma de orientação ao objeto, o que o SynMaker na
sua primeira versão já é capaz de fazer com algumas restrições.
45
ferramentas utilizam linguagem C e, apenas
apenas, Catapult C e System C dão suporte
linguagem C++ que tem funcionalidades de orientação ao objeto objeto,, o que difere da
ferramenta proposta,
proposta, pois, a mesma foi desenvolvida para suporta mú
múltiplas
ltiplas linguagens,
li
apesar do SynMaker, na versão atual, ter seu foco de desenvolvimento voltado mais
para a linguagem JAVA. Ainda observando a Tabela 4,, verifi verifica-sese que muitas
ferramentas conseguem ou tem aplicabilidade para algoritmos de processamento de
imagem, porém nenhuma das citadas conseguem fazer uma síntese e integrar
automáticamente com uma placa de prototipação especí
específica,, que no caso do SynMaker é
a plataforma de camera digital da Altera. Uma observação importante é que a
ferramenta Lime que na teoria faz um processo parecido com a ferramenta proposta, na
prática não funciona para videos,
videos apenas para imagens e com algoritmos muito simples
de conversão de cores.
Tabela 4. Comparação
mparação entre ferramentas de síntese.
46
4 FERRAMENTA DE SÍNTESE: SYNMAKER
Neste capítulo será explicada por completo a ferramenta desenvolvida para esta
dissertação, como funciona, como deve ser instalada, como foi desenvolvida, as
liguagens, restrições, metodologia e fluxo de síntese.
O SynMaker proporciona que os projetistas trabalhem num ambiente de
abstração mais produtivo, fazendo com que circuitos, antes complexos, se tornem mas
fáceis de serem desenvolvidos. Em especial, no caso do SynMaker, aplicações de filtro
de processamento de imagens. A ferramenta também é capaz de criar vários tipos de
implementações diferentes para uma mesma aplicação, assim proporcionando ao
projetista a opção de escolha da melhor solução para as restrições (de área, potência)
especificadas para o sistema. Tendo em vista que a maioria das ferramentas de síntese
de alto nível existentes no mercado utilizam liguagem C ou C++ e conceitos estruturais,
percebeu-se que falta na comunidade científica uma ferramenta que utilizasse a
linguagem Java (uma das linguagens mais difundidas no mundo) para realização de
síntese de alto nivel. Foi pensando em preencher esse espaço que o SynMaker foi
desenvolvido. Além de Java, o SynMaker é suficentemente flexível para aceitar outras
linguagens de entrada e produzir o mesmo resultado de síntese, essa flexibilidade é um
diferencial da ferramenta em relação a outras existentes no mercado.
O SynMaker foi construído utilizando linguagem de programação Java e usa a
biblioteca para console chamada enigma para instanciar um console e mostrar para o
usuário informações sobre o processamento, usa o framework log4j para extrair um log
e para exibir a simulação do código de processamento de imagem de entrada inicial é
utilizada API JAI quando for utilizado uma imagem na simulação e a API XUGGLER
quando for utilizado um vídeo. Para iniciar a síntese, o usuário precisa ter um projeto
SynMaker, o projeto SynMaker tem arquivos e pastas padrão que se não forem
detectados a ferramenta irá lançar uma exceção. Essas configurações padrão são: a pasta
Sourcer (contém o código-fonte do projeto base da plataforma FPGA), pasta Log
(contém o registro de síntese), pasta de Simulação (contém as imagens e arquivos para
serem utilizadas no processo de simulação e que foram geradas neste processo) e pasta
de Otimização (contém um arquivo CDFG para gerar o gráfico CDFG e fazer
analisadores de otimização). A descrição RTL gerada no final da síntese é um
SystemVerilog, que, agora, pode ser sintetizado por uma ferramenta CAE, como o
QUARTUS II, e pode ser utilizado ou não num projeto base da plataforma D2-70 da
Altera, como explicado na secção 4.1 .
A Figura 20 ilustra a visão global da ferramenta desenvolvida, iniciando o
processo, como já foi citado, com uma descrição comportamental de entrada, JAVA ou
SystemVerilog, logo após o SynMaker pode realizar uma simulação ou uma síntese
nesse arquivo que foi dado de entrada, onde o resultado da simulação será apresentado
no computador e o resultado da síntese será um conjunto de módulos RTL que formarão
um projeto que poderá ser compilado e executado na placa de prototipação que exibirá o
resultado.
47
Figura 20.. Visão global do funcionamento.
funcionamento
4.1 ARQUITETURA
ARQUITET A ALVO DO SYNMAKER
48
plataforma de base. No estado atual, o SynMaker apenas pode alterar o fluxo do projeto
base entre a Touch_Tcon e LTM, mas o objetivo é que, no futuro, a ferramenta consiga
alterar o fluxo do projeto em outras partes, assim sendo possível usar outros módulos da
plataforma base.
(a)
(b)
Figura 21. Visão RTL de parte do projeto base utilizado pelo SynMaker. (a) Projeto base padrão. (b) Projeto
Base alterado pelo SynMaker após a síntese.
49
comportamental e irá utilizar um parser para a linguagem específica, no caso de Java,
usamos um parser já existente, mas no caso de SystemVerilog foi desenvolvido um
parser para estaa linguagem baseado na definição SystemVerilog Formal (BNF) que
está presente em [36]. A análise gera uma Árvore Sintática Abstrata (AST) e esta AST é
transfomada em uma representação intermediária criada para o SynMaker chamado
Árvore Sintática Abstrata Genérica (GAST). Assim, pode-se converter AST de
diferentes línguas em uma única representação e continuar o fluxo. Esta representação
única serve como entrada tanto para fase de simulação quanto para fase de síntese da
ferramenta. Se o usuário escolher através de comando realizar uma simulação, o
SynMaker irá para fase de simulação depois da realização da pré-compilação, caso ele
escolha realizar síntese, o SynMaker irá para fase de síntese após a pré-compilação. Na
fase de simulação de alto nível o SynMaker verifica, antes de fazer uma síntese, se o
código de entrada é um aplicativo de processamento de imagem digital válido e exibi a
execução desse código em tempo real na tela. Quando o usuário escolhe fazer a síntese,
o compilador HLS irá decidir o que vai ser feito com o GAST e pode começar a síntese
de duas formas que é escolhida pelo usuário através de um parâmetro no comando dado
na fase de processamento de comando no início do processo.
O primeiro caminho o SynMaker faz um processo de síntese simples, sem
otimização, usa apenas a representação intermediária GAST para fazer algumas análises
e gerar vários objetos chamados de entidades que serão transformados em RTLs pelo
gerador no próximo passo. O segundo caminho o SynMaker faz um processo de síntese
mais complexa e utiliza algumas técnicas de otimização para isso. Nesse processo a
parte da GAST equivalente a uma função é transformada em uma representação
intermediária CDFG pelo CDFG Builder. Logo após, um arquivo contendo essa
representação em forma gráfica também é criado e este arquivo pode ser visualizado
pelo o usuário. E por fim, as técnicas de otimização é aplicada para esta versão da
ferramenta, apenas, as otimizações ALAP, ASAP e IRM, podem ser feitas, o resultado
final é transformado em um RTL no próximo processo chamado Gerador RTL.
O Gerador RTL produz arquivos SystemVerilog que podem ser sintetizáveis, o
RTL é sintetizado para uma implementação FPGA utilizando a ferramenta comercial
Quartus II para compilar para uma Placa, no nosso caso, a plataforma de
desenvolvimento de câmera digital DE2-70 da Altera. O SynMaker usa um script TCL
para criar um projeto Quartus e executar os seguintes comandos:
Quartus_map - Traduz arquivos de concepção do projeto (por exemplo, a
RTL ou netlist EDA), elementos de design e mapeamento dos recursos do
dispositivo.
Quartus_fit - Denomina os lugares e rotas dos recursos do dispositivo FPGA.
Quartus_sta - Realiza uma análise de tempo estático no design.
Quartus_asm - Gera o arquivo de programação de pós-local e rota-design.
50
Figura 22. Fluxograma de síntese do SynMaker.
51
Sempre deve existir uma classe que estende HLSSystem. Não pode existir mais do que
uma classe que estende HLSSystem, deve sempre haver um método run() na classe que
estende HLSSystem, esse método não terá processamento, apenas chamada de função, e
o designer deve estar ciente que este metodo é uma representação abstrata de um loop
infinito no processo de síntese. Algumas operações da linguagem ainda não são
sintetizadas como Switch, While, Do-While, break, continue e construtores que
representam o estado inicial de uma classe. Algumas expressões da linguagem também
ainda não são possíveis de serem utilizadas no código de entrada para o SynMaker
como expressão condicional ternária.
2. sm_simu [-v Video | -i imagem ] [arquivo] - Use para fazer uma simulação. O
parâmetro arquivo é o caminho do código a ser simulado. O parâmetro –v é para
realizar uma simulação com exibição de vídeo passando o vídeo que será simulado e o
parâmetro -i para simulação de imagem passando a imagem a ser simulada.
3. sm_synth [-s] | [-o tipo] [-g |-c |-p] [arquivo] - Use para fazer um processo de
síntese. Os parâmetros s, o, g, c,p e arquivo são, respectivamente, realizar uma síntese
simples, realizar um síntese com uma otimização que pode ser do tipo ALAP, ASAP ou
IRM, gerar um projeto Quartus, executar uma compilação Quartus com a RTL gerado,
realizar a programação da placa com o arquivo .sof gerado pela compilação do Quartus
e o parâmetro final “arquivo” é o caminho do código a ser sintetizado.
52
4.2.3. PRÉ-COMPILADOR
PRÉ COMPILADOR HLS
4.2.4. SIMULAÇÃO
(a) (b)
Figura 24. Tela de Simulação. (a) Vídeo de entrada. (b) Vídeo de saída.
O compilador HLS irá decidir o que vai ser feito com o GAST e pode começar a
síntese de duas formas, escolhida pelo usuário através de um parâmetro determinado no
início do processo. O primeiro caminho a SynMaker faz um processo de síntese
simples, sem otimização, usa apenas a representação intermediária GAST para fazer
algumas análises e gerar os objetos entidades que serão transformados em um RTL pelo
gerador RTL no próximo passo. O segundo caminho o SynMaker faz um processo de
síntese mais complexa e utilizar algumas técnicas de otimização para isso, a Figura 25
mostra como este processo foi feito. A parte da GAST que representa uma função é
utilizada neste processo, essa parte da GAST é transformada em uma representação
chamada CDFG no passo CDFG Builder. Na próxima etapa, um arquivo contendo o
gráfico CDFG é criado e pode ser visualizado pelo usuário, este arquivo é levado para o
passo seguinte. O último passo do fluxo de otimização é o Ignition optimization que
implementará algumas técnicas de otimização, nesta versão inicial apenas otimização de
schedule como ALAP, ASAP e IRM, podem ser feitas e, finalmente, o resultado é
transformado em um RTL no próximo processo chamado gerador RTL.
54
Figura 25. Fluxo de otimização.
55
dentro do bloco seqüencial. Seguindo essa lógica, a Figura 26, demostra um exemplo de
código SystemVerilog gerado pela síntese de alto nível feita pelo SynMaker, com seus
inputs, outputs, declarações, ligações, lógica seqüêncial e combinacional.
56
Figura 27.. Metodologia de síntese do SynMaker para classe, função e sua respectiva interface RTL.
A Figura 28,
28, ilustra uma visão geral da metodologia de síntese da ferramenta,
destacando a classe TestSobel que extende HLSsystem que dará origem ao módulo
Toplevel da síntese. Cada trecho destacado no ccódigoódigo será sintetizado no respectivo
item que pode ser diferenciado pelas cores na figura. O código comportamental de
entrada contém a instanciação de duas classes não sintetizáveis destacadas pela cor
amarela, estas vão dar origem a dois módulos, LTM e TCON. TC Já o trecho de código
destacado de verde escuro que contém a instanciação de uma classe sintetizável pela
ferramenta chamada Sobel irá gerar um módulo com nome Sobel. As linhas roxas, roxas
vermelho, laranja e verde claro que representam a síntese de ligação foram geradas a
partir das chamadas de função do código de entrada, por exemplo, iLCD_R_t =
tcon.getNextPixelR()
tcon.getNextPixelR( deu origem a ligação entre o módulo TestSobelRun e Tcon. Tcon E por
fim, o destaque da função obrigató
obrigatória
ria run() que está em azul será sintetizada em outro
módulo chamado TestSobelRun.
Quando o usuário escolhe a síntese com otimização uma metodologia diferente é
iniciada. Para esta versão só há possibilidade de ser feita otimização por scheduling
ASAP, ALAP e IRM,
ASAP, IRM, esse tipo de síntese não suporta,
suporta ainda,, aplicações na Plataforma
de Processamento de Imagem Digital da Altera. No início da síntese com otimização
ocorre uma transformação do GAST num CDFG. IIgual gual à metodologia simples, uma
classe de linguagem de alto nível ainda sserá sintetizada
sintetizad em um módulo principal e as
funções desta classe ainda serserão
ão sintetizadas em módulos
módulo que irão ser instanciados
dentro do módulo principal sintetizado. A diferença é que o compilador da ferramenta
irá separar a parte da GAST que representa
representam as funções e extrair um CDFG para cada
função desta, ou seja, para cada função que existir na GAST irá ser gerado um CDFG.
A otimização será feita apenas nas funções porque são sã nelas que vão estar presentes as
funcionalidade Após obter o CDFG da função
funcionalidades. função, a otimização escolhida pelo usuário é
feita e a ferramenta gera a descrição RTL, uma máquina de estado finito e um caminho
de dados. As classes serão sintetizadas como módulos pais que apresentam em sua
estrutura, basicamente, apenas instanciação de outr outros
os módulos e links, não existe
existem
funcionalidade, portanto, não é feita nenhuma otimização, então, nenhuma extração de
funcionalidade,
CDFG é feita.
57
Figura 28.. Visão geral da metodologia de síntese de alto nível
ível do SynMaker
SynMaker.
58
PrintComb – O bloco combinacional será gerado neste momento e conterá a
chamada para a função de execução do mó módulo
dulo e seu retorno será colocado num
registrador que é declar
registrador declarado
ado dentro do módulo.
PrintFF – O bloco sequencial, always_ff, colocará a cada pulso de clock
(posedge) o resultado contido no registrador que conterá o resultado do bloco
combinacional num sinal de output, este sinal de outputoutput será ligad
ligadoo a uma saída do
módulo.
dulo.
PrintLink – Neste momento são geradas todas as ligações do mó módulo,
dulo, incluídas
nelas a ligação entre a saída
saída do always_ff ao output do módulo, e as ligações de entrada
e saída do módulo
módulo com as entradas e saídas de instancias de módulos que estão dentro
deste módulo
mó que esta sendo sintetizado.
sintetizado. Nesta etapa também é gerada aas declarações
dos fios (wire) que são necessários para realizar as ligações.
PrintInstances – Aqui será gerada as iinstancias
nstancias que estão dentro do mómódulo que
está sendo sintetizado.
printModuleClassEnd – Responsável apenas por incluir o final do mó módulo
gerado, end module.
O resultado final do passo anterior será um arquivo SystemVerilog que pode ser
sintetizado pela ferramenta Quartus II, o RTL é sintetizada em uma implementação
FPGA utilizando a ferramenta comercial Quartus II que compila para placa DE2 DE2-70
com FPGA Cyclone II na plataforma de desenvolvimento de Câmera Digital da Alter Altera,
o SynMaker usa um script TCL para criar um projeto Quartus e executar os seguintes
comandos abaixo, conforme seqüencia ilustrada na Figura 29.
Quartus_sh: Criar projeto e configurar o Quartus.
Quartus_map: síntese de arquivos de concepção do projeto (por exemplo, o RTL
ou netlist EDA), e elementos de design, mapas aos recursos do dispositivo.
Quartus_fit: lugares e rotas dos recursos do dispositivo para o FPGA.
Quartus_sta: realiza uma análise de tempo estático no design.
Quartus_asm: Gera arquivo de programação .pof e .sof.
Quartus_pgm: Executar o .pof.
Antes da execução desses comandos o SynMaker realiza uma verificação para
garantir que o Quartus II está instalado. Essa comunicação realiz
realizada
ada entre o Quartus II e
o SynMaker é feita através do módulo GenerateProject. O arquivo TCL também é
gerado automaticamente antes de ser executado, pois o projeto Quartus vai ter um
módulo TopLevel diferente dependendo do código de entrada dado, que pode ter
qualquer classe estendendo HLSSYSTEM.
No fim, quando termina a execução de todas essas linhas de comando da Figura
29,, o resultado é um RTL transformado numa implementação FPGA completa sob a
forma de um fluxo de bits programado nnaa plataforma FPGA alvo.
59
4.3 ARQUITETURA DO SYNMAKER
60
sendo cumpridas. Essa unidade possui dois componentes principais que é a unidade de
Synthesis - Simple e a unidade de Synthesis - Optimization.
A primeira é responsável por realizar uma síntese mais simples sem máquina de
estado ou otimizações de potência ou desempenho através de alguma técnica específica,
a primeira unidade da síntese simples realiza análises e verificações na AST genérica
recebida pela unidade de pré-compilação, logo após a um mapeamento de ordem de
sintetização de módulos, a unidade seguinte é a responsável por gerar o arquivo
sintetizado que será usado na próxima etapa e por fim a unidade Quartus Ignition que se
interliga com a plataforma Quartus II para geração do projeto Quartus, realização de
síntese e análises nos seus projetos para FPGA, o SynMaker chama o QUARTUS II
através da execução de linha de comando pelo shell no Linux ou pelo prompt de
comando no Windows.
A segunda é a unidade de síntese com otimização que esta dividido em unidade
de DFG onde será gerado, nessa unidade, a representação intermediária para otimização,
utilizando a árvore genérica vinda da unidade de pré-compilação, através do
componente DFG Builder o SynMaker irá construir essa nova representação e poderá
gerar um gráfico e utilizá-lo nos componentes que vem logo depois. A unidade
SchedulingToRTL que fará a otimização seguirá os seguintes passos, análise do DFG
para que seja otimizado na unidade Analyser, síntese do arquivo que representará a
máquina de estado, transferência de dados e o arquivo principal de síntese otimizada o
main. Uma observação é que o SchedulingToRTL ainda não conta, para essa versão do
SynMaker, com um componente QuartusIgnition que irá realizar a função de criação do
projeto e execução do mesmo na placa de prototipação.
61
5 EXPERIMENTOS E TESTES DE VALIDAÇÃO
5.1 AMBIENTE
USB Blaster (on board) for programming and user API control; both JTAG and
Active Serial (AS) programming modes are supported.
2-Mbyte SSRAM
Two 32-Mbyte SDRAM
8-Mbyte Flash memory
SD Card socket
4 push button switches
18 toggle switches
18 red user LEDs
9 green user LEDs
50-Mhz oscillator and 28.63-Mhz oscillator for clock sources
24-bit CD-quality audio CODEC with line-in, line-out, and microphone-in jacks
VGA DAC (10-bit high-speed triple DACs) with VGA-out connector
2 TV Decoder (NTSC/PAL) and TV-in connector
10/100 Ethernet Controllerwith a connector
USB Host/Slave Controller with USB type A and type B connectors
RS-232 transceiverand 9-pin connector
PS/2 mouse/keyboard connector
IrDA transceiver
1 SMA connector
Two 40-pin Expansion Headers with diode protection
63
Figura 31. Placa de desenvolvimento Altera D2-70.
64
Além dos componentes presentes na placa principal, há dois conectores para
viabilizar a integração de placas de expansão. Há várias placas de expansão disponíveis,
para os mais diversos fins e que são extremamente úteis no projeto e desenvolvimento
de aplicações. Em particular, há duas placas que se destacam quando o foco do projeto é
voltado para a área de visão computacional. São as placas TRDB-D5M e TRDB-LTH.
A placa TRDB-D5M possui uma câmera digital com um sensor CMOS Micron
com resolução máxima de 5 megapixels. Esta câmera é capaz de atuar tanto na captura
de imagens estáticas como para vídeo. Assim, se configura como um importante meio
de entrada para qualquer aplicação que trabalhe com captura de imagens para
processamento, como as aplicações de visão computacional. Figura 33, ilustra está
placa.
65
5.1.3. O FPGA EP2C70: CIRCUITO LÓGICO RECONFIGURÁVEL
66
Figura 36. Estrutura interna do FPGA EP2C70F896C6.
5.2 EXECUÇÃO
67
filtro de processamento de imagem chamado filtro de Sobel e finaliza-se com este filtro
em execução na placa. Outros filtros de processamento de imagem também foram
testados e alguns aplicativos simples de manipulação de imagem também ratificaram o
funcionamento ferramenta.
Linguage
Tipo de
Nº Teste m de
Metodologia
entrada
Síntese de
Declaration,
Assignment, Binary JAVA/
SIMPLES/
1 Expressions, Unary SYSTEM
OTIMIZADA
Expressions, Literal VERILOG
Expressions, Name
Expressions
Síntese de Array and
2 Method Call JAVA SIMPLES
Expression
JAVA/
Sínteseof Object
3 SYSTEM SIMPLES
Creation Expression
VERILOG
Síntese de For and If
4 JAVA SIMPLE
Statements
Síntese de function, JAVA/
SIMPLES /
5 Constructions and SYSTEM
OTIMIZADA
Classes VERILOG
Tabela 5. Testes de validação realizados.
68
(a) (b)
Figura 37. Altera DE2-70 Digital Camera Development Platform. (a) Projeto Base. (b) Projeto base alterado
pelo SynMaker com o filtro de sobel.
69
com uma função com parte do código do filtro, outra classe com uma função que
determinar o limiar do filtro e a terceira classe com outra função que realiza troca de
sinal do pixel. A terceira maneira o filtro possui duas classes, sendo uma delas com duas
funções internas, onde uma destas funções contém parte do código do filtro, e a outra
função determina o limiar do filtro e outra classe contém apenas uma função que faz a
mudança de sinal do pixel, dentre elas a primeira maneira de implementação obteve um
consumo de energia, um total de registradores e uma quantidade de elementos lógicos
inferior as outras, porém um período de clock maior. O total de elementos lógicos foi
muito próximo entre as três implementações e a implementação número três foi a que
obteve o menor período de clock.
Dentre todas as aplicações sintetizadas a que apresentou menor consumo de
energia, menor número de registradores e elementos lógicos foi a conversão para escala
de cinza e menor período de clock foi o Filtro de binarização. Dentre eles o filtro que
apresentou maior ciclo de clock foi o filtro de média, o que apresentou maior consumo e
maior numero de elementos lógicos foi o filtro de binarização, entre tanto quem
apresentou maior quantidade de registradores na síntese foi a segunda maneira de
implementação do filtro de sobel.
70
6 CONSIDERAÇÕES FINAIS
6.1 CONTRIBUIÇÕES
Foi apresentada, nesta dissertação, uma nova ferramenta para síntese de alto
nível de filtros de processamento de imagem desenvolvidos em Java ou SystemVerilog,
também foi demonstrado, através de vários exemplos, que a metodologia utilizada na
ferramenta é bastante eficiente, convertendo vários algoritmos de filtros de
processamento de imagem desenvolvido em linguagem de alto nível orientada a objeto,
com restrições, em seu RTL correspondente. Com isso é possível concluir que este
trabalho contribuiu com a comunidade científica por ter sido desenvolvido um novo
sistema de síntese de alto nível, com um fluxo de projeto e metodologia de síntese para
plataformas FPGA que o designer de circuitos pode programar em qualquer linguagem,
se essa linguagem é suportada pela ferramenta, este programa é convertido em uma
representação intermediária Genérica da ferramenta que gerará uma implementação
RTL que pode ser compilada e programada para a plataforma FPGA DE2-70 de Câmera
Digital da Altera através do Software Quartus II. Incluídos na ferramenta ainda estão
presentes um parser SystemVerilog, um parser JAVA, uma representação intermediária
Genérica e uma metodologia de síntese própria para desenvolver projetos que
funcionaram na plataforma de desenvolvimento de câmera digital da altera.
71
REFERÊNCIAS
[1] ADAMS, J. K.; THOMAS, D.E. Tutorial: The Design of Mixed Hardware/Software
Systems. DAC, 1996, p. 515–520.
[2] ADVE, V.; LATTNER, C. LLVM: A Compilation Framework for Lifelong
Program Analysis & Transformation, Symposium on Code Generation and
Optimization (CGO 2004), IEEE CS Press, p. 75–86.
[3] ADIMEC. Disponível em:<http://info.adimec.com/blogposts/bid/39656/CCD-vs-
CMOS-Image-Sensors-in-Machine-Vision-Cameras>.Acesso em: 04/03/2013.
[4] ADOLFO, G.; ALVAREZ, P. Especificação e Implementação de uma
Representação Intermediária Unificada para Sistemas Digitais. Master’s
Dissertation, Polytechnic School of University of São Paulo, São Paulo, Brazil,
2005. 135 pages.
[5] ALTERA CORPORATION. 1995-2012. Disponível em: <http://www.altera.com>.
Acesso em: 17/04/2013.
[6] AMELLAL, S.; KAMINSK, B. Scheduling of a control and data flow graph. IEEE
Int. Symposium on Circuits and Systems, 3:1666–1669, May 1993.
[7] AUERBACH, J. et al. Lime: a Java-compatible and synthesizable language for
heterogeneous architectures. SIGPLAN Conferences, Not. 45, 10 (October 2010),
89-108.
[8] AUTOESL DESIGN TECHNOLOGIES, INC. AutoESL's AutoPilot. 2010.
Disponível em: <http://www.autoesl.com/autopilto_fpga.htm>. Acesso em: 01 out.
2011.
[9] BERGAMASCHI, R. A. Bridging the domains of high-level and logic synthesis.
Computer-Aided Design of Integrated Circuits and Systems, IEEE
Transactions, v. 21, n. 5, p. 582-596, mai 2002, doi: 10.1109/43.998629.
Disponível em
<http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=998629&isnumber=215
47>. Acesso em: 21 nov. 2011.
[10] BERKELEY DESIGN TECHNOLOGY, INC. An Independent Evaluation of:
High-Level Synthesis Tools for Xilinx FPGAs, 2010. Disponível em:
<www.BDTI.com>.Acesso em: 1 mar. 2012.
[11] CALYPTO DESIGN SYSTEMS, INC. Catapult C Synthesis. 2010. Disponível
em:<http://www.mentor.com/products/esl/high_level_synthesis/catapult_synthesis>.
Acesso em: 01 out. 2011.
[12] CANIS, A. et al. LegUp: high-level synthesis for FPGA-based processor/accelerator
systems. In Proceedings of the 19th ACM/SIGDA international symposium on
Field programmable gate arrays (FPGA '11), 2011, New York, NY, USA, p. 33-
36, DOI=10.1145/1950413.1950423. Disponível em:
<http://doi.acm.org/10.1145/1950413.1950423>. Acesso em: 10 jan. 2012.
[13] CASSEAU, E.; LE GAL, B. High-level synthesis for the design of FPGA-based
signal processing systems. Systems, Architectures, Modeling, and Simulation.
SAMOS 2009 International Symposium, p.25-32, 20-23, jul. 2009, DOI:
10.1109/ICSAMOS.2009.5289238. Disponível
em: <http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=5289238&isnumbe
r=5289219>. Acesso em: 12 fev. 2012.
[14] CHEN, D et al. LOPASS: A Low-Power Architectural Synthesis System for FPGAs
With Interconnect Estimation and Optimization.Very Large Scale Integration
(VLSI) Systems, IEEE Transactions, v. 18, n. 4, p. 564-577, abr 2010 doi:
72
10.1109/TVLSI.2009.2013353. Disponível em:
<http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=5109476&isnumber=54
37466>. Acesso em: 21 nov. 2011.
[15] CROMAR, S.; LEE, J.; CHEN, D. FPGA-targeted high-level binding algorithm for
power and area reduction with glitch-estimation. In Proceedings of the 46th
Annual Design Automation Conference (DAC 2009). ACM, New York, NY,
USA, 838-843, DOI=10.1145/1629911.1630125. Disponível em
<http://doi.acm.org/10.1145/1629911.1630125>. Acesso em: 12 nov. 2011.
[16] CONG, J. et al. High-Level Synthesis for FPGAs: From Prototyping to
Deployment. Computer-Aided Design of Integrated Circuits and Systems, IEEE
Transactions, v.30, n.4, p.473-491, abr. 2011,
doi:10.1109/TCAD.2011.2110592. Disponível em
<http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=5737854&isnumber=5
737840>. Acesso em: 20 mar. 2012.
[17] COUSSY, P. GAUT: High-Level Synthesis tool From C to RTL. 2010.
Disponível em: <http://www-labsticc.univ-ubs.fr/www-gaut/>. Acesso em: 15 out.
2011.
[18] COUSSY, P. et al. An Introduction to High-Level Synthesis.Design & Test of
Computers, IEEE, v. 26, n. 4, p. 8-17, ago. 2009, doi: 10.1109/MDT.2009.69.
Disponível em:
<http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=5209958&isnumber=52
09950>. Acesso em: 14 out. 2011.
[19] COUSSY, P.; LHAIRECH-LEBRETON, G.; MARTIN, E. Hierarchical and
Multiple-Clock Domain High-Level Synthesis for Low-Power Design on FPGA.
Field Programmable Logic and Applications (FPL), 2010 International
Conference, p. 464-468, ago. 31 2010, doi: 10.1109/FPL.2010.94. Disponível em
<http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=5694295&isnumber=56
94025>. Acesso em: 03 abr. 2012.
[20] EDWARDS, S et al. Design of Embedded Systems: Formal Model, Validation and
Synthesi. Proceedings of the IEEE 85(3), 366–390, 1997.
[21] EJNIOUI, A; NAMBALLA, R.; RANGANATHAN, N. Control and data flow
graph extraction for high-level synthesis. Proceedings. IEEE Computer society
Annual Symposium. VLSI, 2004. p.187-192, 19-20 fev. 2004,
doi:10.1109/ISVLSI.2004.1339528. Disponível em:
<http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=1339528&isnumber=29
536>. Acesso em: 22 out. 2011.
[22] GAJSKI, D. et al. Specification and Design of EmbeddedSystems, Prentice-Hall,
Englewood Cliffs, N. J., 1994.
[23] GILL, A. Introduction to the Theory of Finite-State Machines. Electronic
Sciences Series, McGraw-Hill, New York, NY 10020, USA; 1962.
[24] GONZALEZ, R. C.; WOODS, R. E. Digital Image Processing. 2ª ed. New Jersey:
Prentice Hall, 2002.
[25] GUPTA, R. K.; DE MICHELI, G. System Synthesis via Hardware-Software Co-
Design, Technical Report CSL-TR-1992-548, Stanford University, Computer
Systems Laboratory.
[26] GUPTA, S. et al. SPARK: A parallelizing approach to the High-Level synthesis of
digital circuits. Kluwer Academic Publishers, 2004.
[27] IMPULSE C ACCELERATED TECHNOLOGIES. Disponível em:
<http://www.impulseaccelerated.com/>. Acesso em: 20/03/2013.
73
[28] KASTENBERG, H.; KLEPPE, A.G.; RENSINK, A. Engineering Object-Oriented
Semantics Using Graph Transformations. Technical Report TR-CTIT-2006-12,
Centre for Telematics and Information Technology University of Twente, Enschede.
ISSN 1381-3625.
[29] LEP MOTION. Disponível em: <https://leapmotion.com/>.Acesso em: 12/03/2013.
[30] MARTIN, G.; SMITH, G. High-Level Synthesis: Past, Present, and Future. IEEE
Design and Test of Computers, Jul. 2009.
[31] MARTIN, S. A. M. F. Ferramenta de apoio ao desenvolvimento de sistemas de
processamento de imagem em tempo real implementados em plataformas
reconfiguráveis. Departamento de Engenharia Eletronica e de Computadores,
Porto, 2007.
[32] OBRIZAN, V. A method for automatic generation of an RTL-interface from a C++
description. Design & Test Symposium (EWDTS), 2010, East-West, p.186-189,
17-20, set.2010, doi:10.1109/EWDTS.2010.5742152. Disponível
em: <http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=5742152&isnumbe
r=5742029>. Acesso em: 23 jan. 2012.
[33] PHILIPPE, C.; MORAWIEC, A. High-level Synthesis: From Algorithm To
Digital Circuit. Springer, 2008.
[34] RANGANATHAN, N.; NAMBALLA, R.; HANCHATE, N. CHESS: a
comprehensive tool for CDFG extraction and synthesis of low power designs from
VHDL. Emerging VLSI Technologies and Architectures, IEEE Computer Society
Annual Symposium, v.0, p.6, p.2-3, mar. 2006, DOI:
10.1109/ISVLSI.2006.27.Disponível
em: <http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=1602460&isnumbe
r=33676>. Acesso em: 12 nov. 2011.
[35] SINHA, S.; SRIKANTHAN, T. Hardware complexity metrics for high level
synthesis of software functions. VLSI Design, Automation and Test (VLSI-DAT),
2011 International Symposium, p. 1-4, 25-28 abr. 2011,
doi:10.1109/VDAT.2011.5783553. Disponível em:
<http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=5783553&isnumber=57
83538>. Acesso em: 02 mar. 2012.
[36] SUTHERLAND, S. et al. SystemVerilog for Design Second Edition: A Guide to
Using SystemVerilog for Hardware Design and Modeling. Out. 29, 2010,
Springer.
[37] SYSTEMC USER´S GUIDE VERSION 2.0. Disponível em:
<http://www.cse.iitd.ac.in/~panda/SYSTEMC/LangDocs/UserGuide20.pdf>
Acessado em: 04/04/2013.
[38] TERASIC ALTERA. Disponível em:<http://www.terasic.com.tw/cgi-
bin/page/archive.pl?No=226>.Acesso em: 18/03/2013.
[39] The Source for Java(TM) Technology Collaboration. Java Compiler Compiler
(JavaCC). Disponível em:<http://javacc.dev.java.net/>. Acesso em: 13 set. 2011.
[40] TRIPP, J.L.; GOKHALE, M.B.; PETERSON, K.D. Trident: From High-Level
Language to Hardware Circuitry. IEEE Computer, v.40, n.3, p.28-37, mar.2007,
DOI:10.1109/MC.2007.107. Disponível em:
< http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=4133993&isnumber=4
133979>. Acesso em: 10 fev. 2012.
[41] VALLERIO, K. S.; JHA, N. K. Task graph extraction for embedded system
synthesis. Proceedings 16th International Conference, VLSI Design, 2003. p.
480- 486, 4-8 Jan. 2003, doi: 10.1109/ICVD.2003.1183180. Disponível em:
74
<http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=1183180&isnumber=26
547>. Acesso em: 17 out. 2011.
[42] VAREA, M. Modelling And Verification Of Embedded Systems Based On Petri
Net Oriented Representations. Tese (Doutorado) - Department Of Electronics And
Computer Science, University Of Southampton, United Kingdom, 2003.
75
7 ANEXO
Anexo I
package br.ufpe.cin.hls.sample;
import br.ufpe.cin.hlslib.system.HLSSynth;
import br.ufpe.cin.hlslib.system.HLSSystem;
import br.ufpe.cin.hlslib.system.LTM;
import br.ufpe.cin.hlslib.system.touch_tcon;
int soma;
int somay,somax;
int y;
int x;
int[][] GX = new int[3][3];
int[][] GY = new int[3][3];
76
int res;
// Máscara de Sobel
GX[0][0] = -1; GX[0][1] = 0; GX[0][2] = 1;
GX[1][0] = -2; GX[1][1] = 0; GX[1][2] = 2;
GX[2][0] = -1; GX[2][1] = 0; GX[2][2] = 1;
for(int m=0;m<vetor*2+2;m++)
buffer[m]=buffer[m+1];
buffer[vetor*2+2]= oy;
//Reinicialização de variáveis
somax=0;
somay=0;
x= 1;
y= 1;
// Realizar convoluções
// GRADIENTE X
for(int i= -1; i<=1; i=i+1)
{
for(int j=-1; j<=1; j=j+1)
{
somax = somax + buffer[x+i+(y +
j)*vetor]*GX[i+1][j+1];
}
}
// GRADIENTE Y
if(res>255)
res=0;
else if(res<0)
res=0;
else if(res>=0 && res<=25)
res=0;
else
res=255;
return res;
77
public int sinal_cor(int d)
{
// inversão da escala de cinza
int res;
res= 255-d;
return res;
}
}
pixel_sobel_t=sobel2.fsobel(iLCD_R_t,iLCD_G_t,iLCD_B_t);//input_1,2,3
; output_4
oLCD_t=sobel2.sinal_cor(pixel_sobel_t);//input_4 ; output_5
ltm.setLtm_r(oLCD_t);//input_5
ltm.setLtm_b(oLCD_t);//input_6
ltm.setLtm_g(oLCD_t);//input_7
}
}
78
Anexo II
module Sobel( input logic SobelfsobeliCLK , input logic SobelfsobeliRST_n , input int
Sobelfsobel_input_3 , input int Sobelfsobel_input_4 , input int Sobelfsobel_input_5 , input logic
Sobelsinal_coriCLK , input logic Sobelsinal_coriRST_n , input int Sobelsinal_cor_input_3 , output int
Sobelfsobel_output_1 , output int Sobelsinal_cor_output_1 );
Sobelfsobel Sobelfsobel(
.Sobelfsobel_output_1(Sobelfsobel_output_1_sign),
.SobelfsobeliCLK(SobelfsobeliCLK_sign),
.SobelfsobeliRST_n(SobelfsobeliRST_n_sign),
.Sobelfsobel_input_3(Sobelfsobel_input_3_sign),
.Sobelfsobel_input_4(Sobelfsobel_input_4_sign),
.Sobelfsobel_input_5(Sobelfsobel_input_5_sign)
);
.Sobelsinal_cor_output_1(Sobelsinal_cor_output_1_sign),
.Sobelsinal_coriCLK(Sobelsinal_coriCLK_sign),
79
.Sobelsinal_coriRST_n(Sobelsinal_coriRST_n_sign),
.Sobelsinal_cor_input_3(Sobelsinal_cor_input_3_sign)
);
endmodule
80
Anexo III
module TestSobelrun( input logic TestSobelruniCLK , input logic TestSobelruniRST_n , input int
TestSobelrunltm_b , input int TestSobelrunltm_r , input int TestSobelrunltm_g , input int
TestSobelrunoLCD_G , input int TestSobelrunoLCD_R , input int TestSobelrunoLCD_B , input int
TestSobelrunSobelfsobel_output_1 , input int TestSobelrunSobelsinal_cor_output_1 , output int
TestSobelrunltm_b_input , output int TestSobelrunltm_r_input , output int TestSobelrunltm_g_input ,
output int TestSobelrunSobelfsobel_input_3 , output int TestSobelrunSobelfsobel_input_4 , output int
TestSobelrunSobelfsobel_input_5 , output int TestSobelrunSobelsinal_cor_input_3 );
endfunction
endmodule
81
Anexo IV
int return_Sobelsinal_cor_output_1 ;
endfunction
always_comb
begin
return_Sobelsinal_cor_output_1 = sinal_cor(Sobelsinal_cor_input_3);
end
end
endmodule
82
Anexo V
module Sobelfsobel( input logic SobelfsobeliCLK , input logic SobelfsobeliRST_n , input int
Sobelfsobel_input_3 , input int Sobelfsobel_input_4 , input int Sobelfsobel_input_5 , output int
Sobelfsobel_output_1 );
parameter int vetor = 1056;
int oy;
int buffer[2 * vetor + 3:0];
int return_Sobelfsobel_output_1 ;
83
for (int j = -1; j <= 1; j = j + 1)
begin
end
end
for (int i = -1; i <= 1; i = i + 1)
begin
end
end
if (somax < 0)
begin
somax = -somax;
end
if (somay < 0)
begin
somay = -somay;
end
res = somax + somay;
if (res > 255)
begin
res = 0;
end
else if (res < 0)
begin
res = 0;
end
else if (res >= 0 && res <= 25)
begin
res = 0;
end
else
begin
res = 255;
end
return res;
endfunction
always_comb
begin
return_Sobelfsobel_output_1 = fsobel(Sobelfsobel_input_3,Sobelfsobel_input_4,Sobelfsobel_input_5);
end
84
buffer[vetor * 2 + 2] <= oy;
end
endmodule
85
Anexo VI
Esse código não é sintetizado pelo SynMaker, ele faz parte do projeto
base onde vão ser inseridos os RTLs gerados pela ferramenta.
module LTM ( input wire [7:0] ltm_r_input, input wire [7:0] ltm_g_input, input wire [7:0]
ltm_b_input,
input wire ltm_hd_input, input wire ltm_vd_input, input wire
ltm_den_input,
output wire [7:0] ltm_r, output wire [7:0] ltm_g, output wire [7:0]
ltm_b,output wire ltm_hd, output wire ltm_vd, output wire ltm_den
);
endmodule
86
Anexo VII
Esse código não é sintetizado pelo SynMaker, ele faz parte do projeto
base onde vão ser inseridos os RTLs gerados pela ferramenta.
// --------------------------------------------------------------------
// Copyright (c) 2007 by Terasic Technologies Inc.
// --------------------------------------------------------------------
//
// Permission:
//
// Terasic grants permission to use and modify this code for use
// in synthesis for all Terasic Development Boards and Altera Development
// Kits made by Terasic. Other use of this code, including the selling
// ,duplication, or modification of any portion is strictly prohibited.
//
// Disclaimer:
//
// This VHDL/Verilog or C/C++ source code is intended as a design reference
// which illustrates how these types of functions can be implemented.
// It is the user's responsibility to verify their design for
// consistency and functionality through the use of formal
// verification methods. Terasic provides no warranty regarding the use
// or functionality of this code.
//
// --------------------------------------------------------------------
//
// Terasic Technologies Inc
// 356 Fu-Shin E. Rd Sec. 1. JhuBei City,
// HsinChu County, Taiwan
// 302
//
// web: http://www.terasic.com/
// email: support@terasic.com
//
// --------------------------------------------------------------------
//
// Major Functions: DE2 LTM module Timing control and output image data
// form sdram
//
// --------------------------------------------------------------------
//
// Revision History :
// --------------------------------------------------------------------
// Ver :| Author :| Mod. Date :| Changes Made:
// V1.0 :| Johnny Fan :| 07/06/30 :| Initial Revision
// --------------------------------------------------------------------
module touch_tcon (
iCLK, // LCD display clock
iRST_n, // systen reset
// SDRAM SIDE
iREAD_DATA1, // R and G color data form sdram
iREAD_DATA2, // B color data form sdram
oREAD_SDRAM_EN, // read sdram data control signal
87
//LCD SIDE
oHD, // LCD Horizontal sync
oVD, // LCD Vertical sync
oDEN, // LCD Data Enable
oLCD_R, // LCD Red color data
oLCD_G, // LCD Green color data
oLCD_B, // LCD Blue color data
);
//============================================================================
// PARAMETER declarations
//============================================================================
parameter H_LINE = 1056;
parameter V_LINE = 525;
parameter Hsync_Blank = 216;
parameter Hsync_Front_Porch = 40;
parameter Vertical_Back_Porch = 35;
parameter Vertical_Front_Porch = 10;
//===========================================================================
// PORT declarations
//===========================================================================
input iCLK;
input iRST_n;
input [15:0] iREAD_DATA1;
input [15:0] iREAD_DATA2;
output oREAD_SDRAM_EN;
output [7:0] oLCD_R;
output [7:0] oLCD_G;
output [7:0] oLCD_B;
output oHD;
output oVD;
output oDEN;
//=============================================================================
// REG/WIRE declarations
//=============================================================================
reg [10:0] x_cnt;
reg [9:0] y_cnt;
wire [7:0] read_red;
wire [7:0] read_green;
wire [7:0] read_blue;
wire display_area;
wire oREAD_SDRAM_EN;
reg mhd;
reg mvd;
reg mden;
reg oHD;
reg oVD;
reg oDEN;
reg [7:0] oLCD_R;
reg [7:0] oLCD_G;
reg [7:0] oLCD_B;
//=============================================================================
// Structural coding
//=============================================================================
// This signal control reading data form SDRAM , if high read color data form sdram .
assign oREAD_SDRAM_EN = ( (x_cnt>Hsync_Blank-2)&&
(x_cnt<(H_LINE-Hsync_Front_Porch-1))&&
(y_cnt>(Vertical_Back_Porch-1))&&
(y_cnt<(V_LINE - Vertical_Front_Porch))
)? 1'b1 : 1'b0;
88
assign read_red = display_area ? iREAD_DATA2[9:2] : 8'b0;
assign read_green = display_area ? {iREAD_DATA1[14:10],iREAD_DATA2[14:12]}: 8'b0;
assign read_blue = display_area ? iREAD_DATA1[9:2] : 8'b0;
89
oLCD_G <= 8'd0;
oLCD_B <= 8'd0;
end
else
begin
oHD <= mhd;
oVD <= mvd;
oDEN <= mden;
oLCD_R <= read_red;
oLCD_G <= read_green;
oLCD_B <= read_blue;
end
end
endmodule
90
Anexo VIII
module TestSobel
(
91
//////////////////// Clock Input ////////////////////
iCLK_28, // 28.63636 MHz
iCLK_50, // 50 MHz
iCLK_50_2, // 50 MHz
iCLK_50_3, // 50 MHz
iCLK_50_4, // 50 MHz
iEXT_CLOCK, // External Clock
//////////////////// Push Button ////////////////////
iKEY, // Pushbutton[3:0]
//////////////////// DPDT Switch ////////////////////
iSW, // Toggle Switch[17:0]
//////////////////// 7-SEG Dispaly ////////////////////
oHEX0_D, // Seven Segment Digit
0
oHEX0_DP, // Seven Segment Digit 0
decimal point
oHEX1_D, // Seven Segment Digit
1
oHEX1_DP, // Seven Segment Digit 1
decimal point
oHEX2_D, // Seven Segment Digit
2
oHEX2_DP, // Seven Segment Digit 2
decimal point
oHEX3_D, // Seven Segment Digit
3
oHEX3_DP, // Seven Segment Digit 3
decimal point
oHEX4_D, // Seven Segment Digit
4
oHEX4_DP, // Seven Segment Digit 4
decimal point
oHEX5_D, // Seven Segment Digit
5
oHEX5_DP, // Seven Segment Digit 5
decimal point
oHEX6_D, // Seven Segment Digit
6
oHEX6_DP, // Seven Segment Digit 6
decimal point
oHEX7_D, // Seven Segment Digit
7
oHEX7_DP, // Seven Segment Digit 7
decimal point
//////////////////////// LED ////////////////////////
oLEDG, // LED Green[8:0]
oLEDR, // LED Red[17:0]
//////////////////////// UART ////////////////////////
oUART_TXD, // UART Transmitter
iUART_RXD, // UART Receiver
oUART_CTS, // UART Clear To Send
iUART_RTS, // UART Requst To Send
//////////////////////// IRDA ////////////////////////
oIRDA_TXD, // IRDA Transmitter
iIRDA_RXD, // IRDA Receiver
///////////////////// SDRAM Interface ////////////////
DRAM_DQ, // SDRAM Data bus
32 Bits
oDRAM0_A, // SDRAM0 Address
bus 13 Bits
oDRAM1_A, // SDRAM1 Address
bus 13 Bits
oDRAM0_LDQM0, // SDRAM0 Low-byte Data Mask
oDRAM1_LDQM0, // SDRAM1 Low-byte Data Mask
oDRAM0_UDQM1, // SDRAM0 High-byte Data
Mask
oDRAM1_UDQM1, // SDRAM1 High-byte Data
92
Mask
oDRAM0_WE_N, // SDRAM0 Write Enable
oDRAM1_WE_N, // SDRAM1 Write Enable
oDRAM0_CAS_N, // SDRAM0 Column Address
Strobe
oDRAM1_CAS_N, // SDRAM1 Column Address
Strobe
oDRAM0_RAS_N, // SDRAM0 Row Address Strobe
oDRAM1_RAS_N, // SDRAM1 Row Address Strobe
oDRAM0_CS_N, // SDRAM0 Chip Select
oDRAM1_CS_N, // SDRAM1 Chip Select
oDRAM0_BA, // SDRAM0 Bank
Address
oDRAM1_BA, // SDRAM1 Bank
Address
oDRAM0_CLK, // SDRAM0 Clock
oDRAM1_CLK, // SDRAM1 Clock
oDRAM0_CKE, // SDRAM0 Clock
Enable
oDRAM1_CKE, // SDRAM1 Clock
Enable
//////////////////// Flash Interface ////////////////
FLASH_DQ, // FLASH Data bus 15
Bits (0 to 14)
FLASH_DQ15_AM1, // FLASH Data bus Bit 15 or
Address A-1
oFLASH_A, // FLASH Address bus
26 Bits
oFLASH_WE_N, // FLASH Write Enable
oFLASH_RST_N, // FLASH Reset
oFLASH_WP_N, // FLASH Write Protect
/Programming Acceleration
iFLASH_RY_N, // FLASH Ready/Busy output
oFLASH_BYTE_N, // FLASH Byte/Word Mode
Configuration
oFLASH_OE_N, // FLASH Output Enable
oFLASH_CE_N, // FLASH Chip Enable
//////////////////// SRAM Interface ////////////////
SRAM_DQ, // SRAM Data Bus 32
Bits
SRAM_DPA, // SRAM Parity Data Bus
oSRAM_A, // SRAM Address bus
22 Bits
oSRAM_ADSC_N, // SRAM Controller Address Status
oSRAM_ADSP_N, // SRAM Processor Address Status
oSRAM_ADV_N, // SRAM Burst Address Advance
oSRAM_BE_N, // SRAM Byte Write Enable
oSRAM_CE1_N, // SRAM Chip Enable
oSRAM_CE2, // SRAM Chip Enable
oSRAM_CE3_N, // SRAM Chip Enable
oSRAM_CLK, // SRAM Clock
oSRAM_GW_N, // SRAM Global Write Enable
oSRAM_OE_N, // SRAM Output Enable
oSRAM_WE_N, // SRAM Write Enable
//////////////////// ISP1362 Interface ////////////////
OTG_D, // ISP1362 Data bus 16
Bits
oOTG_A, // ISP1362 Address 2
Bits
oOTG_CS_N, // ISP1362 Chip Select
oOTG_OE_N, // ISP1362 Read
oOTG_WE_N, // ISP1362 Write
oOTG_RESET_N, // ISP1362 Reset
OTG_FSPEED, // USB Full Speed,
0 = Enable, Z = Disable
OTG_LSPEED, // USB Low Speed,
0 = Enable, Z = Disable
93
iOTG_INT0, // ISP1362 Interrupt 0
iOTG_INT1, // ISP1362 Interrupt 1
iOTG_DREQ0, // ISP1362 DMA
Request 0
iOTG_DREQ1, // ISP1362 DMA
Request 1
oOTG_DACK0_N, // ISP1362 DMA Acknowledge 0
oOTG_DACK1_N, // ISP1362 DMA Acknowledge 1
//////////////////// LCD Module 16X2 ////////////////
oLCD_ON, // LCD Power
ON/OFF
oLCD_BLON, // LCD Back Light
ON/OFF
oLCD_RW, // LCD Read/Write
Select, 0 = Write, 1 = Read
oLCD_EN, // LCD Enable
oLCD_RS, // LCD
Command/Data Select, 0 = Command, 1 = Data
LCD_D, // LCD Data bus 8 bits
//////////////////// SD_Card Interface ////////////////
SD_DAT, // SD Card Data
SD_DAT3, // SD Card Data 3
SD_CMD, // SD Card Command
Signal
oSD_CLK, // SD Card Clock
//////////////////// I2C ////////////////////////////
I2C_SDAT, // I2C Data
oI2C_SCLK, // I2C Clock
//////////////////// PS2 ////////////////////////////
PS2_KBDAT, // PS2 Keyboard Data
PS2_KBCLK, // PS2 Keyboard Clock
PS2_MSDAT, // PS2 Mouse Data
PS2_MSCLK, // PS2 Mouse Clock
//////////////////// VGA ////////////////////////////
oVGA_CLOCK, // VGA Clock
oVGA_HS, // VGA H_SYNC
oVGA_VS, // VGA V_SYNC
oVGA_BLANK_N, // VGA BLANK
oVGA_SYNC_N, // VGA SYNC
oVGA_R, // VGA Red[9:0]
oVGA_G, // VGA Green[9:0]
oVGA_B, // VGA Blue[9:0]
//////////// Ethernet Interface ////////////////////////
ENET_D, // DM9000A DATA bus 16Bits
oENET_CMD, // DM9000A
Command/Data Select, 0 = Command, 1 = Data
oENET_CS_N, // DM9000A Chip
Select
oENET_IOW_N, // DM9000A Write
oENET_IOR_N, // DM9000A Read
oENET_RESET_N, // DM9000A Reset
iENET_INT, // DM9000A Interrupt
oENET_CLK, // DM9000A Clock 25
MHz
//////////////// Audio CODEC ////////////////////////
AUD_ADCLRCK, // Audio CODEC ADC LR Clock
iAUD_ADCDAT, // Audio CODEC ADC Data
AUD_DACLRCK, // Audio CODEC DAC LR Clock
oAUD_DACDAT, // Audio CODEC DAC Data
AUD_BCLK, // Audio CODEC Bit-
Stream Clock
oAUD_XCK, // Audio CODEC Chip
Clock
//////////////// TV Decoder ////////////////////////
iTD1_CLK27, // TV Decoder1
Line_Lock Output Clock
iTD1_D, // TV Decoder1 Data bus 8 bits
94
iTD1_HS, // TV Decoder1 H_SYNC
iTD1_VS, // TV Decoder1 V_SYNC
oTD1_RESET_N, // TV Decoder1 Reset
iTD2_CLK27, // TV Decoder2
Line_Lock Output Clock
iTD2_D, // TV Decoder2 Data bus 8 bits
iTD2_HS, // TV Decoder2 H_SYNC
iTD2_VS, // TV Decoder2 V_SYNC
oTD2_RESET_N, // TV Decoder2 Reset
//////////////////// GPIO ////////////////////////////
GPIO_0, // GPIO Connection 0
I/O
GPIO_CLKIN_N0, // GPIO Connection 0 Clock Input
0
GPIO_CLKIN_P0, // GPIO Connection 0 Clock Input 1
GPIO_CLKOUT_N0, // GPIO Connection 0 Clock Output 0
GPIO_CLKOUT_P0, // GPIO Connection 0 Clock Output 1
GPIO_1, // GPIO Connection 1
I/O
GPIO_CLKIN_N1, // GPIO Connection 1 Clock Input 0
GPIO_CLKIN_P1, // GPIO Connection 1 Clock Input 1
GPIO_CLKOUT_N1, // GPIO Connection 1 Clock Output 0
GPIO_CLKOUT_P1 // GPIO Connection 1 Clock Output 1
);
//===========================================================================
// PARAMETER declarations
//===========================================================================
//===========================================================================
// PORT declarations
//===========================================================================
//////////////////////// Clock Input ////////////////////////
input iCLK_28; // 28.63636 MHz
input iCLK_50; // 50 MHz
input iCLK_50_2; // 50 MHz
input iCLK_50_3; // 50 MHz
input iCLK_50_4; // 50 MHz
input iEXT_CLOCK; // External Clock
//////////////////////// Push Button ////////////////////////
input [3:0] iKEY; // Pushbutton[3:0]
//////////////////////// DPDT Switch ////////////////////////
input [17:0] iSW; // Toggle Switch[17:0]
//////////////////////// 7-SEG Dispaly ////////////////////////
output [6:0] oHEX0_D; // Seven Segment Digit
0
output oHEX0_DP; // Seven Segment
Digit 0 decimal point
output [6:0] oHEX1_D; // Seven Segment Digit
1
output oHEX1_DP; // Seven Segment
Digit 1 decimal point
output [6:0] oHEX2_D; // Seven Segment Digit
2
output oHEX2_DP; // Seven Segment
Digit 2 decimal point
output [6:0] oHEX3_D; // Seven Segment Digit
3
output oHEX3_DP; // Seven Segment
Digit 3 decimal point
output [6:0] oHEX4_D; // Seven Segment Digit
4
output oHEX4_DP; // Seven Segment
Digit 4 decimal point
output [6:0] oHEX5_D; // Seven Segment Digit
95
5
output oHEX5_DP; // Seven Segment
Digit 5 decimal point
output [6:0] oHEX6_D; // Seven Segment Digit
6
output oHEX6_DP; // Seven Segment
Digit 6 decimal point
output [6:0] oHEX7_D; // Seven Segment Digit
7
output oHEX7_DP; // Seven Segment
Digit 7 decimal point
//////////////////////////// LED ////////////////////////////
output [8:0] oLEDG; // LED Green[8:0]
output [17:0] oLEDR; // LED Red[17:0]
//////////////////////////// UART ////////////////////////////
output oUART_TXD; // UART
Transmitter
input iUART_RXD; // UART
Receiver
output oUART_CTS; // UART Clear To Send
input iUART_RTS; // UART Requst To Send
//////////////////////////// IRDA ////////////////////////////
output oIRDA_TXD; // IRDA
Transmitter
input iIRDA_RXD; // IRDA
Receiver
/////////////////////// SDRAM Interface ////////////////////////
inout [31:0] DRAM_DQ; // SDRAM Data bus
32 Bits
output [12:0] oDRAM0_A; // SDRAM0 Address
bus 13 Bits
output [12:0] oDRAM1_A; // SDRAM1 Address
bus 13 Bits
output oDRAM0_LDQM0; // SDRAM0 Low-byte
Data Mask
output oDRAM1_LDQM0; // SDRAM1 Low-byte
Data Mask
output oDRAM0_UDQM1; // SDRAM0 High-byte
Data Mask
output oDRAM1_UDQM1; // SDRAM1 High-byte
Data Mask
output oDRAM0_WE_N; // SDRAM0 Write
Enable
output oDRAM1_WE_N; // SDRAM1 Write
Enable
output oDRAM0_CAS_N; // SDRAM0 Column
Address Strobe
output oDRAM1_CAS_N; // SDRAM1 Column
Address Strobe
output oDRAM0_RAS_N; // SDRAM0 Row
Address Strobe
output oDRAM1_RAS_N; // SDRAM1 Row
Address Strobe
output oDRAM0_CS_N; // SDRAM0 Chip
Select
output oDRAM1_CS_N; // SDRAM1 Chip
Select
output [1:0] oDRAM0_BA; // SDRAM0 Bank
Address
output [1:0] oDRAM1_BA; // SDRAM1 Bank
Address
output oDRAM0_CLK; // SDRAM0
Clock
output oDRAM1_CLK; // SDRAM1
Clock
output oDRAM0_CKE; // SDRAM0
Clock Enable
96
output oDRAM1_CKE; // SDRAM1
Clock Enable
//////////////////////// Flash Interface ////////////////////////
inout [14:0] FLASH_DQ; // FLASH Data bus 15
Bits (0 to 14)
inout FLASH_DQ15_AM1; // FLASH Data bus
Bit 15 or Address A-1
output [21:0] oFLASH_A; // FLASH Address bus
26 Bits
output oFLASH_WE_N; // FLASH Write
Enable
output oFLASH_RST_N; // FLASH Reset
output oFLASH_WP_N; // FLASH Write
Protect /Programming Acceleration
input iFLASH_RY_N; // FLASH Ready/Busy
output
output oFLASH_BYTE_N; // FLASH Byte/Word
Mode Configuration
output oFLASH_OE_N; // FLASH Output
Enable
output oFLASH_CE_N; // FLASH Chip Enable
//////////////////////// SRAM Interface ////////////////////////
inout [31:0] SRAM_DQ; // SRAM Data Bus 32
Bits
inout [3:0] SRAM_DPA; // SRAM Parity Data Bus
output [18:0] oSRAM_A; // SRAM Address bus
21 Bits
output oSRAM_ADSC_N; // SRAM Controller Address
Status
output oSRAM_ADSP_N; // SRAM Processor Address Status
output oSRAM_ADV_N; // SRAM Burst Address Advance
output [3:0] oSRAM_BE_N; // SRAM Byte Write Enable
output oSRAM_CE1_N; // SRAM Chip Enable
output oSRAM_CE2; // SRAM Chip Enable
output oSRAM_CE3_N; // SRAM Chip Enable
output oSRAM_CLK; // SRAM Clock
output oSRAM_GW_N; // SRAM Global Write Enable
output oSRAM_OE_N; // SRAM Output Enable
output oSRAM_WE_N; // SRAM Write Enable
//////////////////// ISP1362 Interface ////////////////////////
inout [15:0] OTG_D; // ISP1362 Data bus 16
Bits
output [1:0] oOTG_A; // ISP1362 Address 2
Bits
output oOTG_CS_N; // ISP1362
Chip Select
output oOTG_OE_N; // ISP1362
Read
output oOTG_WE_N; // ISP1362
Write
output oOTG_RESET_N; // ISP1362 Reset
inout OTG_FSPEED; // USB Full
Speed, 0 = Enable, Z = Disable
inout OTG_LSPEED; // USB Low
Speed, 0 = Enable, Z = Disable
input iOTG_INT0; // ISP1362
Interrupt 0
input iOTG_INT1; // ISP1362
Interrupt 1
input iOTG_DREQ0; // ISP1362
DMA Request 0
input iOTG_DREQ1; // ISP1362
DMA Request 1
output oOTG_DACK0_N; // ISP1362 DMA
Acknowledge 0
output oOTG_DACK1_N; // ISP1362 DMA
Acknowledge 1
97
//////////////////// LCD Module 16X2 ////////////////////////////
inout [7:0] LCD_D; // LCD Data bus 8 bits
output oLCD_ON; // LCD
Power ON/OFF
output oLCD_BLON; // LCD
Back Light ON/OFF
output oLCD_RW; // LCD
Read/Write Select, 0 = Write, 1 = Read
output oLCD_EN; // LCD
Enable
output oLCD_RS; // LCD
Command/Data Select, 0 = Command, 1 = Data
//////////////////// SD Card Interface ////////////////////////
inout SD_DAT; // SD Card
Data
inout SD_DAT3; // SD Card
Data 3
inout SD_CMD; // SD Card
Command Signal
output oSD_CLK; // SD Card
Clock
//////////////////////// I2C ////////////////////////////////
inout I2C_SDAT; // I2C Data
output oI2C_SCLK; // I2C
Clock
//////////////////////// PS2 ////////////////////////////////
inout PS2_KBDAT; // PS2
Keyboard Data
inout PS2_KBCLK; // PS2
Keyboard Clock
inout PS2_MSDAT; // PS2
Mouse Data
inout PS2_MSCLK; // PS2
Mouse Clock
//////////////////////// VGA ////////////////////////////
output oVGA_CLOCK; // VGA Clock
output oVGA_HS; // VGA
H_SYNC
output oVGA_VS; // VGA
V_SYNC
output oVGA_BLANK_N; // VGA BLANK
output oVGA_SYNC_N; // VGA SYNC
output [9:0] oVGA_R; // VGA Red[9:0]
output [9:0] oVGA_G; // VGA Green[9:0]
output [9:0] oVGA_B; // VGA Blue[9:0]
//////////////// Ethernet Interface ////////////////////////////
inout [15:0] ENET_D; // DM9000A DATA
bus 16Bits
output oENET_CMD; //
DM9000A Command/Data Select, 0 = Command, 1 = Data
output oENET_CS_N; //
DM9000A Chip Select
output oENET_IOW_N; // DM9000A Write
output oENET_IOR_N; // DM9000A Read
output oENET_RESET_N; // DM9000A Reset
input iENET_INT; //
DM9000A Interrupt
output oENET_CLK; //
DM9000A Clock 25 MHz
//////////////////// Audio CODEC ////////////////////////////
inout AUD_ADCLRCK; // Audio CODEC ADC
LR Clock
input iAUD_ADCDAT; // Audio CODEC ADC
Data
inout AUD_DACLRCK; // Audio CODEC DAC
LR Clock
output oAUD_DACDAT; // Audio CODEC DAC
98
Data
inout AUD_BCLK; // Audio
CODEC Bit-Stream Clock
output oAUD_XCK; // Audio
CODEC Chip Clock
//////////////////// TV Devoder ////////////////////////////
input iTD1_CLK27; // TV
Decoder1 Line_Lock Output Clock
input [7:0] iTD1_D; // TV Decoder1 Data
bus 8 bits
input iTD1_HS; // TV Decoder1
H_SYNC
input iTD1_VS; // TV Decoder1
V_SYNC
output oTD1_RESET_N; // TV Decoder1 Reset
input iTD2_CLK27; // TV
Decoder2 Line_Lock Output Clock
input [7:0] iTD2_D; // TV Decoder2 Data
bus 8 bits
input iTD2_HS; // TV Decoder2
H_SYNC
input iTD2_VS; // TV Decoder2
V_SYNC
output oTD2_RESET_N; // TV Decoder2 Reset
// CCD
wire [11:0] CCD_DATA;
wire CCD_SDAT;
wire CCD_SCLK;
wire CCD_FLASH;
wire CCD_FVAL;
wire CCD_LVAL;
wire CCD_PIXCLK;
wire CCD_MCLK; // CCD Master Clock
99
wire DLY_RST_2;
wire Read;
reg [11:0] rCCD_DATA;
reg rCCD_LVAL;
reg rCCD_FVAL;
wire [11:0] sCCD_R;
wire [11:0] sCCD_G;
wire [11:0] sCCD_B;
wire sCCD_DVAL;
wire [9:0] oVGA_R; // VGA Red[9:0]
wire [9:0] oVGA_G; // VGA Green[9:0]
wire [9:0] oVGA_B; // VGA Blue[9:0]
reg [1:0] rClk;
wire sdram_ctrl_clk;
wire out_enable;
wire den;
wire [9:0] r;
wire [9:0] g;
wire [9:0] b;
//=============================================================================
// Structural coding
//=============================================================================
assign CCD_DATA[0] = GPIO_1[11];
assign CCD_DATA[1] = GPIO_1[10];
assign CCD_DATA[2] = GPIO_1[9];
assign CCD_DATA[3] = GPIO_1[8];
assign CCD_DATA[4] = GPIO_1[7];
assign CCD_DATA[5] = GPIO_1[6];
assign CCD_DATA[6] = GPIO_1[5];
assign CCD_DATA[7] = GPIO_1[4];
assign CCD_DATA[8] = GPIO_1[3];
assign CCD_DATA[9] = GPIO_1[2];
assign CCD_DATA[10]= GPIO_1[1];
assign CCD_DATA[11]= GPIO_1[0];
assign GPIO_CLKOUT_N1 = CCD_MCLK;
assign CCD_FVAL = GPIO_1[18];
assign CCD_LVAL = GPIO_1[17];
assign CCD_PIXCLK = GPIO_CLKIN_N1;
assign GPIO_1[15] = 1'b1; // tRIGGER
assign GPIO_1[14] = DLY_RST_1;
100
assign oTD1_RESET_N = 1'b1;
assign oVGA_CLOCK = ~VGA_CTRL_CLK;
always@(posedge CCD_PIXCLK)
begin
rCCD_DATA <= CCD_DATA;
rCCD_LVAL <= CCD_LVAL;
rCCD_FVAL <= CCD_FVAL;
end
Reset_Delay u1 ( .iCLK(iCLK_50),
.iRST(iKEY[0]),
.oRST_0(DLY_RST_0),
.oRST_1(DLY_RST_1),
.oRST_2(DLY_RST_2)
);
CCD_Capture u2 ( .oDATA(mCCD_DATA),
.oDVAL(mCCD_DVAL),
.oX_Cont(X_Cont),
.oY_Cont(Y_Cont),
.oFrame_Cont(Frame_Cont),
.iDATA(rCCD_DATA),
.iFVAL(rCCD_FVAL),
.iLVAL(rCCD_LVAL),
.iSTART(!iKEY[3]),
.iEND(!iKEY[2]),
.iCLK(CCD_PIXCLK),
.iRST(DLY_RST_2)
);
RAW2RGB u3 ( .iCLK(CCD_PIXCLK),
.iRST_n(DLY_RST_1),
.iData(mCCD_DATA),
.iDval(mCCD_DVAL),
.oRed(sCCD_R),
.oGreen(sCCD_G),
.oBlue(sCCD_B),
.oDval(sCCD_DVAL),
.iMIRROR(iSW[17]),
.iX_Cont(X_Cont),
.iY_Cont(Y_Cont)
);
SEG7_LUT_8 u4 ( .oSEG0(oHEX0_D),.oSEG1(oHEX1_D),
.oSEG2(oHEX2_D),.oSEG3(oHEX3_D),
.oSEG4(oHEX4_D),.oSEG5(oHEX5_D),
.oSEG6(oHEX6_D),.oSEG7(oHEX7_D),
.iDIG(Frame_Cont[31:0]) );
vga_pll u5 ( .inclk0(iCLK_50_2),
.c0(ltm_nclk),
.c1()
);
sdram_pll u6 ( .inclk0(iCLK_50_3),
.c0(sdram_ctrl_clk),
.c1(oDRAM0_CLK),
.c2(oDRAM1_CLK)
);
101
assign CCD_MCLK = rClk[0];
// SDRAM Side
.SA(oDRAM0_A[11:0]),
.BA(oDRAM0_BA),
.CS_N(oDRAM0_CS_N),
.CKE(oDRAM0_CKE),
.RAS_N(oDRAM0_RAS_N),
.CAS_N(oDRAM0_CAS_N),
.WE_N(oDRAM0_WE_N),
.DQ(DRAM_DQ[15:0]),
.DQM({oDRAM0_UDQM1,oDRAM0_LDQM0})
);
// SDRAM Side
.SA(oDRAM1_A[11:0]),
.BA(oDRAM1_BA),
.CS_N(oDRAM1_CS_N),
.CKE(oDRAM1_CKE),
.RAS_N(oDRAM1_RAS_N),
102
.CAS_N(oDRAM1_CAS_N),
.WE_N(oDRAM1_WE_N),
.DQ(DRAM_DQ[31:16]),
.DQM({oDRAM1_UDQM1,oDRAM1_LDQM0})
);
);
lcd_3wire_config u11 (
// Host Side
.iCLK(iCLK_50),
.iRST_n(DLY_RST_0),
// 3 wire Side
.o3WIRE_SCLK(ltm_sclk),
.io3WIRE_SDAT(ltm_sda),
.o3WIRE_SCEN(ltm_scen),
.o3WIRE_BUSY_n(ltm_3wirebusy_n)
);
//wire [7:0] ltm_r_sign; // LTM Red Data 8 Bits
//wire [7:0] ltm_g_sign; // LTM Green Data 8 Bits
//wire [7:0] ltm_b_sign; // LTM Blue Data 8 Bits
//wire ltm_hd_input_sign;
//wire ltm_vd_input_sign;
//wire ltm_den_input_sign;
//wire ltm_hd_sign;
//wire ltm_vd_sign;
//wire ltm_den_sign;
103
assign GPIO_0[14] =ltm_g_sign[0];
assign GPIO_CLKOUT_P0 =ltm_g_sign[1];
assign GPIO_0[15] =ltm_g_sign[2];
assign GPIO_0[16] =ltm_g_sign[3];
assign GPIO_0[17] =ltm_g_sign[4];
assign GPIO_0[18] =ltm_g_sign[5];
assign GPIO_0[19] =ltm_g_sign[6];
assign GPIO_0[20] =ltm_g_sign[7];
assign GPIO_0[21] =ltm_r_sign[0];
assign GPIO_0[22] =ltm_r_sign[1];
assign GPIO_0[23] =ltm_r_sign[2];
assign GPIO_0[24] =ltm_r_sign[3];
assign GPIO_0[25] =ltm_r_sign[4];
assign GPIO_0[26] =ltm_r_sign[5];
assign GPIO_0[27] =ltm_r_sign[6];
assign GPIO_0[28] =ltm_r_sign[7];
assign GPIO_0[29] =ltm_grst;
assign GPIO_0[30] =ltm_scen;
assign GPIO_0[31] =ltm_sda;
LTM LTM(
.ltm_hd(ltm_hd_sign),
.ltm_vd(ltm_vd_sign),
.ltm_den(ltm_den_sign),
.ltm_b(ltm_b_sign),
.ltm_r(ltm_r_sign),
.ltm_g(ltm_g_sign),
.ltm_b_input(ltm_b_input_sign),
.ltm_r_input(ltm_r_input_sign),
.ltm_g_input(ltm_g_input_sign),
.ltm_hd_input(ltm_hd_input_sign),
.ltm_vd_input(ltm_vd_input_sign),
.ltm_den_input(ltm_den_input_sign)
);
104
wire [31:0] ltm_g_input_sign;
wire [31:0] ltm_hd_input_sign;
wire [31:0] ltm_vd_input_sign;
wire [31:0] ltm_den_input_sign;
touch_tcon touch_tcon(
.oLCD_G(oLCD_G_sign),
.oLCD_R(oLCD_R_sign),
.oLCD_B(oLCD_B_sign),
.oREAD_SDRAM_EN(oREAD_SDRAM_EN_sign),
.oHD(oHD_sign),
.oVD(oVD_sign),
.oDEN(oDEN_sign),
.iCLK(iCLK_sign),
.iRST_n(iRST_n_sign),
.iREAD_DATA1(iREAD_DATA1_sign),
.iREAD_DATA2(iREAD_DATA2_sign)
);
);
105
wire [31:0] TestSobelrunSobelsinal_cor_output_1_sign;
Sobel Sobel(
.Sobelfsobel_output_1(Sobelfsobel_output_1_sign),
.Sobelsinal_cor_output_1(Sobelsinal_cor_output_1_sign),
.SobelfsobeliCLK(SobelfsobeliCLK_sign),
.SobelfsobeliRST_n(SobelfsobeliRST_n_sign),
.Sobelfsobel_input_3(Sobelfsobel_input_3_sign),
.Sobelfsobel_input_4(Sobelfsobel_input_4_sign),
.Sobelfsobel_input_5(Sobelfsobel_input_5_sign),
.Sobelsinal_coriCLK(Sobelsinal_coriCLK_sign),
.Sobelsinal_coriRST_n(Sobelsinal_coriRST_n_sign),
.Sobelsinal_cor_input_3(Sobelsinal_cor_input_3_sign)
);
endmodule
106