projeto e implementaÇÃo de um emulador...
TRANSCRIPT
Universidade Federal do Rio de Janeiro
Escola Politécnica
Departamento de Eletrônica e de Computação
Projeto e Implementação de um Emulador Digital de
Equipamento de Medição Instantânea de Frequência (IFM)
Autor:
_________________________________________________
Matheus Souza Pinto Engel
Orientador:
_________________________________________________
Prof. Heraldo Luis Silveira de Almeida, D. Sc.
Orientador:
_________________________________________________
Prof. Alexandre Baptista Magalhães, M. Sc.
Examinador:
_________________________________________________
Prof. Aloysio de Castro Pinto Pedroza, D. Sc.
Examinador:
_________________________________________________
Prof. Flávio Luis de Mello, D. Sc.
DEL
Agosto de 2014
ii
UNIVERSIDADE FEDERAL DO RIO DE JANEIRO
Escola Politécnica – Departamento de Eletrônica e de Computação
Centro de Tecnologia, bloco H, sala H-217, Cidade Universitária
Rio de Janeiro – RJ CEP 21949-900
Este exemplar é de propriedade da Universidade Federal do Rio de Janeiro, que
poderá incluí-lo em base de dados, armazenar em computador, microfilmar ou adotar
qualquer forma de arquivamento.
É permitida a menção, reprodução parcial ou integral e a transmissão entre
bibliotecas deste trabalho, sem modificação de seu texto, em qualquer meio que esteja
ou venha a ser fixado, para pesquisa acadêmica, comentários e citações, desde3 que sem
finalidade comercial e que seja feita a referência bibliográfica completa.
Os conceitos expressos neste trabalho são de responsabilidade do(s) autor(es) e
do(s) orientador(es).
iii
DEDICATÓRIA
A meu pai, Adeum Engel (in memoriam), por ter sido para mim o maior exemplo
de caráter, trabalho árduo, dedicação e responsabilidade, e por todo o seu esforço e
doação despendidos para que eu pudesse ter condições de crescer, superar obstáculos e
conquistar meus maiores objetivos na vida.
iv
AGRADECIMENTO
A Deus pelo dom da vida e por tudo o que hoje tenho e sou.
À família por todo o apoio e suporte dados para que eu pudesse chegar até aqui
com foco, disposição e força.
A minha namorada Michelle Maia por todo o seu carinho, compreensão e
incentivo de sempre, que sem dúvida tornaram essa jornada mais leve e prazerosa.
Aos amigos pela paciência e amizade a mim transmitidas de forma sincera e
generosa.
Aos colegas de curso pelo auxílio e companheirismo trocados ao longo de todo
esse período.
Aos colegas do estágio pela receptividade, direcionamento e aprendizado
alcançados por meio dessa oportunidade.
Aos professores pelo esforço, dedicação, atenção e excepcional formação dados
de maneira sábia e ao mesmo tempo amigável.
Aos meus orientadores, Prof. Heraldo e Alexandre, pela excelente didática e
inesgotável paciência para ensinar todos os conceitos necessários para o
desenvolvimento deste projeto.
v
RESUMO
Este trabalho apresenta a implementação de um emulador digital de um
equipamento IFM utilizando-se de um circuito contendo uma placa de desenvolvimento
FPGA, programada em VHDL no Quartus II, da Altera, a qual é conectada ao
computador via interface serial, para inserção dos dados pelo usuário por meio de uma
GUI, desenvolvida na linguagem C++ em ambiente QT Creator, e ao barramento FPDP,
através de uma placa de interface projetada usando os softwares OrCAD Capture
(esquemático) e OrCAD PCB Designer (layout).
Palavras-Chave: radar, IFM, FPDP, FPGA, VHDL, C++.
vi
ABSTRACT
This work presents an implementation of a digital emulator of an IFM
equipment, by the use of a circuit containing a FPGA-based development board,
programmed in VHDL in Quartus II, from Altera, which is connected to the computer
via serial interface, for data insertion by the user by means of a GUI, developed in C++
language in QT Creator environment, and to the FPDP bus, through an interface board
projected using OrCAD Capture (schematics) and OrCAD PCB Designer (layout)
softwares.
Key-words: radar, IFM, FPDP, FPGA, VHDL, C++.
vii
SIGLAS
ASCII – American Standard Code for Information Interchange
CI – Circuito Integrado
CMOS – Complementary Metal-Oxide-Semiconductor
CW – Continuous Wave
DDR SDRAM – Double Data Rate Synchronous Dynamic Random-Access Memory
EDIFM – Emulador Digital de IFM
FMOP – Frequency Modulation On Pulse
FPDP – Front Panel Data Port
FPGA – Field Programmable Gate Array
GUI – Graphic User Interface
HSMC – High Speed Mezzanine Card
I/O – Input/Output
IFM – Instantaneous Frequency Measurement
LED – Light-Emitting Diode
LP – Largura de Pulso
LSB – Least Significant Bit
LVCMOS – Low-Voltage CMOS
LVTTL – Low-Voltage TTL
MSB – Most Significant Bit
PA – Pulse Amplitude
PCI – Placa de Circuito Impresso
PDW – Pulse Descriptor Word
PECL – Positive Emitter-Coupled Logic
PLL – Phase-Locked Loop
PMOP – Phase Modulation On Pulse
PRF – Pulse Repetition Frequency
PRI – Pulse Repetition Interval
PW – Pulse Width
RF – Radiofrequência
SRAM – Static Random-Access Memory
TOA – Time Of Arrival
TTL – Transistor-Transistor Logic
viii
UART – Universal Asynchronous Receiver and Transmitter
USB – Universal Serial Bus
VHDL – VHSIC Hardware Description Language
VHSIC – Very High Speed Integrated Circuits
ix
Sumário
1 Introdução
1
1.1 - Tema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 - Delimitação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.3 - Justificativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.4 - Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.5 - Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.6 - Descrição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Radar e IFM
4
2.1 - Radar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 - IFM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3 Modelagem do Problema
8
3.1 - Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2 - Barramento FPDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.3 - Modos de Operação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.4 - Software para Geração das PDWs . . . . . . . . . . . . . . . . . . . . . 12
3.5 - Interface com o Computador . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.6 - Interface de Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4 Ferramentas Utilizadas
17
4.1 - Altera . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
x
4.1.1 – FPGA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.1.2 – Quartus II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.1.3 – ModelSim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.2 - OrCAD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.2.1 – Capture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.2.2 – PCB Designer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.3 - QT Creator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5 Desenvolvimento
25
5.1 - Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.1.1 – FPGA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.1.2 – Placa de Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.1.2.1 – Diagrama de Blocos . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.1.2.2 – Esquemático . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.1.2.3 – PCI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.2 - Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.2.1 – GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.2.2 – Funcionamento Interno . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.3 - Interface Serial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.3.1 – Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.3.2 – Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
6 Resultados
54
6.1 - Simulações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
6.2 - Testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
xi
6.2.1 – IFM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
6.2.2 – EDIFM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
7 Conclusões 105
Bibliografia 107
xii
Lista de Figuras
2.1 – Exemplo de forma de onda de um radar pulsado . . . . . . . . . . . . . . . . . . . . 4
2.2 – Exemplo de modelo típico de IFM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1 – Funcionamento do “Single Frame Data” . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2 – Funcionamento dos sinais de clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3 – Funcionamento do sinal de SUSPEND* . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.4 – Pinagem do conector DB-9 (macho) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.5 – Protocolo de comunicação da interface serial RS-232 . . . . . . . . . . . . . . . . 14
3.6 – Diagrama de blocos simplificado de alto nível do EDIFM . . . . . . . . . . . . 16
4.1 – Altera Cyclone III Starter Kit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.2 – Placa de prototipação HSMC da Bitec . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.3 – Tela inicial do Quartus II 12.0 SP2 Web Edition, da Altera . . . . . . . . . . . 20
4.4 – Tela inicial do ModelSim 10.0d Starter Edition, da Altera . . . . . . . . . . . . 21
4.5 – Tela inicial do OrCAD Capture 16.3, da Cadence . . . . . . . . . . . . . . . . . . . 22
4.6 – Tela inicial do OrCAD PCB Designer 16.3, da Cadence . . . . . . . . . . . . . . 23
4.7 – Tela inicial do QT Creator 5.2.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.1 – Diagrama de blocos de alto nível do EDIFM . . . . . . . . . . . . . . . . . . . . . . . 27
5.2 – Diagrama da máquina de estados do programa “gerador_fpdp” . . . . . . . . 28
5.3 – Diagrama de blocos de baixo nível do EDIFM . . . . . . . . . . . . . . . . . . . . . 32
5.4 – Esquemático da Placa de Interface: Buffer 1, Buffer 2 e conector de 50
vias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.5 – Configuração dos sinais de entrada e saída do FPGA na placa
prototipadora . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.6 – Esquemático da Placa de Interface: Buffer 3, TTL-to-PECL, TTL-to-
LVTTL e resistores de terminação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
xiii
5.7 – Esquemático da Placa de Interface: RS232-to-TTL, TTL-to-RS232,
conector DB-9, conector FPDP e resistores de pull-up e pull-down . . . . . 38
5.8 – Esquemático da Placa de Interface: Chaves e resistor limitador de
corrente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.9 – Esquemático da Placa de Interface: 12V-to-5V e pads de alimentação . . . 39
5.10 – Esquemático da Placa de Interface: Capacitores de filtragem . . . . . . . . . 40
5.11 – Esquemático da Placa de Interface: LEDs e resistores limitadores de
corrente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.12 – Modelo em 3-D da Placa de Interface do EDIFM . . . . . . . . . . . . . . . . . . 41
5.13 – Modelo em 3-D da Placa de Interface do EDIFM, com roteamento . . . . 42
5.14 – Tela inicial do Programa Gerador de PDW do EDIFM (modelo S) . . . . 43
5.15 – Tela inicial do Programa Gerador de PDW do EDIFM (modelo K) . . . . 44
5.16 – Exemplo de uso do “Tooltip” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.17 – Mensagem de status indicativa de transmissão concluída e bem
sucedida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.18 – Exemplo de mensagem de status indicativa de erro na transmissão . . . . 47
5.19 – Diagrama de funcionamento da arquitetura da entidade uart_rx . . . . . . . 50
5.20 – Fluxograma que descreve a lógica do funcionamento interno do estado
“Aguarda PDW” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
6.1 – Simulação do sinal de clock_saida do modelo S . . . . . . . . . . . . . . . . . . 54
6.2 – Simulação do sinal de clock_saida do modelo K . . . . . . . . . . . . . . . . . . 55
6.3 – Simulação da PRI do modelo S no modo master . . . . . . . . . . . . . . . . . . . . 55
6.4 – Simulação da PDW do modelo S no modo master . . . . . . . . . . . . . . . . . . 56
6.5 – Simulação da PDW seguinte do modelo S no modo master . . . . . . . . . . . 57
6.6 – Simulação da PRI do modelo K no modo master . . . . . . . . . . . . . . . . . . . 57
6.7 – Simulação da PDW do modelo K no modo master . . . . . . . . . . . . . . . . . . 58
6.8 – Simulação da PDW seguinte do modelo K no modo master . . . . . . . . . . . 58
xiv
6.9 – Simulação do sinal de serial_entrada do modelo S no modo slave . . . . . . 59
6.10 – Simulação da PRI do modelo S no modo slave . . . . . . . . . . . . . . . . . . . . 60
6.11 – Simulação da PDW do modelo S no modo slave . . . . . . . . . . . . . . . . . . . 61
6.12 – Simulação da PDW seguinte do modelo S no modo slave . . . . . . . . . . . . 61
6.13 – Simulação do sinal de serial_entrada do modelo K no modo slave . . . . 62
6.14 – Simulação da PRI do modelo K no modo slave . . . . . . . . . . . . . . . . . . . . 62
6.15 – Simulação da PDW do modelo K no modo slave . . . . . . . . . . . . . . . . . . 63
6.16 – Simulação da PDW seguinte do modelo K no modo slave . . . . . . . . . . . 63
6.17 – Simulação da ativação do sinal de reset_n no modo master . . . . . . . . . . 64
6.18 – Simulação da desativação do sinal de reset_n no modo master . . . . . . . . 64
6.19 – Simulação da PDW na desativação do sinal de reset_n no modo master 65
6.20 – Simulação da ativação do sinal de reset_n no modo slave . . . . . . . . . . . . 65
6.21 – Simulação da desativação do sinal de reset_n no modo slave . . . . . . . . . 66
6.22 – Simulação da desativação do sinal de nao_pronto_n . . . . . . . . . . . . . . . . 66
6.23 – Simulação da ativação do sinal de nao_pronto_n . . . . . . . . . . . . . . . . . . 67
6.24 – Simulação da ativação do sinal de suspender_n no modo master . . . . . . 67
6.25 – Simulação da desativação do sinal de suspender_n no modo master . . . 68
6.26 – Simulação da ativação do sinal de suspender_n no modo slave . . . . . . . 68
6.27 – Simulação da desativação do sinal de suspender_n no modo slave . . . . . 69
6.28 – Simulação da ativação do sinal de on_off_n no modo master . . . . . . . . . 69
6.29 – Simulação da desativação do sinal de on_off_n no modo master . . . . . . 70
6.30 – Simulação da ativação do sinal de on_off_n no modo slave . . . . . . . . . . 70
6.31 – Simulação da desativação do sinal de on_off_n no modo slave . . . . . . . . 70
xv
6.32 – Simulação da transição do modelo S para o modelo K no modo master . 71
6.33 – Simulação da PDW na transição do modelo S para o modelo K no
modo master . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
6.34 – Simulação da transição do modelo S para o modelo K no modo slave . . 72
6.35 – Simulação da transição do modo de operação master para o slave . . . . . 72
6.36 – Simulação da transição do modo de operação slave para o master . . . . . 73
6.37 – Simulação da PDW na transição do modo de operação slave para o
master . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
6.38 – Teste do sinal de STROB do IFM referente ao modelo S . . . . . . . . . . . . 74
6.39 – Teste da PRI do IFM referente ao modelo S . . . . . . . . . . . . . . . . . . . . . . 75
6.40 – Teste da PDW do IFM referente ao modelo S . . . . . . . . . . . . . . . . . . . . . 76
6.41 – Teste da PDW anterior do IFM referente ao modelo S . . . . . . . . . . . . . . 76
6.42 – Teste do sinal de STROB do IFM referente ao modelo K . . . . . . . . . . . . 77
6.42 – Teste da PRI do IFM referente ao modelo K . . . . . . . . . . . . . . . . . . . . . . 77
6.43 – Teste da PDW do IFM referente ao modelo K . . . . . . . . . . . . . . . . . . . . . 78
6.44 – Teste da PDW anterior do IFM referente ao modelo K . . . . . . . . . . . . . . 78
6.45 – Protótipo em protoboard montado para a execução dos testes . . . . . . . . 79
6.46 – Hardware usado para os testes no analisador lógico . . . . . . . . . . . . . . . . 80
6.47 – Detalhe da placa de desenvolvimento FPGA conectada à placa
prototipadora . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
6.48 – Teste do sinal de clock_saida do modelo S . . . . . . . . . . . . . . . . . . . . . . . 82
6.49 – Teste do sinal de clock_saida do modelo K . . . . . . . . . . . . . . . . . . . . . . . 82
6.50 – Teste da PRI do modelo S no modo master . . . . . . . . . . . . . . . . . . . . . . . 83
6.51 – Teste da PDW do modelo S no modo master . . . . . . . . . . . . . . . . . . . . . . 84
6.52 – Teste da PDW seguinte do modelo S no modo master . . . . . . . . . . . . . . 84
xvi
6.53 – Teste da PRI do modelo K no modo master . . . . . . . . . . . . . . . . . . . . . . . 85
6.54 – Teste da PDW do modelo K no modo master . . . . . . . . . . . . . . . . . . . . . 86
6.55 – Teste da PDW seguinte do modelo K no modo master . . . . . . . . . . . . . . 86
6.56 – Configuração dos parâmetros de teste do modelo S no modo slave . . . . 87
6.57 – Teste do sinal de serial_entrada do modelo S no modo slave . . . . . . . . . 87
6.58 – Teste da PRI do modelo S no modo slave . . . . . . . . . . . . . . . . . . . . . . . . 88
6.59 – Teste da PDW do modelo S no modo slave . . . . . . . . . . . . . . . . . . . . . . . 89
6.60 – Teste da PDW seguinte do modelo S no modo slave . . . . . . . . . . . . . . . . 89
6.61 – Configuração dos parâmetros de teste do modelo K no modo slave . . . . 90
6.62 – Teste do sinal de serial_entrada do modelo K no modo slave . . . . . . . . 91
6.63 – Teste da PRI do modelo K no modo slave . . . . . . . . . . . . . . . . . . . . . . . . 91
6.64 – Teste da PDW do modelo K no modo slave . . . . . . . . . . . . . . . . . . . . . . . 92
6.65 – Teste da PDW seguinte do modelo K no modo slave . . . . . . . . . . . . . . . 92
6.66 – Teste da ativação do sinal de reset_n no modo master . . . . . . . . . . . . . . 93
6.67 – Teste da desativação do sinal de reset_n no modo master . . . . . . . . . . . . 93
6.68 – Teste da PDW na desativação do sinal de reset_n no modo master . . . . 94
6.69 – Teste da ativação do sinal de reset_n no modo slave . . . . . . . . . . . . . . . . 94
6.70 – Teste da desativação do sinal de reset_n no modo slave . . . . . . . . . . . . . 95
6.71 – Teste da desativação do sinal de nao_pronto_n . . . . . . . . . . . . . . . . . . . . 96
6.72 – Teste da ativação do sinal de nao_pronto_n . . . . . . . . . . . . . . . . . . . . . . 96
6.73 – Teste da ativação do sinal de suspender_n no modo master . . . . . . . . . . 97
6.74 – Teste da desativação do sinal de suspender_n no modo master . . . . . . . . 97
6.75 – Teste da ativação do sinal de suspender_n no modo slave . . . . . . . . . . . . 98
xvii
6.76 – Teste da desativação do sinal de suspender_n no modo slave . . . . . . . . . 98
6.77 – Teste da ativação do sinal de on_off_n no modo master . . . . . . . . . . . . . 99
6.78 – Teste da desativação do sinal de on_off_n no modo master . . . . . . . . . . . 99
6.79 – Teste da ativação do sinal de on_off_n no modo slave . . . . . . . . . . . . . . . 100
6.80 – Teste da desativação do sinal de on_off_n no modo slave . . . . . . . . . . . . 100
6.81 – Teste da transição do modelo S para o modelo K no modo master . . . . . 101
6.82 – Teste da PDW na transição do modelo S para o modelo K no modo
master . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
6.83 – Teste da transição do modelo S para o modelo K no modo slave . . . . . . 102
6.84 – Teste da transição do modo de operação master para o slave . . . . . . . . . 103
6.85 – Teste da transição do modo de operação slave para o master . . . . . . . . . 103
6.86 – Teste da PDW na transição do modo de operação slave para o master . . 104
xviii
Lista de Tabelas
5.1 – Estrutura da PDW do IFM de modelo S . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.2 – Estrutura da PDW do IFM de modelo K . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.3 – Valores predefinidos para os parâmetros dos pulsos no modo master . . . . . 30
5.4 – Codificação usada para os parâmetros do pulso no modelo S . . . . . . . . . . . . 48
5.5 – Codificação usada para os parâmetros do pulso no modelo K . . . . . . . . . . . . 48
1
Capítulo 1
Introdução
1.1 – Tema
O tema do trabalho é o desenvolvimento de um sistema capaz de emular um
equipamento IFM, o qual recebe sinais de radar em RF e disponibiliza, via barramento
FPDP, palavras digitais com informações de amplitude, frequência da portadora, largura
e tempo de chegada dos pulsos, entre outras. A ideia geral de funcionamento do sistema
é, então, permitir ao usuário selecionar, por meio de um software no computador, os
parâmetros desejados para os pulsos de um radar, cujas palavras digitais representativas
serão transmitidas via interface serial para um circuito de hardware dedicado utilizando
FPGA, o qual será responsável por disponibilizar de modo sincronizado tais dados no
formato padrão do barramento FPDP.
1.2 – Delimitação
O projeto ficará restrito à parte digital do equipamento, sendo o subsistema de
RF substituído por uma interface de software que permitirá ao usuário inserir os
parâmetros do pulso de radar que desejar emular, os quais serão transmitidos via
interface serial para o circuito de hardware dedicado, conforme apresentado no item
anterior.
1.3 – Justificativa
O projeto de um sistema como este poderá ser de grande utilidade para
organizações que trabalham com radar e Defesa Eletrônica, como as Forças Armadas,
por exemplo, principalmente no auxílio em testes de funcionamento de equipamentos
que utilizam diretamente os dados enviados por um IFM. Nesse sentido, como o
2
emulador será projetado de forma que possa substituir o IFM original, fornecendo um
padrão de saída idêntico ao dele, seu emprego permitiria maior rapidez na identificação
de defeitos e consequentemente na execução da manutenção daqueles equipamentos e
também do próprio IFM, já que procedimentos como este são normalmente trabalhosos
e demorados.
1.4 – Objetivos
Desse modo, o objetivo central deste projeto é desenvolver um sistema de
grande aplicabilidade e utilidade prática, usando-se dos conhecimentos adquiridos ao
longo de todo o curso de graduação em Engenharia Eletrônica e de Computação,
especialmente nas áreas de programação de software e hardware e projeto de circuitos
eletrônicos.
1.5 – Metodologia
O projeto se divide em três partes fundamentais: hardware, software e a interface
entre ambos. A metodologia utilizada priorizou o desenvolvimento do hardware
dedicado, a partir da programação do FPGA, a fim de que o mesmo fosse capaz de
sincronizar os dados e disponibilizá-los devidamente no formato padrão do barramento
FPDP. Com esta etapa do projeto finalizada, o circuito foi testado a partir de entradas de
dados simuladas pelo próprio FPGA, utilizadas para verificar se os sinais de saída
conferiam com o esperado. Para tanto, um modo de operação autônomo, que gera
padrões fixos, foi implementado com o intuito de tornar viável essa fase de testes
parciais.
Finalizada a programação do FPGA, mas ainda na fase de desenvolvimento do
hardware dedicado, foi iniciado o projeto de uma placa de interface, a qual seria
responsável por promover a interconexão dos sinais de I/O do FPGA, com os enviados
pela porta serial e para o barramento FPDP, garantindo também a integridade e a
perfeita compatibilidade dos mesmos com os padrões do referido barramento.
Tendo feito isso, a próxima etapa diz respeito à programação do software a ser
manuseado pelo usuário para selecionar os parâmetros do sinal de radar enviados ao
3
hardware dedicado. Foi desenvolvido não só o programa com todo o código-fonte que
implementa as funções desejadas como também uma GUI de fácil utilização.
Por fim, para viabilizar a comunicação do FPGA com o computador, foi
realizado também o projeto da uma interface serial, tanto no lado do software como no
lado do hardware, a qual será responsável por conduzir os sinais de saída gerados pelo
programa para a porta serial do computador e viabilizar sua leitura pelo circuito com
FPGA.
1.6 – Descrição
O capítulo 2 introduzirá os principais conceitos envolvidos e necessários para o
entendimento deste trabalho.
O capítulo 3 tratará da modelagem do problema, especificando os requisitos do
projeto e descrevendo suas funcionalidades.
No capítulo 4 serão descritas as ferramentas empregadas para concretizar cada
uma das etapas do projeto, tanto de hardware como de software.
O capítulo 5 apresenta o desenvolvimento detalhado de cada uma dessas etapas.
Os resultados finais do funcionamento do equipamento são apresentados no
capítulo 6. Nele serão explicitados os testes feitos e seus respectivos resultados parciais.
A conclusão do trabalho será apresentada no capítulo 7.
4
Capítulo 2
Radar e IFM
2.1 – Radar [1]
Um radar é essencialmente um equipamento para detecção e medição de
distâncias por meio de ondas eletromagnéticas de RF. Sendo um acrônimo para RAdio
Detection And Ranging, este dispositivo baseia-se em uma técnica cujo princípio é o
envio de um sinal que, refletindo em um alvo, torna possível o cálculo da sua distância
até o transmissor por meio do tempo de chegada deste sinal refletido de volta ao ponto
de onde ele foi transmitido.
Para serem capazes de realizar esta função, tais equipamentos se utilizam de
diversos tipos de sinais, que caracterizam igualmente o tipo de radar utilizado. O mais
simples e comum deles é o radar pulsado. Um exemplo de forma de onda típica de um
radar pulsado está ilustrado na Figura 2.1.
Figura 2.1 – Exemplo de forma de onda de um radar pulsado.
Nela, podem-se observar quatro parâmetros relevantes que caracterizam o pulso.
São eles: frequência da portadora (Radar Carrier Frequency), amplitude (PA), largura
de pulso (PW ou LP) e intervalo de repetição de pulso (PRI).
A frequência da portadora é a frequência na qual o oscilador que gera a onda de
alta frequência está sintonizado. Esta frequência costuma estar na faixa de micro-ondas,
em geral entre centenas de MHz até dezenas de GHz, a fim de garantir longo alcance de
5
transmissão, grande precisão nas medidas e diminuição das dimensões do transmissor e
do receptor. Um valor típico para a frequência da portadora é 9 GHz.
A amplitude do pulso, por sua vez, consiste no valor de pico do sinal modulador,
em geral medido em unidades de potência, como o dBm. Um valor de amplitude
comumente utilizado é -50 dBm.
A LP é definida como a duração de cada pulso de radar, isto é, o tempo em que
o radar está “iluminando”. Este tempo é normalmente medido em ns ou µs, e um valor
recorrente de largura de pulso pode ser, por exemplo, 1 µs.
Finalmente, por PRI entende-se o período entre cada um dos pulsos de radar, em
outras palavras, o intervalo de repetição entre os mesmos. Seu inverso, conhecido como
PRF, consiste na frequência (taxa) de repetição dos pulsos. Para a PRI, as medidas são
em geral realizadas na escala de ms ou µs, ao passo que para a PRF, kHz ou MHz.
Valores típicos são 1 ms para a PRI e 1 kHz para a PRF.
As aplicações práticas dos radares são muitas. Para citar algumas delas, vale
ressaltar as seguintes: geográficas e geológicas, no mapeamento de terrenos; climáticas,
na detecção de chuva, aerossóis e outros elementos presentes na atmosfera; de
fiscalização, na medição de velocidade em estradas; e militares, na identificação de
alvos inimigos em navios e aeronaves das Forças Armadas.
Tomando-se o último exemplo mencionado, pode-se imaginar a situação real de
um navio que esteja patrulhando a costa. Para esta aplicação em específico, é de vital
importância tomar conhecimento dos tipos de sinais radar que estão atingindo essa
embarcação, a fim de identificar os radares utilizados e assim classificar os emissores
como amigos, neutros ou hostis. Para cumprir tal função, portanto, faz-se necessário o
emprego de um equipamento dotado da capacidade de extrair dos sinais desses radares
os parâmetros básicos definidos nos parágrafos anteriores, tornando possível a
caracterização e classificação da maior parte dos radares pulsados empregados
atualmente. Assim sendo, uma das maneiras mais eficientes de fazê-lo é com a
utilização do equipamento conhecido como IFM.
2.2 – IFM
Originalmente, os equipamentos IFM foram concebidos para realizar medições
apenas da frequência da portadora de pulsos de radar, como o próprio nome sugere. No
6
entanto, com a crescente demanda e o desenvolvimento tecnológico, novas funções de
medição foram incorporadas ao mesmo equipamento, tais como: amplitude, LP, TOA;
até outras mais elaboradas, como FMOP, PMOP, detecção de CW, etc.
Em geral, um receptor IFM possui uma conexão de entrada com uma antena
omnidirecional, da qual recebe sinais de RF vindos de todas as direções, que são
digitalizados e processados a fim de serem retiradas as informações desejadas dos
parâmetros dos pulsos. A conexão de saída, por sua vez, é um barramento digital, no
qual são disponibilizados dados codificados referentes aos parâmetros medidos dos
pulsos.
Existem diversos modelos de IFM disponíveis no mercado, cada qual com as
suas especificações próprias. Um exemplo de especificação bastante característica e que
é na maioria dos casos utilizada para diferenciar um modelo de outro é a banda de
operação, que pode ser de 50 a 500 MHz, 0,5 a 2 GHz, 2 a 18 GHz, dentre outras
combinações. Na Figura 2.2 encontra-se um modelo típico de IFM, operando na banda
S (pág. 84 de [1]).
Figura 2.2 – Exemplo de modelo típico de IFM.
Para os fins de emulação, foram idealizados dois modelos de IFM distintos, com
características ligeiramente diferentes de banda de operação, resolução e parâmetros
medidos. Isso demonstra a flexibilidade deste projeto, de modo que as especificações do
emulador podem ser modificadas facilmente, caso seja preciso, por exemplo, emular um
modelo diferente de IFM.
Ambos os modelos emulados, no entanto, possuem um padrão de saída
semelhante entre si: a disponibilização, no barramento FPDP, de uma palavra digital, ou
7
seja, um vetor de bits, que descreve as características do pulso. Esta palavra é
denominada PDW, possuindo um total de 96 bits para a descrição completa do pulso.
As definições do conteúdo das PDWs e das especificações de cada modelo
emulado foram feitas com base em pesquisas realizadas sobre diversos modelos
diferentes. Tais definições serão apresentadas e detalhadas mais adiante, no capítulo 5.
8
Capítulo 3
Modelagem do Problema
3.1 – Introdução
Antes de apresentarem-se as ferramentas utilizadas para o desenvolvimento
deste projeto, o que será feito no capítulo 4, e detalhar-se o desenvolvimento em si, no
capítulo 5, é necessário modelar o problema. Nas seções que se seguem, portanto, serão
especificados os requisitos do projeto e apresentadas as principais funcionalidades, tanto
de hardware quanto de software, que o Emulador do IFM deverá possuir.
3.2 – Barramento FPDP [2]
Primeiramente, é de fundamental importância o conhecimento mais aprofundado
do padrão de funcionamento do barramento usado para transferência das palavras
digitais em ambos os modelos de IFM escolhidos. Denominado FPDP, ele consiste de
um barramento paralelo síncrono de 32 bits de dados, cuja conexão é feita por um cabo
em forma de fita contendo 80 condutores. A documentação desse barramento contém o
detalhamento do protocolo de comunicação utilizado pelo mesmo, bem como outras
características técnicas importantes.
A partir dessa documentação, tem-se que o IFM deve operar segundo o padrão
“FPDP Transmitter Master”, pois faz a função de transmissor no circuito. Por isso
também ele deve possuir um circuito de interface que permita levar os sinais através do
barramento mantendo a integridade dos mesmos. Este circuito será visto com mais
detalhes na seção 5.1.2.
Adicionalmente, o protocolo define como frame de dados uma sequência de
dados consecutivos, cujo início ou fim é identificado por um sinal de sincronismo. No
caso deste projeto, o formato do frame de dados é definido como “Single Frame Data”.
Nesse formato, o pulso de sincronismo deve ser enviado antes do início da transmissão
dos dados no barramento, a fim de avisar ao receptor para que este se prepare para
9
receber tais dados. Esse mecanismo, implementado pelo sinal de SYNC* (negado),
permite ao receptor, por exemplo, enquanto aguarda o pulso de sincronismo, trabalhar o
hardware para deixar livre o caminho de dados, a fim de poder recebê-los e tratá-los de
forma correta. Um detalhe importante é que, para esse formato, somente são permitidos
frames de tamanhos (durações) iguais.
Após o pulso de SYNC*, com o objetivo de certificar a validade dos dados no
barramento ao longo da transmissão, deve ser habilitado o sinal de DVALID* (negado).
Dessa forma, caso o sinal de DVALID* estiver em nível lógico alto durante uma
transmissão, o receptor deve automaticamente ignorar todo e qualquer dado presente no
barramento. A Figura 3.1 ilustra o funcionamento desse formato de transmissão, onde
D<31:00> representa o barramento de dados de 32 bits.
Figura 3.1 – Funcionamento do “Single Frame Data”.
Como qualquer protocolo de comunicação síncrono, o FPDP precisa de um sinal
de clock para controlar a velocidade das trocas de dados, em cuja borda de descida os
dados são disponibilizados pelo transmissor, e na de subida eles são amostrados pelo
receptor. Essa função pode ser cumprida tanto pelo sinal de STROB apenas, quanto por
ambos os sinais de PSTROBE (PSTROBE+ e PSTROBE-), os quais formam um sinal
diferencial, no formato PECL, servindo como uma alternativa mais robusta em
comparação ao STROB, já que o formato diferencial é mais imune a ruído e
interferências, permitindo operação a taxas de clock mais elevadas (no caso do FPDP,
maiores que 20 MHz). Portanto, fica a cargo do projetista do equipamento, levando em
conta seus requisitos de funcionamento, utilizar como referência o clock TTL STROB
ou o clock PECL PSTROBE.
10
Para ilustrar a aplicação dos referidos sinais de clock, é apresentado o gráfico da
Figura 3.2, que demonstra a variação ao longo do tempo do sinal de DVALID* e do
barramento D<31:00> mediante os dois tipos de clock.
Figura 3.2 – Funcionamento dos sinais de clock.
Além dos já definidos até então, mais alguns sinais são necessários para permitir
o pleno funcionamento da comunicação através do FPDP. São eles:
DIR*
Direção da transmissão (fixo em nível lógico baixo para o
transmissor).
NRDY*
Not Ready. Deve ser mantido ativado em nível lógico baixo pelo
receptor antes do início da transmissão, enquanto ele ainda não
estiver pronto para receber os dados. Assim que for colocado em
nível alto, o transmissor passa a não mais amostrar este sinal.
SUSPEND*
Suspend Data. Também deve ser ativado em nível lógico baixo
pelo receptor para informar ao transmissor da ocorrência de
buffer overflow. Quando ativado, o transmissor tem até 16 ciclos
de clock para suspender a transmissão, isto é, colocar o sinal de
DVALID* em nível lógico alto.
A lógica de funcionamento do sinal de SUSPEND* encontra-se ilustrada na
Figura 3.3.
11
Figura 3.3 – Funcionamento do sinal de SUSPEND*.
Dessa maneira, como cada PDW transmitida pelo IFM contém 96 bits e o
barramento possui apenas 32 bits, são necessários 3 ciclos de clock para transmiti-la.
Essa quantidade de ciclos, então, somada ao ciclo compulsório de sincronismo
imediatamente anterior à transmissão da primeira palavra de 32 bits, e a no mínimo um
ciclo ocioso (“idle”) após a terceira e última palavra, resulta em um total de 5 ciclos de
clock para cada PDW.
3.3 – Modos de Operação
O Emulador do IFM deverá possuir dois modos de operação distintos,
selecionados pelo usuário: master e slave.
No modo master, um emissor radar fixo será automaticamente emulado pelo
EDIFM. O conteúdo das PDWs a serem transmitidas no barramento, isto é, os
parâmetros dos pulsos desse emissor, serão predefinidos no próprio programa do FPGA,
de modo que o usuário não terá acesso aos mesmos. Recomenda-se o uso deste modo,
por exemplo, no caso da indisponibilidade de um computador, impossibilitando o
usuário de configurar os parâmetros desejados para o pulso.
O modo slave, por sua vez, exige, além de um computador com o arquivo
executável do software que gera as PDWs e de ser capaz de rodá-lo, a existência de uma
interface com o computador. Apesar de ter os referidos pré-requisitos, este modo é o
mais recomendado para o usuário que necessita de uma flexibilidade maior para o
Emulador, já que ele permite a personalização dos valores dos parâmetros do pulso
através de uma ampla gama de combinações possíveis.
12
3.4 – Software para Geração das PDWs
A fim de permitir ao usuário configurar os parâmetros desejados para os pulsos
do emissor radar, operando o Emulador no seu modo slave, será necessário desenvolver
um software com uma GUI de fácil manuseio, com uma interface intuitiva.
Ela deverá possuir: dois botões de lógica exclusiva, para a seleção do modelo de
IFM a ser emulado; campos para o preenchimento dos valores de parâmetros como
frequência da portadora, amplitude, LP, PRI e PRF (estes dois utilizando-se campos
especiais, denominados intertravados, de forma que, quando se preenche um, o outro é
automaticamente preenchido com o valor inverso); um botão do tipo push-button para
gerar as PDWs e transmiti-las na porta serial; e uma barra de status para efeitos de
acompanhamento dos processos de geração e transmissão por parte do usuário.
O software será chamado de Programa Gerador de PDW do Emulador do IFM, e
precisará ter funções específicas dedicadas à leitura dos dados preenchidos pelo usuário
na GUI, outras dedicadas à codificação desses valores em forma de vetores de bits, uma
dedicada à geração das três palavras formadoras da PDW, e outra para implementar a
transmissão das PDWs para o EDIFM, através de interface a ser definida.
3.5 – Interface com o Computador
Conforme o que foi apresentado na seção 3.3, para permitir o funcionamento do
modo slave, faz-se necessária uma interface entre o computador, onde serão geradas as
PDWs, e o EDIFM, que irá sincroniza-las para o FPDP. A interface escolhida é a
interface serial padrão RS-232, em virtude da sua simplicidade, facilidade de
programação e praticidade de implementação em hardware.
O protocolo de comunicação da interface serial é assíncrono, isto é, o clock
usado para sincronizar a transmissão dos bits não é transmitido, e bidirecional full-
duplex, o que significa que o computador pode enviar e receber dados ao mesmo tempo,
com taxa máxima de transmissão de aproximadamente 10 kBps.
O conector atualmente empregado nessa interface, juntamente com sua pinagem,
estão representados na Figura 3.4. Para o caso específico do padrão serial RS-232,
13
entretanto, somente são utilizados os pinos 2, 3 e 5, os quais representam
respectivamente os sinais de RXD, TXD e GND.
Figura 3.4 – Pinagem do conector DB-9 (macho).
O funcionamento básico desse protocolo encontra-se exemplificado na Figura
3.5. Nesse exemplo, é transmitido na porta serial o caractere ASCII equivalente à letra
“v”, em binário, 01010110. Na figura, o eixo das ordenadas do gráfico debaixo contém
os valores de tensão assumidos pelo sinal de TXD ao longo de uma transmissão. Estes
valores podem variar dependendo da implementação, mas sempre dentro da faixa de +3
a +15 V para nível lógico baixo (“espaço”) e -3 a -15 V para nível lógico alto
(“marca”). Os níveis lógicos equivalentes estão representados no gráfico de cima.
Quando a linha está ociosa, o sinal é mantido em nível lógico alto. No ciclo
imediatamente anterior ao início de uma transmissão, a linha de TXD deve ser colocada
em nível lógico baixo, caracterizando o chamado bit de start, para alertar ao receptor do
início da transmissão dos dados no próximo ciclo. A transmissão então ocorre bit a bit,
do LSB para o MSB, totalizando os 8 bits que formam um byte. Imediatamente após o
último bit, é enviado um bit de valor 1, sinalizando o fim da transmissão do byte. Tal bit
é denominado bit de stop.
Opcionalmente, dependendo da configuração, também pode haver um bit de
paridade, par ou ímpar, anterior ao bit de stop, caracterizando a implementação de um
14
algoritmo simples de detecção de erro. No exemplo da Figura 3.5, foi empregada
paridade ímpar.
Figura 3.5 – Protocolo de comunicação da interface serial RS-232.
A partir dessas informações, conclui-se que essa é de fato uma interface de
implementação razoavelmente simples, e que ao mesmo tempo atende às especificações
do projeto. Sendo assim, precisará ser desenvolvida uma UART, a qual será responsável
por estabelecer a comunicação no protocolo serial especificado nesta seção,
possibilitando a transferência das PDWs do computador para o EDIFM. O projeto da
mesma será dividido em dois módulos: no lado do software gerador haverá o módulo
transmissor, o qual será responsável por enviar as PDWs geradas para a porta serial, e,
no lado do EDIFM, o módulo receptor, para receber estas PDWs na linha serial,
armazená-las e sincroniza-las no barramento.
3.6 – Interface de Hardware
Em se tratando de hardware, é necessária não só uma interface para a
compatibilização dos níveis dos sinais elétricos, como também uma interface para o
usuário, tanto para entrada de dados quanto para indicação de sinais de saída. No caso
da compatibilização elétrica, são exigidos os circuitos de interface com o barramento
FPDP e conversores de níveis de tensão, tanto para o EDIFM quanto para o RS-232.
15
Para a entrada e saída de dados são necessários, respectivamente, chaves de duas
posições, para os sinais de on_off_n, modo_operacao e modelo_ifm, e LEDs de
indicação, para a verificação da integridade das alimentações do circuito e de
transmissão ativa no barramento. Além disso, é preciso também espaço para a
acomodação dos conectores DB-9, para a interface serial, e FPDP.
Por esses motivos, optou-se por desenvolver uma PCI que fosse capaz de
comportar e interligar todos os componentes necessários para esse conjunto de
interfaces. Tal PCI foi denominada Placa de Interface do Emulador do IFM.
Além disso, a forma de implementação escolhida para fazer a sincronização dos
dados no formato do barramento FPDP descrito na presente seção foi a utilização de um
FPGA, com programação na linguagem VHDL, em virtude principalmente do
conhecimento prévio no domínio dessa tecnologia e linguagem e da disponibilidade dos
componentes necessários. O emprego do FPGA possibilitou a descrição da lógica desse
barramento aplicado ao IFM de forma a emular com fidelidade suas características e
especificidades.
Finalmente, apenas para representar de modo geral o sistema, a Figura 3.6
consiste de um diagrama de blocos de alto nível, mostrando de maneira simplificada o
relacionamento até então existente entre os módulos citados ao longo deste capítulo.
16
Figura 3.6 – Diagrama de blocos simplificado de alto nível do EDIFM.
17
Capítulo 4
Ferramentas Utilizadas
4.1 – Altera
4.1.1 – FPGA
Para a realização do projeto foi utilizado um kit de desenvolvimento com FPGA
Altera, denominado Cyclone III Starter Kit (Figura 4.1). A placa que pertence a esse kit
contém, dentre outros componentes: chip FPGA de modelo EP3C25 com 324 pinos,
214 deles de I/O, 25k elementos lógicos e 4 PLLs; um chip de cada tipo de memória,
incluindo SRAM (1 MB), DDR SDRAM (32 MB) e Flash (16 MB), tendo esta última a
funcionalidade de permitir ao usuário carregar um programa e gravá-lo na mesma, o
qual se manterá gravado mesmo se cortada a alimentação (memória não-volátil); clock
de 50 MHz gerado por oscilador a cristal; 4 botões configuráveis como sinais de entrada
definidos pelo usuário; 4 LEDs de indicação configuráveis como sinais de saída
igualmente definidos pelo usuário; conector para barramento HSMC, para acesso aos
pinos de alimentação da placa (12 V e 3,3 V) e I/O do FPGA; e interface USB-Blaster
para carregamento dos programas a serem executados.
18
Figura 4.1 – Altera Cyclone III Starter Kit.
Além disso, com o intuito de obter acesso direto aos pinos de alimentação e I/O
do FPGA através do barramento HSMC, fez-se necessário o uso da placa de
prototipação HSMC, da fabricante Bitec. A placa é mostrada na Figura 4.2, onde, à
esquerda, tem-se a vista inferior da mesma (conector HSMC aparente) e, à direita, sua
vista superior.
Figura 4.2 – Placa de prototipação HSMC da Bitec.
19
4.1.2 – Quartus II
O Quartus II, da Altera, é um software poderoso para projeto de circuitos de
lógica programável, como o FPGA. Tal projeto pode ser feito de dois modos distintos.
Um deles é através de diagramas de blocos, com cada bloco representando uma função
lógica sequencial, como um flip-flop, um contador, um registrador de deslocamento,
dentre muitas outras; ou combinacional, como uma porta NAND, um multiplexador, um
codificador de prioridade, etc. O outro modo é o uso das linguagens de descrição de
hardware, como o VHDL, pelas quais o projetista descreve em forma de código a
arquitetura e o comportamento desejado para o circuito.
Após ter sido feita a descrição do hardware, por qualquer um dos modos
mencionados no parágrafo anterior, o processo geral de elaboração do programa que
será rodado no FPGA se dá em três etapas: primeiro, o código gerado deve passar pelo
processo de compilação, a fim de que seja convertido em comandos de baixo nível para
o hardware; não havendo nenhum erro na etapa de compilação, o próximo passo
consiste no mapeamento de todos os sinais de entrada e saída do programa nos pinos de
I/O do FPGA, etapa esta que permite ao projetista optar pela configuração de pinagem
que seja mais conveniente para o seu projeto; e por último a etapa de gravação do
programa no chip, a qual é em geral implementada por meio da interface USB do
computador (USB-Blaster).
Para o presente trabalho foi utilizada a versão 12.0 SP2 Web Edition do referido
programa, que pode ser encontrada com licença gratuita [3]. Além disso, o modo
empregado para a elaboração do projeto foi aquele por meio de uma linguagem de
descrição de hardware, no caso, o VHDL. A lógica implementada no programa será
explicada com maior grau de detalhamento na seção 5.1.2. A tela inicial do software
pode ser vista na Figura 4.3.
20
Figura 4.3 – Tela inicial do Quartus II 12.0 SP2 Web Edition, da Altera.
4.1.3 – ModelSim
Conforme foi explicado na seção anterior, os procedimentos necessários para a
programação no chip da lógica descrita pelo projetista são, em suma: compilação,
mapeamento dos pinos e gravação. No entanto, entre as etapas de compilação e
mapeamento é possível, e também altamente recomendado, inserir uma etapa a mais
neste processo: a simulação. Simular o circuito projetado é em geral uma maneira
simples, não custosa e bastante eficiente de verificar se a lógica do circuito projetado
está se comportando da maneira esperada.
Para executar tal função, pode ser empregado o software ModelSim, também da
Altera, o qual permite ao usuário avaliar o funcionamento do circuito a partir da
visualização dos respectivos diagramas de tempo de cada um dos sinais definidos no
projeto. Assim sendo, é possível, por exemplo, atribuir um valor de período para um
sinal de clock e/ou atribuir níveis lógicos (0s ou 1s) a sinais de entrada, para então
monitorar os níveis lógicos dos sinais de saída, a fim de compará-los com os resultados
esperados.
Por essa razão, foi utilizado neste projeto o Altera ModelSim 10.0d Starter
Edition, o qual é compatível com a versão do Quartus II utilizada. Em [4] pode-se
encontrar essa versão do software disponível gratuitamente, e cuja tela inicial está
apresentada na Figura 4.4.
21
Figura 4.4 – Tela inicial do ModelSim 10.0d Starter Edition, da Altera.
4.2 – OrCAD
O OrCAD é um software da Cadence cuja funcionalidade é o projeto de
circuitos eletrônicos analógicos e digitais. Ele possui diversas ferramentas distintas,
como o Capture, PSpice, PCB Designer, entre outros.
A primeira é usada para o desenho do esquemático do circuito, através da
inserção dos modelos dos componentes e da interconexão dos mesmos por meio de fios.
O PSpice, por sua vez, permite ao usuário projetista executar simulações sobre o
circuito desenhado, simulações estas que podem ser de polarização, transiente, resposta
em frequência do circuito, etc. A última ferramenta citada é utilizada para o desenho da
PCI do circuito criado no Capture, a partir do dimensionamento da placa e seus
atributos, como largura das trilhas e tamanho das ilhas, posicionamento dos
componentes na placa e roteamento das ligações entre eles.
4.2.1 – Capture
22
A versão do OrCAD Capture empregada para o projeto do circuito da Placa de
Interface do Emulador do IFM é a 16.3, a qual pode ser obtida no website do OrCAD
[5]. A título de ilustração, na Figura 4.5 encontra-se a tela inicial do Capture.
Figura 4.5 – Tela inicial do OrCAD Capture 16.3, da Cadence.
4.2.2 – PCB Designer
Da mesma maneira, a versão do PCB Designer utilizada para o desenho da placa
de circuito impresso da Placa de Interface do Emulador do IFM foi a incluída no
OrCAD 16.3. A Figura 4.6, abaixo, mostra a tela inicial do PCB Designer.
23
Figura 4.6 – Tela inicial do OrCAD PCB Designer 16.3, da Cadence.
4.3 – QT Creator
Para o desenvolvimento do Gerador de PDW do Emulador do IFM, foi usado o
software QT Creator, que proporciona um ambiente de programação completo para a
linguagem C++, juntamente com uma ferramenta bastante intuitiva para elaboração de
layout de GUI, denominada QT Designer, proporcionando compatibilidade de operação
multiplataforma. A versão utilizada para este trabalho é a 5.2.1, fornecida gratuitamente
no website do QT [6]. A tela inicial deste software é apresentada na Figura 4.7.
24
Figura 4.7 – Tela inicial do QT Creator 5.2.1.
25
Capítulo 5
Desenvolvimento
5.1 – Hardware
5.1.1 – FPGA
A fim de implementar no FPGA a lógica de geração síncrona das PDWs
disponibilizadas no barramento FPDP, exatamente do mesmo modo como a mesma é
empregada pelo equipamento de IFM, foi desenvolvido um programa na linguagem
VHDL, cujo código está contido em um projeto denominado “gerador_fpdp”. Suas
entradas e saídas, juntamente com uma breve descrição de cada um dos sinais que as
representam, são apresentadas a seguir.
Entradas:
clock_entrada
Clock interno do FPGA, de frequência igual a 50 MHz.
reset_n
Sinal de reset (negado) que permite ao usuário reinicializar todo
o sistema para sua configuração original.
on_off_n
Sinal (negado) que permite ao usuário desligar a transmissão sem
desconectar o equipamento da alimentação.
nao_pronto_n
Sinal que implementa a função do sinal de NRDY*, padrão do
FPDP.
suspender_n
Sinal que implementa a função do sinal de SUSPEND*, padrão
do FPDP.
modo_operacao
26
Sinal que permite ao usuário selecionar um dentre os dois
possíveis modos de operação do sistema. Quando em nível lógico
baixo, seleciona o modo slave, já em nível lógico alto, o modo
master é selecionado.
modelo_ifm
Sinal que permite ao usuário selecionar um dentre os dois
possíveis modelos de IFM, denominados modelo S e modelo K, a
ser emulado. Quando em nível lógico baixo, seleciona o modelo
S, ao passo que, em nível lógico alto, o modelo K é selecionado.
serial_entrada
Sinal que é conectado ao sinal de TX vindo da interface serial, já
no padrão LVTTL, usado para receber no FPGA os bits que
compõem a PDW enviada pelo software no computador.
Saídas:
clock_saida
Clock de saída do PLL configurado no FPGA, que pode ser de 20
MHz (modelo S) ou 40 MHz (modelo K), cuja borda de descida é
usada para comandar as transições de estado do sistema.
Implementa a função do sinal de STROB, padrão do FPDP.
direcao_n
Sinal que implementa a função do sinal de DIR*, padrão do
FPDP.
sync_n
Sinal que implementa a função do sinal de SYNC*, padrão do
FPDP.
dado_valido_n
Sinal que implementa a função do sinal de DVALID*, padrão do
FPDP.
dados
Vetor de 32 bits que implementa a função do sinal de D<31:00>,
padrão do FPDP.
serial_saida
27
Sinal que é conectado ao sinal de RX da interface serial, ainda no
padrão LVTTL, usado para possibilitar o envio de bits do FPGA
para o software no computador. Este sinal não é utilizado nesta
versão de implementação do Emulador, sendo a comunicação
apenas unidirecional, no sentido do computador para o FPGA.
Tendo-se tomado conhecimento de todos os sinais necessários para a
programação do FPGA, é possível esboçar, agora com maior grau de detalhamento, um
diagrama atualizado para o diagrama de blocos simplificado de alto nível ilustrado na
Figura 3.6 da seção 3.6. Tal diagrama, agora um pouco mais detalhado, encontra-se
desenhado na Figura 5.1.
Figura 5.1 – Diagrama de blocos de alto nível do EDIFM.
Com relação à lógica de sincronismo necessária para a transferência das PDWs,
sua implementação foi realizada utilizando-se uma máquina de estados síncrona. Tal
28
máquina é classificada como Máquina de Moore, em virtude do fato de que seus sinais
de saída são disponibilizados durante a execução de cada estado, e não na transição
entre os mesmos (Máquina de Mealy). A Figura 5.2 apresenta o diagrama de estados
dessa máquina.
Figura 5.2 – Diagrama da máquina de estados do programa “gerador_fpdp”.
Primeiramente, antes de entrar na máquina de estados propriamente dita, o
programa executa uma lógica condicional que define o valor atribuído ao clock_saida.
Tal lógica atua de modo que, caso o modelo de IFM selecionado seja o modelo S,
clock_saida recebe o valor de frequência de 20 MHz. Por outro lado, caso a seleção seja
pelo modelo K, clock_saida recebe então o valor de 40 MHz. Estes valores são ambos
gerados por um dos PLLs do chip FPGA, que, tendo sido devidamente configurado, por
intermédio de uma ferramenta do próprio Quartus II denominada Megafunction
“ALTPLL”, é capaz de dividir o clock interno de 50 MHz para gerar os referidos clocks
de 20 e 40 MHz.
Tendo-se estabelecido o valor da frequência do sinal de clock_saida, é calculado
também nesta etapa o número total de ciclos de clock relativos à PRI definida no modo
29
master, cujo valor final fica guardado na variável ciclos_PRI, a partir do cálculo
realizado da seguinte forma:
ciclos_PRI = frequênciaclock (Hz) × PRI (s) × 5. (1)
O valor da variável ciclos_PRI será utilizado nos estados “PDW0” e “Aguarda
TOA”.
O primeiro estado é denominado “Início”. Nesse estado é garantido que se tenha
os sinais de sync_n e dado_valido_n em nível lógico alto, enquanto todos os bits do
vetor de dados são mantidos em nível baixo. O sinal que controla a passagem para o
próximo estado é o sinal de nao_pronto_n, sendo que a máquina de estados somente
passará para o próximo estado, isto é, “Aguarda PDW”, quando nao_pronto_n = 1.
O estado “Aguarda PDW” implementa o armazenamento das PDWs recebidas
na porta serial, no caso de modo de operação slave. Por essa razão, ele será abordado
apenas na seção 5.3.
Os estados subsequentes, “PDW0”, “PDW1” e “PDW2”, possuem lógica
semelhante entre si, já que nos três é garantido que sync_n = 1 e dado_valido_n = 0,
respeitando os padrões do barramento. A diferença entre eles reside no fato de que cada
um é responsável por disponibilizar no barramento, respectivamente, a primeira, a
segunda e a terceira palavras de 32 bits da PDW completa, totalizando seus 96 bits. A
estrutura da PDW varia conforme os modelos de IFM. Por isso, foram escolhidas duas
estruturas ligeiramente diferentes para serem implementadas. A Tabela 5.1 apresenta a
estrutura da PDW do modelo S, ao passo que a Tabela 5.2 apresenta a do modelo K.
Tabela 5.1 – Estrutura da PDW do IFM de modelo S.
PDW0
PDW1 LP [D31:16] Reservado [D15:14]
PDW2 Reservado [D31:8] Amplitude [D7:0]
TOA [D31:0]
Frequência [D13:0]
Tabela 5.2 – Estrutura da PDW do IFM de modelo K.
PDW0
PDW1 Reservado [D0]
PDW2
TOA [D31:0]
LP [D31:16] Frequência [D15:1]
Amplitude [D7:0]Reservado [D31:8]
30
No modo master, os valores desses parâmetros são predefinidos no próprio
programa, em forma de constantes, tendo sido escolhidos convenientemente valores
típicos para os mesmos. A Tabela 5.3 informa os valores respectivamente aos
parâmetros do pulso, levando em consideração as diferenças entre os dois modelos.
Tabela 5.3 – Valores predefinidos para os parâmetros dos pulsos no modo master.
Parâmetro do Pulso Valor
Modelo S Modelo K
Frequência da Portadora (GHz) 2 9
Amplitude (dBm) -40
LP (μs) 1
PRI (ms) 1
Reservado 0
Sendo assim, o estado “PDW0” disponibiliza em seus 32 bits o valor do TOA. É
convencionado que o TOA do primeiro pulso é sempre zerado, ao passo que os
subsequentes são gerados cada qual somando-se o valor fixo definido para a PRI com o
valor atual do TOA acumulado até aquele estado. Caso este valor fique maior ou igual
ao valor máximo do TOA (o valor máximo ocorre quando o vetor de 32 bits está todo
em nível lógico alto), o valor máximo é então diminuído do valor acumulado,
resultando em um novo valor acumulado, o qual será disponibilizado já no estado atual.
No estado “PDW1”, por sua vez, são transmitidos os valores de LP e frequência
da portadora, além de bits reservados para futura implementação.
Já o estado “PDW2” é responsável por disponibilizar no barramento dados de
amplitude e bits reservados.
O estado seguinte é chamado “Aguarda TOA”, possuindo como principal função
a contagem dos ciclos de clock equivalentes à PRI definida no programa. É utilizada
para esse fim a variável contador_TOA, a qual é incrementada a cada ciclo de clock, de
modo que a máquina muda de estado quando o valor deste contador se igualar ao valor
da variável ciclos_PRI, descontando os três ciclos equivalentes aos estados “PDW0”,
“PDW1” e “PDW2”, isto é,
31
contador_TOA = ciclos_PRI – 3. (2)
No ciclo onde ocorrerá essa mudança de estado, a lógica implementada faz com
que sync_n = 0, preparando o início da transmissão da PDW no estado seguinte
(“PDW0”), além de zerar a variável contador_TOA. Mesmo assim, enquanto não ocorre
tal mudança de estado, a lógica garante que os sinais de sync_n e dado_valido_n sejam
mantidos em nível lógico alto, ao passo que o vetor dados é mantido em nível baixo.
Por outro lado, caso ocorra algum evento de mudança de modo de operação ou
modelo de IFM selecionado, com o modo master habilitado, a máquina de estados, após
reiniciar a variável contador_TOA e o valor acumulado do TOA, volta para o estado
“PDW0”. De forma semelhante, no caso de ocorrerem as mesmas mudanças, porém
com o modo slave ativado, ou o sinal de serial_entrada ir para nível lógico baixo (o que
significa que foi recebido um bit de start através da porta serial, iniciando a transmissão
de uma PDW), a máquina de estados volta desta vez para o estado “Aguarda PDW”,
após fazer as mesmas reinicializações da situação anterior.
Adicionalmente, se no estado “Aguarda TOA” forem ativados os sinais de
suspender_n ou on_off_n, a máquina passa para o último estado a ser descrito: o estado
“Suspenso”.
Assim como o próprio nome sugere, o objetivo do estado “Suspenso” é garantir
que a transmissão das PDWs permaneça suspensa até que suspender_n = 1 e on_off_n =
1, quando então o sinal de sync_n vai para 0, fazendo a máquina retornar para o estado
“PDW0”. Enquanto isso não acontece, a lógica mantém sync_n = 1.
Como forma de, independentemente do sinal de clock, permitir-se a
reinicialização da máquina de estados, foi criado o sinal de reset_n, que, de maneira
assíncrona, zera todas as variáveis do programa, e o coloca em seu estado “Início”. Ele
pode ser acionado pressionando-se o primeiro dos quatro botões presentes na placa de
desenvolvimento do FPGA.
5.1.2 – Placa de Interface
5.1.2.1 – Diagrama de Blocos
32
O desenvolvimento da Placa de Interface do EDIFM se deu com base nas
especificações de requisitos apresentadas ao longo da seção 3.6. No intuito de facilitar o
projeto do circuito, foi elaborado um diagrama de blocos de baixo nível do EDIFM,
uma versão mais detalhada daquele mostrado na Figura 5.1 da seção 5.1.1. Esse
diagrama encontra-se na Figura 5.3.
Figura 5.3 – Diagrama de blocos de baixo nível do EDIFM.
Nele, podem ser observados os módulos principais que compõem o circuito.
De acordo com as informações da seção 3.2 sobre o barramento FPDP, para que
o EDIFM pudesse operar como “FPDP Transmitter Master”, era necessário utilizar um
circuito específico. Tal circuito é composto pelos seguintes módulos: Buffer 1, Buffer 2,
Buffer 3 e TTL-to-PECL. Buffer 1 e Buffer 2, cada qual de 16 bits, atuam como drivers
de corrente para os 32 bits de sinais do barramento de dados, fornecendo a corrente
necessária para manter a integridade dos mesmos ao longo do barramento. De forma
semelhante atua o Buffer 3, mas este para os sinais de controle de direção_n, sync_n,
dado_valido_n e clock_saida, sendo este último conectado ao módulo TTL-to-PECL,
33
para converter o nível lógico do sinal de TTL para PECL, gerando o clock diferencial
PSTROBE, utilizado como referência no barramento. Vale acrescentar que os três
módulos de Buffer, além de fazer a função citada, também atuam aumentando o nível
de tensão dos sinais de saída do FPGA, originalmente 2,5 V LVCMOS, para os 5 V
TTL exigidos.
Dando prosseguimento à descrição dos módulos, tem-se o módulo TTL-to-
LVTTL, o qual é responsável por converter os níveis de tensão dos sinais que saem do
FPDP, NRDY* e SUSPEND*, e do sinal de RX vindo do circuito conversor serial
(explicado no parágrafo seguinte), todos em 5 V TTL, para 3,3 V LVTTL. Aqui vale
salientar que, idealmente, esta conversão deveria ser feita para os 2,5 V LVCMOS
utilizados pelo FPGA. Entretanto, por indisponibilidade de componentes para realizar
tal função, foram empregados componentes que fazem a conversão apenas para 3,3 V
LVTTL, o que não configura um problema, já que este FPGA suporta sinais de entrada
de até no máximo 3,6 V.
O circuito conversor serial, representado pelo módulo subdividido em RS232-to-
TTL e TTL-to-RS232, ligado ao conector DB-9, é responsável por executar a conversão
de níveis de tensão apresentada na Figura 3.4 da seção 3.5. Ele converte o sinal de RX,
no formato RS-232, para TTL, e o sinal de TX, no formato TTL, para RS-232. Aqui
vale uma ressalva: na prática, como é obtido diretamente da saída do FPGA, o sinal de
TX não está em 5 V TTL, mas sim em 2,5 V LVCMOS. Apesar disso, a conversão é
possível, devido ao fato de que a tensão de 2,5 V se encontra acima do limiar inferior de
2,0 V a partir do qual um sinal TTL é entendido como estando em nível lógico alto.
No módulo Chaves estão representadas as três chaves de duas posições que
servem de interface para o usuário controlar os sinais de on_off_n, modo_operacao e
modelo_ifm.
Por fim, o módulo 12V-to-5V equivale ao circuito regulador de tensão,
responsável por, a partir dos 12 V disponibilizados pelo FPGA através do barramento
HSMC, fornecer a tensão de 5 V necessária para a alimentação da maioria dos circuitos
integrados da Placa de Interface. Na figura, a tensão de alimentação utilizada por cada
um dos módulos está representada pelos valores ao lado das linhas tracejadas.
5.1.2.2 – Esquemático
34
Tendo-se definido os módulos principais da Placa de Interface e suas respectivas
funcionalidades, pode-se então apresentar o esquemático do circuito que implementa e
conecta todos esses módulos. Tal esquemático foi subdividido em sete partes, cada qual
representada por uma figura, com o objetivo de facilitar sua visualização.
A primeira delas, Figura 5.4, mostra a implementação a nível de circuito dos
módulos Buffer 1 (U2) e Buffer 2 (U3), bem como o conector de 50 pinos (J1), para
cabo flat, cuja função é conduzir os sinais do FPGA, através da placa prototipadora,
para a Placa de Interface. Para permitir essa forma de conexão, foi feito o roteamento
dos pinos de entrada e saída do programa “gerador_fpdp” de modo que os sinais
possuíssem a configuração da Figura 5.5. É importante observar nessa figura que os
sinais cujos pinos estão localizados dentro do contorno em azul não estão diretamente
roteados nesses mesmos pinos, pois estes não são ligados internamente ao conector
HSMC desse modelo de FPGA. Por isso, a fim de que o conector flat pudesse ser
aproveitado também para conectá-los, eles foram roteados nos pinos delimitados pelo
contorno em azul à direita, e são interligados via fios soldados na parte de baixo da
placa prototipadora.
35
Figura 5.4 – Esquemático da Placa de Interface: Buffer 1, Buffer 2 e conector de 50
vias.
36
Figura 5.5 – Configuração dos sinais de entrada e saída do FPGA na placa
prototipadora.
Em seguida, na Figura 5.6, encontram-se os módulos Buffer 3 (U4), TTL-to-
PECL (U6) e TTL-to-LVTTL (U5). Os resistores R1, R2 e R3 são resistores de
terminação recomendados pelo padrão do barramento FPDP.
37
Figura 5.6 – Esquemático da Placa de Interface: Buffer 3, TTL-to-PECL, TTL-to-
LVTTL e resistores de terminação.
Na Figura 5.7 constam os módulos RS232-to-TTL e TTL-to-RS232,
representados pelo CI MAX232 (U7), juntamente com o conector DB-9 (J2), para a
interface serial RS-232, e o conector FPDP (J3). Os dois conjuntos de resistores,
formados por R4, R5, R6 e R7, e R8, R9, R10 e R11, consistem de redes de pull-up e
pull-down, também recomendados pelo padrão do FPDP para os sinais indicados.
38
Figura 5.7 – Esquemático da Placa de Interface: RS232-to-TTL, TTL-to-RS232,
conector DB-9, conector FPDP e resistores de pull-up e pull-down.
A Figura 5.8, por sua vez, mostra a implementação do módulo Chaves (SW1,
SW2 e SW3), onde o resistor R16 atua de modo a limitar a corrente que percorre as
chaves seletoras.
39
Figura 5.8 – Esquemático da Placa de Interface: Chaves e resistor limitador de corrente.
A seguir, a Figura 5.9 apresenta o CI usado para implementar o módulo 12V-to-
5V (U1), juntamente com os pads (PAD1, PAD2 e PAD3) que acomodarão os pinos a
serem conectados com as saídas de alimentação do FPGA (GND, +3.3V e +12V,
respectivamente).
Figura 5.9 – Esquemático da Placa de Interface: 12V-to-5V e pads de alimentação.
Ainda com respeito à alimentação do circuito, na Figura 5.10 são representados
todos os capacitores de filtragem aplicados no corte de possíveis oscilações de alta
frequência nas fontes de alimentação, as quais podem ser prejudiciais ao bom
funcionamento do circuito.
40
Figura 5.10 – Esquemático da Placa de Interface: Capacitores de filtragem.
Finalmente, os quatro LEDs (LED1, LED2, LED3 e LED4) empregados na
Placa de Interface, bem como seus respectivos resistores limitadores de corrente (R12,
R13, R14 e R15, respectivamente), são apresentados na Figura 5.11.
Figura 5.11 – Esquemático da Placa de Interface: LEDs e resistores limitadores de
corrente.
5.1.2.3 – PCI
O layout da Placa de Interface do EDIFM foi desenhado com base no
esquemático descrito na seção 5.1.2.2. As dimensões aproximadas da PCI são 10 x 13
cm, tendo sido projetada em quatro camadas, a saber: Top, camada de roteamento
superior; Bottom, camada de roteamento inferior; e as camadas internas que consistem
nos planos de GND (terra) e +5V.
Na Figura 5.12 está representado um modelo em três dimensões da placa,
contendo a delimitação da área da mesma, seus componentes e furação.
Adicionalmente, a Figura 5.13 mostra a mesma vista da PCI, porém com as trilhas de
41
roteamento já demarcadas (trilhas verdes para a camada Top e amarelas para a Bottom).
Nas duas figuras, as camadas internas (GND e +5V) estão ocultadas propositalmente,
no sentido de facilitar a visualização geral da placa.
Figura 5.12 – Modelo em 3-D da Placa de Interface do EDIFM.
42
Figura 5.13 – Modelo em 3-D da Placa de Interface do EDIFM, com roteamento.
À esquerda da figura tem-se o conector de 50 vias (J1), e acima dele os três pads
para os pinos de alimentação, ao lado dos seus respectivos capacitores de filtragem.
Na parte superior estão os três LEDs para indicação das alimentações, com seus
respectivos resistores, e ao lado o conector DB-9 (J2).
À direita está posicionado o conector FPDP (J3), juntamente com os circuitos
dos módulos Buffer 1, Buffer 2, Buffer 3, TTL-to-PECL e TTL-to-LVTTL, também
com os seus capacitores de filtragem, resistores de pull-up, pull-down e de terminação.
Abaixo do conector FPDP encontra-se o LED de indicação de transmissão no
barramento, com seu resistor limitador de corrente.
Na parte inferior da placa estão as três chaves seletoras, abaixo do resistor que
limita a corrente sobre as mesmas.
O centro da PCI, finalmente, contém o módulo 12V-to-5V, à esquerda, e o
circuito que implementa os módulos RS232-to-TTL e TTL-to-RS232, à direita, com
seus capacitores de filtragem.
Adicionalmente, em cada vértice da PCI foram posicionados furos para fixação
de suporte para que a placa não fique diretamente apoiada sobre a superfície.
43
5.2 – Software
O desenvolvimento do software foi centrado na criação de uma classe
gerador_pdw, a qual possui todos os métodos e atributos necessários para a inserção
dos parâmetros do pulso, geração das PDWs e sua transmissão na porta serial. O
método responsável por essa transmissão, porém, será descrito na seção 5.3. A
apresentação da GUI desenvolvida para o software será feita na seção 5.2.1, ao passo
que a descrição do funcionamento interno da classe gerador_pdw, por sua vez, ficará na
seção 5.2.2.
5.2.1 – GUI
A tela inicial do Programa Gerador de PDW do EDIFM encontra-se na Figura
5.14.
Figura 5.14 – Tela inicial do Programa Gerador de PDW do EDIFM (modelo S).
44
O usuário começa selecionando o modelo do IFM a ser emulado, modelo S ou
modelo K, com um clique no botão referente ao modelo desejado. Este botão é
denominado “Radio Button”, e, por estarem ambos no mesmo grupo (“Modelo do
IFM”), o sistema permite que apenas um dos botões permaneça marcado. A seleção do
modelo do IFM logo de início é importante pois o software é programado para que,
quando o usuário alterar a seleção do modelo, todos os parâmetros sejam reinicializados
para a configuração padrão. Tal padrão pode ser visto também na Figura 5.14, para o
modelo S, e na Figura 5.15, para o modelo K.
Figura 5.15 – Tela inicial do Programa Gerador de PDW do EDIFM (modelo K).
Tendo selecionado o modelo do IFM, pode-se então preencher os valores dos
parâmetros do pulso. Os parâmetros disponíveis para configuração são os seguintes:
frequência da portadora, amplitude, largura do pulso (LP), PRI e PRF. Os valores desses
parâmetros são preenchidos por meio de campos do tipo “Double Spin Box”, que
permitem não só a inserção manual dos mesmos como também o uso de setas para
aumenta-los ou diminuí-los com passos fixos. Cada campo possui limites máximo e
mínimo estabelecidos, o que impede o usuário de inserir valores que porventura estejam
fora desses limites. Tais valores podem ser conferidos pelo próprio usuário,
45
simplesmente mantendo-se o cursor sobre o parâmetro cujos limites deseja-se tomar
conhecimento. No intuito de cumprir essa função, são usados elementos chamados
“Tooltips”. A Figura 5.16 traz um exemplo de uso desse elemento na verificação dos
valores máximo e mínimo para a amplitude do pulso (-55 a +5 dBm).
Figura 5.16 – Exemplo de uso do “Tooltip”.
Além disso, vale lembrar que os campos relativos à PRI e PRF são intertravados,
o que quer dizer que, ao se preencher um, o outro é simultaneamente preenchido com
seu valor inverso.
Finalmente, após a seleção do modelo do IFM e o preenchimento dos valores
dos parâmetros, nesta ordem, pode-se então executar o algoritmo de geração da PDW e
transmissão para a porta serial. Isso é possível pressionando-se o botão do tipo “Push
Button” intitulado “Transmitir”. Logo após o usuário pressionar tal botão, a barra de
status do tipo “Progress Bar” começa a ser preenchida, e o percentual referente ao
progresso de execução do algoritmo até o momento é mostrado ao lado direito da barra.
Abaixo dela, são transcritas as mensagens de status que alertam o usuário da situação da
transmissão da PDW na porta serial. As diferentes mensagens que podem aparecer no
campo de status são as seguintes:
46
“Transmissão concluída!” (em azul; as demais, em vermelho)
“Erro ao abrir porta serial!”
“Erro ao adquirir status do dispositivo!”
“Erro ao configurar parâmetros do dispositivo!”
“Erro ao configurar ‘timeouts’!”
“Erro na transmissão dos bytes!”
“Erro ao fechar porta serial!”
Na Figura 5.17 é mostrada a primeira mensagem, ocorrida após a transmissão
bem sucedida de uma PDW, ao passo que na Figura 5.18 é apresentada a mensagem de
um dos possíveis casos de erro, desta vez ao executar o procedimento de abertura da
porta serial.
Figura 5.17 – Mensagem de status indicativa de transmissão concluída e bem sucedida.
47
Figura 5.18 – Exemplo de mensagem de status indicativa de erro na transmissão.
5.2.2 – Funcionamento Interno
Quanto ao funcionamento interno da classe gerador_pdw, tem-se primeiramente
os métodos responsáveis por fazer a leitura dos valores contidos nos botões e campos da
GUI. Esses métodos, denominados slots, recebem a informação enviada por cada item,
seja ele botão ou campo, que é chamada de signal. Para exemplificar: o método
lerFrequencia(), do tipo slot, recebe, por meio do signal valueChanged(), a informação
de que o valor no campo foi modificado pelo usuário e faz a leitura do valor atualizado
do campo “Frequência da Portadora”, guardando-o no atributo frequencia_entrada. A
mesma lógica é implementada nos slots lerModeloIFM(), lerAmplitude(),
lerLarguraPulso(), lerPRI() e lerPRF().
No caso específico do slot lerModeloIFM(), cada um dos dois botões referentes
aos modelos de IFM envia um signal chamado clicked(), o qual indica que o botão foi
pressionado pelo usuário a fim de ativar sua função. O slot então verifica qual modelo
foi selecionado e seta todas as configurações de parâmetros, como valores iniciais,
máximo e mínimo, para aquele modelo que foi escolhido.
48
Já no caso do slot lerPRI(), além do procedimento semelhante ao do
lerFrequencia(), gravando no atributo PRI_entrada seu respectivo valor, o atributo
PRF_entrada é preenchido com o inverso de PRI_entrada multiplicado pelo fator 109,
cujo valor final é imediatamente setado no campo “PRF”. O procedimento recíproco é
feito para o caso do slot lerPRF().
Os métodos seguintes a serem descritos são os que realizam a codificação dos
valores numéricos dos parâmetros, tipicamente no formato double, para vetores de bits,
os quais serão posteriormente ordenados para gerar as três palavras de 32 bits que
formam a PDW. São eles: codificarFrequencia(), codificarAmplitude(),
codificarLarguraPulso() e codificarPRI(). A codificação usada para cada um dos
parâmetros encontra-se transcrita na Tabela 5.4, para o modelo S, e Tabela 5.5, para o
modelo K.
Tabela 5.4 – Codificação usada para os parâmetros do pulso no modelo S.
Frequência da Portadora (MHz)
Amplitude (dBm)
LP (ns)
PRI (ns) round(PRI_entrada/5)
Parâmetro do PulsoCodificação
Modelo S
round(frequencia_entrada*4,096)
round((amplitude_entrada + 75)/0,5)
round(larguraPulso_entrada/5)
Tabela 5.5 – Codificação usada para os parâmetros do pulso no modelo K.
Frequência da Portadora (MHz)
Amplitude (dBm)
LP (ns)
PRI (ns) round(PRI_entrada/5)
Parâmetro do PulsoCodificação
Modelo K
round((frequencia_entrada - 1808)/0,5)
round((amplitude_entrada + 75)/0,5)
round(larguraPulso_entrada/5)
A função round() utilizada retorna o valor double contido no seu argumento
arredondado para o inteiro mais próximo. Dessa forma, o que se terá no parâmetro de
saída será um número inteiro sem sinal, que é representado internamente por um vetor
de 32 bits.
Finalmente, no sentido de manipular os bits resultantes das codificações
realizadas sobre os valores dos parâmetros, é implementado o método gerarPDW(). Ele
49
é responsável por concatenar os vetores de bits no formato da PDW utilizado por cada
um dos modelos de IFM. Seu funcionamento é bastante simples, consistindo apenas de
uma lógica condicional para detectar qual dos modelos de IFM foi selecionado e de uma
sequência de deslocamentos nos vetores de bits a fim de montar as três palavras da
PDW respeitando as estruturas apresentadas anteriormente, na Tabela 5.1 e Tabela 5.2.
Além disso, é neste método que são chamados e executados os métodos de codificação,
descritos nos parágrafos anteriores.
5.3 – Interface Serial
A implementação da interface serial para o EDIFM se deu em duas partes:
software e hardware. Da parte do software, foi acrescentado mais um método para a
classe gerador_pdw, denominado transmitirPortaSerial(), utilizado para este fim
específico, e que será descrito na seção 5.3.1. Por outro lado, da parte do hardware, foi
acrescentada mais uma entidade para o programa “gerador_fpdp”, chamada uart_rx,
explicada na seção 5.3.2.
5.3.1 – Software
No caso do método transmitirPortaSerial(), ele é chamado a partir do clique do
usuário no botão “Transmitir” da GUI do Programa Gerador de PDWs. Após seu
chamado, primeiramente é executado o método gerar_pdw(), já descrito na seção 5.2,
para, em seguida, executar o procedimento de: abertura da porta serial disponível;
configuração dos parâmetros de transmissão, ou seja, taxa de transmissão (“baud rate”),
tamanho do byte, número de bits de stop e seleção da paridade utilizada; definição das
características de “timeout” da porta; transmissão propriamente dita dos bytes no pino
de TX do conector DB-9; e fechamento da porta serial.
A barra de progresso existente na GUI também vai sendo incrementada ao longo
da execução desse algoritmo, iniciando em zero e acumulando até o final da execução,
totalizando oito passos.
O código na linguagem C++ utilizado como base para implementar essa
interface encontra-se disponível na internet [7].
50
5.3.2 – Hardware
A entidade uart_rx, por sua vez, tem como entradas os sinais de serial_entrada,
modelo_ifm e clock_saida, e como saídas os sinais de serial_byte (vetor 8 bits) e
serial_valido. Como se trata de uma interface assíncrona, o clock usado para sincronizar
a transmissão não é enviado, sendo necessário, para amostrar os dados corretamente, um
clock ao menos oito vezes mais rápido que o utilizado para a transmissão. Assim sendo,
o sinal de clock_saida é usado para este fim.
O funcionamento da arquitetura dessa entidade é simples, e consiste na
paralelização dos bits recebidos serialmente. Um diagrama que o representa encontra-se
na Figura 5.19.
Figura 5.19 – Diagrama de funcionamento da arquitetura da entidade uart_rx.
Para iniciar, a máquina de estados é disparada pelo bit de start do protocolo
serial. Tendo sido disparada, ela então aguarda a metade do primeiro bit de dados para
amostrá-lo, controlando dessa mesma maneira o recebimento de cada bit, de forma que
o primeiro bit recebido seja armazenado no LSB do sinal de serial_byte, enquanto o
último seja o MSB deste sinal.
Completada a recepção de um byte, durante o bit de stop é disponibilizado, em
um pulso do sinal de clock_saida, o valor do byte armazenado no sinal de serial_byte,
juntamente com o bit serial_valido ativado em nível lógico alto, sinalizando que o byte
disponibilizado é válido. A máquina de estados retorna então para seu estado inicial,
aguardando o próximo bit de start.
O código na linguagem VHDL utilizado como base para implementar essa
interface também se encontra disponível na internet [8].
Além de se ter introduzido a nova entidade uart_rx ao programa
“gerador_fpdp”, foram também necessárias algumas pequenas adaptações neste
51
programa, a fim de compatibilizar a nova entidade com a entidade principal do
programa e permitir a utilização dos sinais de uma entidade na outra.
A principal alteração foi a criação do estado “Aguarda PDW”, já mencionado na
seção 5.1.1. Nele fica garantido inicialmente que sync_n = 1 e dado_valido = 1,
enquanto o vetor dados é mantido em 0. A seguir, é checado em qual modo de operação
se encontra o sistema. Caso o mesmo esteja em modo master, faz-se com que sync_n =
0, e o próximo estado seja “PDW0”.
Estando em modo slave, é checado continuamente a cada ciclo de clock_saida o
valor do sinal de serial_valido, até que seja detectado que ele esteja em nível lógico
alto. Quando isso ocorrer, significa que há no presente ciclo um byte válido no sinal de
serial_byte. Esse primeiro byte é então armazenado nos 8 LSB do sinal serial_PDW_0,
utilizado para guardar a primeira das três palavras da PDW. O mesmo procedimento é
executado para os 3 bytes subsequentes, sempre do LSB para o MSB, por meio da
variável contador_serial, que é incrementada a cada byte recebido.
Tendo finalizado a recepção e o armazenamento da primeira palavra da PDW,
outra variável, contador_PDW, é incrementada, e o mesmo algoritmo se repete por mais
duas vezes, até que contador_serial = 4 e contador_PDW = 2.
Ao serem atingidos esses valores, o programa executa algumas ações, que são:
zerar as variáveis contador_serial e contador_PDW e o valor acumulado do TOA,
preencher a variável ciclos_PRI do modo slave com o valor em decimal dos 32 bits do
TOA dividido por 10 (modelo S) ou 5 (modelo K), fazer sync_n = 0 e impor o próximo
estado para “PDW0”. Desta forma, a PDW gerada pelo software passará a ser
disponibilizada no barramento.
Esse mecanismo de funcionamento está descrito na Figura 5.20 em forma de
fluxograma.
52
Figura 5.20 – Fluxograma que descreve a lógica do funcionamento interno do estado
“Aguarda PDW”.
É importante ressaltar que os parâmetros utilizados para transmissão precisam
estar igualmente configurados no receptor, a fim de permitir perfeito sincronismo entre
53
ambos. Caso isso não seja cumprido, pode haver perda de bits ao longo da transmissão,
o que faria com que o FPGA sincronizasse no barramento valores errados para os
parâmetros do pulso. Nesse sentido, os parâmetros a seguir foram configurados da
mesma maneira em ambos os lados da UART: taxa de transmissão igual a 38400 bps,
tamanho do byte equivalente a 8 bits, apenas 1 bit de stop e nenhum bit de paridade.
54
Capítulo 6
Resultados
6.1 – Simulações
Nesta primeira seção do capítulo de resultados serão apresentadas as simulações
executadas sobre o programa “gerador_fpdp”, no sentido de verificar o funcionamento
da lógica de sincronismo do EDIFM, tanto no seu modo master quanto no slave. Os
testes com o hardware propriamente dito serão apresentados na seção 6.2.
Para as primeiras simulações, apesar de não explicitado, assume-se que os sinais
de reset_n, nao_pronto_n, suspender_n e on_off_n estão todos em nível lógico alto. As
entradas que variam são modo_operacao e modelo_ifm, cujos valores serão mostrados
em cada uma das situações. O sinal de saída direcao_n é sempre mantido em nível
lógico baixo, conforme o padrão do barramento para o transmissor.
Dando início à sequência de simulações, a Figura 6.1 apresenta a forma de onda
do clock gerado pelo FPGA com o modelo S selecionado, isto é, modelo_ifm = 0.
Utilizando-se os cursores C1 e C2 como referência, tem-se que a frequência medida
para este clock foi 1/(C2 – C1) = 1/(50 ns), ou seja, 20 MHz, o que confere com o
esperado.
Figura 6.1 – Simulação do sinal de clock_saida do modelo S.
55
Na Figura 6.2 tem-se a mesma situação, porém com modelo_ifm = 1. Com isso
pode-se medir a frequência do clock gerado no caso do modelo K ter sido selecionado.
Mais uma vez usando-se os cursores C1 e C2, tem-se 1/(C2 – C1) = 1/(25 ns), isto é, 40
MHz, valor que também confere com o esperado para o modelo K.
Figura 6.2 – Simulação do sinal de clock_saida do modelo K.
Em seguida, na Figura 6.3, é mostrado o padrão de transmissão ao longo do
tempo com o modo master aplicado ao modelo S, tendo-se então modo_operacao = 1 e
modelo_ifm = 0 para este caso. Novamente fazendo uso dos cursores no gráfico, é
possível medir a PRI deste pulso, pois C1 – C2 = 1 ms, que é justamente a PRI
configurada no programa para o modo master (Tabela 5.3).
Figura 6.3 – Simulação da PRI do modelo S no modo master.
56
Ampliando-se o gráfico para observar o conteúdo do barramento de dados no
momento da transmissão da PDW, o que se tem é o representado na Figura 6.4. Em
primeiro lugar, é possível notar o funcionamento dos sinais de sync_n e dado_valido_n
ocorrendo exatamente da forma como foi modelado e implementado. Em segundo lugar,
o barramento de dados disponibiliza, em sua segunda e terceira palavras, os valores em
hexadecimal 0x00C82000 e 0x00000046, respectivamente. Isso representa, em termos
de números binários, e tomando como base a estrutura da PDW descrita na Tabela 5.1,
uma LP de 0000000011001000, frequência da portadora igual a 10000000000000 e
amplitude de 01000110. Realizando a conversão desses valores para seus
correspondentes decimais, por meio das fórmulas de conversão descritas na Tabela 5.4,
tem-se, para a LP, 1 μs, 2 GHz para a frequência da portadora e, para a amplitude, -40
dBm. Esses valores de fato estão de acordo com os definidos na Tabela 5.3.
No caso da primeira palavra, que contém o TOA, tem-se o valor em
hexadecimal 0x00030D40. Este valor, diminuído do valor do TOA encontrado no pulso
seguinte, o qual está ilustrado na Figura 6.5, isto é, 0x00061A80, resulta no próprio
0x00030D40, que, por sua vez, aplicando-se a fórmula de conversão da Tabela 5.4 para
a PRI, conduz ao valor final de 1 ms, exatamente o valor da PRI encontrada para este
pulso.
Figura 6.4 – Simulação da PDW do modelo S no modo master.
57
Figura 6.5 – Simulação da PDW seguinte do modelo S no modo master.
A seguir, faz-se o mesmo procedimento para o IFM de modelo K. Para isso,
mantém-se modo_operacao = 1 (modo master), impondo agora modelo_ifm = 1. De
forma análoga ao caso do modelo S, é apresentado na Figura 6.6 o padrão de
transmissão da PDW. Através dos cursores C1 e C2, é possível fazer C2 – C1,
resultando em 1 ms, conforme previsto.
Figura 6.6 – Simulação da PRI do modelo K no modo master.
Repetindo o procedimento realizado para o caso do modelo S, pode-se também
ampliar o gráfico para observar o conteúdo do barramento de dados. Representado na
Figura 6.7, o gráfico mostra a segunda palavra contendo o valor em hexadecimal
0x00C87060, enquanto a terceira palavra contém 0x00000046. Da mesma maneira, tais
valores representam, em termos de números binários, e tomando como base a estrutura
da PDW descrita na Tabela 5.2, uma LP de 0000000011001000, frequência da
58
portadora igual a 111000001100000 e amplitude de 01000110. Realizando a conversão
desses valores para seus correspondentes decimais, por meio das fórmulas de conversão
descritas na Tabela 5.5, tem-se, para a LP, 1 μs, 9 GHz para a frequência da portadora e,
para a amplitude, -40 dBm. Esses valores também condizem com os definidos na Tabela
5.4.
Equivalentemente ao modelo S, no caso da primeira palavra, tem-se o valor em
hexadecimal 0x00000000 (primeira PDW da sequência), que, diminuído do valor do
TOA encontrado no pulso posterior, ilustrado na Figura 6.8, ou seja, 0x00030D40,
resulta logicamente no próprio 0x00030D40, o qual, aplicando-se a fórmula de
conversão da Tabela 5.5 para a PRI, conduz ao valor final de 1 ms, que é novamente o
valor exato da PRI encontrada para este pulso.
Figura 6.7 – Simulação da PDW do modelo K no modo master.
Figura 6.8 – Simulação da PDW seguinte do modelo K no modo master.
59
Para as simulações seguintes, o modo operação foi alterado para o modo slave,
fazendo modo_operacao = 0.
A configuração dos valores dos parâmetros transmitidos pela porta serial, para
este caso, com modelo_ifm = 0 (modelo S), é definida de forma que se tenha frequência
da portadora igual a 1 GHz, -5 dBm de amplitude, 10 μs de LP e PRI igual a 100 μs.
Dessa maneira, para se ter estes parâmetros de pulso em específico, as três palavras da
PDW que o descreve devem ser, respectivamente:
00000000000000000100111000100000, 00000111110100000001000000000000 e
00000000000000000000000010001100, conforme a Tabela 5.1 e a Tabela 5.4. No caso
da simulação, isso é possível a partir do desenho de uma forma de onda para o sinal de
serial_entrada que seja idêntica à resultante da transmissão desses parâmetros pelo
Programa Gerador de PDW. Sendo assim, a Figura 6.9 apresenta inicialmente essa
forma de onda e, no tempo restante, as primeiras PDWs sendo transmitidas no
barramento.
Figura 6.9 – Simulação do sinal de serial_entrada do modelo S no modo slave.
Aproximando-se o gráfico, pode-se medir, a partir do emprego dos cursores C1
e C2, fazendo-se C2 – C1, a PRI de 100 μs configurada e transmitida via interface
serial. Essa medida encontra-se na Figura 6.10.
60
Figura 6.10 – Simulação da PRI do modelo S no modo slave.
Assim como no modo master, no modo slave pode-se aproximar ainda mais o
gráfico a fim de verificar cada uma das palavras disponibilizadas no barramento de
dados. O gráfico da Figura 6.11 mostra que a segunda palavra contém o valor em
hexadecimal 0x07D01000, ao passo que a terceira, 0x0000008C. Estes valores, em
termos de números binários, representam uma LP de 0000011111010000, frequência da
portadora igual a 01000000000000 e amplitude de 10001100. Realizando a conversão
desses valores para seus respectivos decimais equivalentes, chega-se a uma LP de 10 μs,
frequência da portadora de 1 GHz e amplitude igual a -5 dBm, estando portanto de
acordo com os definidos para a simulação da transmissão serial.
Para a primeira palavra, tem-se o valor em hexadecimal 0x00004E20, o qual,
diminuído do valor do TOA do pulso seguinte, encontrado na Figura 6.12, isto é,
0x00009C40, resulta no próprio 0x00004E20, cujo valor em decimal está em
conformidade com os 100 μs equivalentes à PRI definida anteriormente.
61
Figura 6.11 – Simulação da PDW do modelo S no modo slave.
Figura 6.12 – Simulação da PDW seguinte do modelo S no modo slave.
Agora, o mesmo procedimento é executado para o IFM de modelo K. Dessa
forma, o sinal de modo_operacao é mantido em 1, caracterizando modo master, mas
desta vez com modelo_ifm também em 1.
De forma análoga ao caso do modelo S, os valores dos parâmetros
representativos da transmissão serial também são definidos, porém desta vez da
seguinte maneira: frequência da portadora igual a 10 GHz, 0 dBm de amplitude, 100 ns
de LP e PRI igual a 1 μs. Para se ter estes parâmetros, de modo análogo ao que foi visto
com o modelo S, é preciso que as três palavras da PDW sejam, respectivamente:
00000000000000000000000011001000, 00000000000101001000000000000000 e
00000000000000000000000010010110, conforme a Tabela 5.2 e a Tabela 5.5. Do
mesmo modo como foi feito com o modelo S em slave, uma forma de onda foi
desenhada para implementar o padrão de transmissão da PDW na porta serial para o
62
modelo K. A Figura 6.13 apresenta no início do gráfico essa forma de onda e, no
restante, as primeiras transmissões da PDW no barramento.
Figura 6.13 – Simulação do sinal de serial_entrada do modelo K no modo slave.
Com uma aproximação no gráfico é possível medir, com os cursores C1 e C2, a
PRI que caracteriza este pulso. Fazendo-se C2 – C1 na Figura 6.14 resulta 1 μs, que é
exatamente a PRI configurada e transmitida via interface serial.
Figura 6.14 – Simulação da PRI do modelo K no modo slave.
Observando-se com mais detalhes o gráfico, como demonstrado na Figura 6.15,
pode-se verificar o conteúdo de cada uma das palavras disponibilizadas no barramento.
A segunda palavra contém o valor em hexadecimal 0x00148000, e a terceira,
0x00000096. Estes valores, em termos de números binários, representam uma LP de
0000000000010100, frequência da portadora igual a 100000000000000 e amplitude de
63
10010110. Realizando-se a conversão desses valores para seus decimais
correspondentes, encontra-se uma LP de 100 ns, 10 GHz de frequência da portadora e 0
dBm de amplitude, os quais correspondem aos configurados para transmissão via
interface serial.
Além disso, a primeira palavra apresenta o valor em hexadecimal 0x000084D0,
que, diminuído do valor do TOA do pulso seguinte, da Figura 6.16, isto é, 0x00008598,
resulta no valor 0x000000C8, que é, em decimal, igual a 1 μs, de fato a mesma PRI
definida para a transmissão.
Figura 6.15 – Simulação da PDW do modelo K no modo slave.
Figura 6.16 – Simulação da PDW seguinte do modelo K no modo slave.
As simulações a seguir são usadas para ilustrar a lógica de funcionamento dos
sinais de controle.
64
A primeira delas, apresentada na Figura 6.17, trata do sinal assíncrono de
reset_n aplicado ao EDIFM operando em modo master. Nota-se que, assim que vai a
nível lógico baixo, o sinal de reset_n reinicializa o sistema, parando a transmissão, a
qual somente retorna quando reset_n = 1, conforme mostra a Figura 6.18. A Figura
6.19, por sua vez, demonstra que assim que a transmissão é retomada, a primeira
palavra da PDW está zerada, significando que o TOA é de fato reinicializado.
Figura 6.17 – Simulação da ativação do sinal de reset_n no modo master.
Figura 6.18 – Simulação da desativação do sinal de reset_n no modo master.
65
Figura 6.19 – Simulação da PDW na desativação do sinal de reset_n no modo master.
Adicionalmente, a mesma situação em relação ao sinal de reset_n é apresentada
a seguir, na Figura 6.20, porém com modo de operação slave. Pode-se perceber que o
funcionamento é similar ao caso anterior, à exceção de que, neste modo, a transmissão
não é retomada com o retorno de reset_n para nível lógico alto, como pode ser
confirmado na Figura 6.21. Isso ocorre porque, ao se reinicializar o sistema como um
todo, as variáveis e os registradores internos também são reinicializados, fazendo com
que se perca os dados das palavras armazenadas, recebidas pela interface serial.
Figura 6.20 – Simulação da ativação do sinal de reset_n no modo slave.
66
Figura 6.21 – Simulação da desativação do sinal de reset_n no modo slave.
Dando prosseguimento, a Figura 6.22 apresenta o sinal de nao_pronto_n e seu
funcionamento, que é idêntico para ambos os modos de operação. Nela pode ser visto
que, quando ativado simultaneamente ao início da transmissão, a mesma não acontece,
até que nao_pronto_n = 1. Após isso, conforme consta na Figura 6.23, este sinal pode ir
novamente a nível lógico baixo, por inúmeras vezes, que ele será ignorado pelo
transmissor, só podendo voltar a ser amostrado caso o sinal de reset_n seja ativado,
reinicializando todo o sistema.
Figura 6.22 – Simulação da desativação do sinal de nao_pronto_n.
67
Figura 6.23 – Simulação da ativação do sinal de nao_pronto_n.
O próximo sinal de controle cujo funcionamento será simulado é o suspender_n.
Na Figura 6.24, tem-se este sinal sendo colocado em nível lógico baixo a fim de
suspender a transmissão, no modo master. Quando em nível alto, a mesma é retomada
imediatamente, de acordo com a Figura 6.25.
Figura 6.24 – Simulação da ativação do sinal de suspender_n no modo master.
68
Figura 6.25 – Simulação da desativação do sinal de suspender_n no modo master.
Pode-se perceber que o mesmo ocorre quando em modo de operação slave,
onde, diferentemente do sinal de reset_n, após suspensão da transmissão, na Figura
6.26, a mesma é retomada, na Figura 6.27, quando suspender_n é colocado de volta em
nível lógico alto.
Figura 6.26 – Simulação da ativação do sinal de suspender_n no modo slave.
69
Figura 6.27 – Simulação da desativação do sinal de suspender_n no modo slave.
Em seguida, tem-se a demonstração da lógica do sinal de on_off_n. Seu
funcionamento é rigorosamente igual ao do sinal de suspender_n, sendo o primeiro
controlado pelo usuário por meio de uma chave na Placa de Interface, e o segundo
controlado pelo receptor via barramento FPDP, conforme já explanado nesse texto. Sua
ativação encontra-se ilustrada na Figura 6.28 e sua desativação na Figura 6.29, para o
modo master, e, para o modo slave, sua ativação está na Figura 6.30 e desativação na
Figura 6.31.
Figura 6.28 – Simulação da ativação do sinal de on_off_n no modo master.
70
Figura 6.29 – Simulação da desativação do sinal de on_off_n no modo master.
Figura 6.30 – Simulação da ativação do sinal de on_off_n no modo slave.
Figura 6.31 – Simulação da desativação do sinal de on_off_n no modo slave.
71
O gráfico de simulação da Figura 6.32, por sua vez, demonstra uma transição de
modelo de IFM, neste caso, do modelo S para o modelo K, com o EDIFM operando em
modo master. Isso é feito com o sinal de modelo_ifm passando de nível lógico baixo
para alto. Pelo gráfico, conclui-se que a transmissão da PDW do modelo S é
imediatamente cessada, passando o sistema a transmitir no barramento a PDW definida
para o modelo K. Além disso, é importante ressaltar que, nessa transição, o TOA é
zerado, fato que pode ser comprovado na Figura 6.33. O resultado é análogo para o caso
da transição inversa, do modelo K para o modelo S.
Figura 6.32 – Simulação da transição do modelo S para o modelo K no modo master.
Figura 6.33 – Simulação da PDW na transição do modelo S para o modelo K no modo
master.
A mesma simulação é feita para o caso de modo de operação slave. Neste caso,
representado pela Figura 6.34, com uma mudança no modelo de IFM a ser emulado, a
72
transmissão é interrompida. A justificativa para esse comportamento é que se entende
que a PDW recebida pela interface serial e armazenada nos registradores somente é
válida para o modelo de IFM para o qual ela foi configurada no software, o que faz com
que a mudança de modelos no modo slave invalide a PDW em transmissão naquele
momento.
Figura 6.34 – Simulação da transição do modelo S para o modelo K no modo slave.
Por último, é ilustrada a situação de mudança de modo de operação. A Figura
6.35 apresenta a mudança de modo master para modo slave. Nela pode-se notar que a
transmissão é suspensa por tempo indeterminado, até que uma PDW seja carregada pela
porta serial.
Figura 6.35 – Simulação da transição do modo de operação master para o slave.
73
Por sua vez, a Figura 6.36 apresenta a alteração inversa, isto é, de modo slave
para modo master. Nessa situação a transmissão é prontamente reiniciada com as novas
configurações de PDW, estabelecidas pelo próprio programa, e o TOA é zerado,
conforme mostra a Figura 6.37.
Figura 6.36 – Simulação da transição do modo de operação slave para o master.
Figura 6.37 – Simulação da PDW na transição do modo de operação slave para o
master.
6.2 – Testes
6.2.1 – IFM
74
O primeiro dos testes de hardware realizados foi o do próprio equipamento IFM.
No sentido de poderem ser considerados como referências para fins de comparação com
o EDIFM desenvolvido, foram utilizados dois modelos de IFM reais distintos.
Para gerar o sinal radar que serve de entrada para o IFM, foi empregado um
equipamento gerador de RF, que gera o sinal de RF usado como portadora na frequência
desejada, ligado em série a um equipamento gerador de pulsos, responsável por modular
o sinal de RF, gerando pulsos de amplitude, LP e PRI definidas. A saída do IFM, por
sua vez, foi conectada a um analisador lógico, a fim de ter suas características de
transmissão no barramento FPDP monitoradas por meio da amostragem dos sinais de
STROB, SYNC*, DVALID* e D<31:00>.
Nesse sentido, a seguir são apresentados os testes do IFM tomado como
referência para o modelo S. Neste caso, os valores dos parâmetros ajustados nos
equipamentos são iguais aos definidos para o modo master do EDIFM de modelo S,
conforme a Tabela 5.3.
Na Figura 6.38 encontra-se a forma de onda do clock medido para o primeiro
modelo de IFM, referência para o modelo S. Utilizando-se as marcações M1 e M2 do
gráfico, tem-se que 1/(M2 – M1) = 1/(50 ns) = 20 MHz, que é a frequência do clock de
saída deste IFM.
Figura 6.38 – Teste do sinal de STROB do IFM referente ao modelo S.
Em seguida, na Figura 6.39, é mostrada uma visão geral do padrão de
transmissão das PDWs no barramento FPDP. Mais uma vez, fazendo uso das marcações
M1 e M2, obtém-se que M2 – M1 = 1 ms, cujo valor representa a PRI configurada.
Pode-se perceber também no gráfico que este modelo de IFM mantém no
barramento os dados disponibilizados na última palavra da PDW, até que ocorra uma
nova transmissão. Isso não configura um problema, visto que os dados no barramento
75
somente podem ser considerados válidos quando o sinal de DVALID* está ativado, o
que não é o caso.
Figura 6.39 – Teste da PRI do IFM referente ao modelo S.
Aproximando-se o gráfico para verificar o conteúdo do barramento no momento
exato da disponibilização da PDW, é encontrado o apresentado na Figura 6.40.
Primeiramente, pode-se verificar a lógica de funcionamento dos sinais de
SYNC* e DVALID* ocorrendo conforme descreve a documentação do barramento
FPDP. É possível, no entanto, notar pequenos atrasos do clock de referência em relação
a estes sinais. Estes atrasos são explicados pelo fato de que o sinal de STROB é
resultante de um processamento analógico do sinal diferencial de PSTROBE,
processamento este feito por um CI que converte o nível lógico de PECL para TTL.
Este processo, então, acaba gerando algum atraso, o que não chega a ser prejudicial para
o sistema como um todo, já que o receptor amostra os sinais somente na borda de subida
do clock.
Prosseguindo a análise do gráfico, nota-se que o barramento de dados
disponibiliza, em sua segunda e terceira palavras, os valores em hexadecimal
0x00CC1FC4 e 0x00000038, respectivamente. Isso representa, em termos de números
binários, e tomando como base a estrutura da PDW descrita na Tabela 5.1, uma LP de
0000000011001100, frequência da portadora igual a 01111111000100 e amplitude de
00111000. Realizando a conversão desses valores para seus correspondentes decimais,
por meio das fórmulas de conversão descritas na Tabela 5.4, tem-se, para a LP, 1,02 μs,
aproximadamente 1,9854 GHz para a frequência da portadora e, para a amplitude, -47
dBm. Estes valores coincidem com os configurados nos equipamentos usados como
entrada para o IFM, sendo os erros de +2%, para a LP, e -0,7% para a frequência da
portadora, decorridos de erros dos próprios equipamentos geradores. O erro na
amplitude é devido à atenuação de aproximadamente 6 dBm ocasionada pelos
76
conectores e cabos de RF que conduzem o sinal do gerador de RF ao gerador de pulsos
e deste ao IFM.
Para a primeira palavra da PDW, que contém o TOA, tem-se o valor em
hexadecimal 0xAC5CFD76. Diminuindo-se deste valor o TOA encontrado no pulso
anterior, o qual está ilustrado na Figura 6.41, isto é, 0xAC59B080, resulta em
0x00034CF6, que, por sua vez, aplicando-se a fórmula de conversão da Tabela 5.4 para
a PRI, conduz ao valor de 1,082 ms, aproximadamente o valor da PRI configurada no
gerador de pulsos.
Figura 6.40 – Teste da PDW do IFM referente ao modelo S.
Figura 6.41 – Teste da PDW anterior do IFM referente ao modelo S.
A partir de agora, nos gráficos seguintes serão apresentados os testes do IFM
tomado como referência para o modelo K. Para este caso também os valores dos
parâmetros ajustados nos equipamentos são iguais aos definidos para o modo master,
porém desta vez para o EDIFM de modelo K, segundo a Tabela 5.3.
Dessa forma, a Figura 6.42 contém a forma de onda do clock medido para o
segundo modelo de IFM, referência para o modelo K. Mais uma vez utilizando-se as
marcações M1 e M2 do gráfico, obtém-se 1/(M2 – M1) = 1/(26 ns) = 38,46 MHz, que é
aproximadamente a frequência do clock de saída deste IFM. Como seu clock máximo é
40 MHz, o clock medido apresenta um desvio menor do que -4% em relação ao valor
máximo, o que é plenamente aceitável.
77
Figura 6.42 – Teste do sinal de STROB do IFM referente ao modelo K.
Posteriormente, a Figura 6.43 mostra uma visão geral do padrão de transmissão
das PDWs no barramento FPDP. Com as marcações M1 e M2 é fácil obter que M2 –
M1 = 1 ms, cujo valor representa a PRI configurada para este IFM.
Figura 6.42 – Teste da PRI do IFM referente ao modelo K.
Do mesmo modo como foi feito com o primeiro IFM, é possível também
aproximar-se o gráfico para verificar o conteúdo do barramento no momento exato da
disponibilização da PDW, estando tal conteúdo apresentado na Figura 6.43.
Pode-se logo de início perceber que a lógica de funcionamento dos sinais de
SYNC* e DVALID* é exatamente a mesma do caso anterior, o que já era esperado,
com base na documentação do barramento FPDP.
Partindo-se então para a análise do gráfico, nota-se que o barramento de dados
disponibiliza, em sua segunda e terceira palavras, os valores em hexadecimal
0x00C57036 e 0x00000047, respectivamente. Isso representa, em termos de números
binários, e tomando como base a estrutura da PDW descrita na Tabela 5.2, uma LP de
0000000011000101, frequência da portadora igual a 011100000011011 e amplitude de
01000111. Realizando a conversão desses valores para seus correspondentes decimais,
por meio das fórmulas de conversão descritas na Tabela 5.4, tem-se, para a LP, 0,985
μs, 8,989 GHz para a frequência da portadora e, para a amplitude, -40 dBm. Estes
78
valores de fato condizem com os configurados nos equipamentos usados como entrada
para o IFM, sendo que os erros de -1,5% para a LP, e -0,1% para a frequência da
portadora, são decorridos de erros dos próprios equipamentos geradores.
Para a primeira palavra da PDW, que contém o TOA, tem-se o valor em
hexadecimal 0xEFD62146. Diminuindo-se deste valor o TOA encontrado no pulso
anterior, o qual está ilustrado na Figura 6.41, isto é, 0xEFD314B4, resulta em
0x00030C92, que, por sua vez, aplicando-se a fórmula de conversão da Tabela 5.5 para
a PRI, conduz ao valor de 1 ms, exatamente o valor da PRI configurada no gerador de
pulsos.
Figura 6.43 – Teste da PDW do IFM referente ao modelo K.
Figura 6.44 – Teste da PDW anterior do IFM referente ao modelo K.
6.2.2 – EDIFM
A segunda etapa dos testes de hardware consiste nos testes do EDIFM
desenvolvido no presente projeto.
Primeiramente, em relação à Placa de Interface do EDIFM, é necessário
esclarecer que, em virtude da quantidade de camadas e de furos metalizados contidos na
placa, e de requisitos rígidos como largura e distância máxima das trilhas, o custo de
fabricação da PCI tornou-se tão alto a ponto de inviabilizá-la. A principal consequência
79
disso é o impedimento da realização de testes completos, com o EDIFM conectado
diretamente ao barramento FPDP.
Apesar disso, foi montado um pequeno protótipo em protoboard, apresentado na
Figura 6.45, que tem como objetivo permitir a realização de testes nos quais, mesmo
não contendo todo o circuito da Placa de Interface, pudessem ser verificadas as
principais funcionalidades da mesma, possuindo também total conectividade com o
FPGA. Na prática, somente não puderam ser efetivamente testados os circuitos
responsáveis pelo condicionamento dos sinais elétricos para o padrão do barramento
FPDP, e portanto a lógica dos mesmos não sofreu nenhum prejuízo.
Figura 6.45 – Protótipo em protoboard montado para a execução dos testes.
Na figura, podem ser observados os seguintes componentes: LEDs de indicação
das alimentações de 12 V e 3,3 V vindas do FPGA, de cor verde, dos 5 V gerados a
partir dos 12 V, de cor vermelha, e de transmissão no barramento, de cor azul,
juntamente com seus respectivos resistores limitadores de corrente; circuito conversor
12V-to-5V, utilizando o CI LM7805 e capacitores; circuito conversor serial, utilizando
o CI MAX232 e capacitores; circuito conversor TTL-to-LVTTL, soldado em adaptador
80
para acesso aos pinos; e três chaves de duas posições, estas podendo ser vistas na Figura
6.46, onde também aparece o analisador lógico empregado nos testes. Todos os
módulos funcionaram conforme o esperado.
Figura 6.46 – Hardware usado para os testes no analisador lógico.
A Figura 6.47, por sua vez, mostra com mais detalhes a placa de
desenvolvimento FPGA, juntamente com a placa prototipadora já conectada à mesma e
com as pontas de prova do analisador lógico também colocadas, e o conector serial, do
qual se aproveitam os sinais de GND e TX utilizando-se fios com extremidades do tipo
garra para permitir melhor fixação aos referidos pinos.
81
Figura 6.47 – Detalhe da placa de desenvolvimento FPGA conectada à placa
prototipadora.
Antes de dar início à apresentação dos gráficos dos testes, de forma semelhante
ao caso das simulações, na seção 6.1, apesar de não explicitado, assume-se que os sinais
de reset_n, nao_pronto_n, suspender_n e on_off_n estão todos em nível lógico alto. As
entradas que variam são modo_operacao e modelo_ifm, cujos valores serão mostrados
em cada uma das situações. O sinal de saída direcao_n é sempre mantido em nível
lógico baixo, conforme o padrão do barramento para o transmissor.
Assim sendo, tem-se apresentada, na Figura 6.48, a forma de onda do clock
gerado com o modelo S selecionado, isto é, modelo_ifm = 0. Utilizando-se as marcações
M1 e M2 como referência, pode-se concluir que a frequência medida para este clock foi
de 1/(M2 – M1) = 1/(50 ns), ou seja, 20 MHz, conferindo com o esperado.
82
Figura 6.48 – Teste do sinal de clock_saida do modelo S.
Na Figura 6.49 tem-se a mesma situação, porém com modelo_ifm = 1. Com isso
pode-se medir a frequência do clock gerado no caso do modelo K ter sido selecionado.
Mais uma vez usando-se as marcações M1 e M2, tem-se 1/(M2 – M1) = 1/(26 ns) =
38,46 MHz para tal frequência, concordando com o resultado dos testes feitos com o
IFM real.
Figura 6.49 – Teste do sinal de clock_saida do modelo K.
Em seguida, na Figura 6.50, é mostrado o padrão de transmissão ao longo do
tempo com o modo master aplicado ao modelo S, tendo-se então modo_operacao = 1 e
modelo_ifm = 0 para este caso. Novamente fazendo uso das marcações no gráfico, é
possível medir a PRI deste pulso, pois M2 – M1 = 1 ms, que é justamente a PRI
configurada para o modo master.
83
Figura 6.50 – Teste da PRI do modelo S no modo master.
Ampliando-se o gráfico para observar o conteúdo do barramento de dados no
momento da transmissão da PDW, o que se tem é o representado na Figura 6.51. Em
primeiro lugar, é possível notar o funcionamento dos sinais de sync_n e dado_valido_n
ocorrendo exatamente da forma como foi modelado, simulado e testado. Em segundo
lugar, o barramento de dados disponibiliza, em sua segunda e terceira palavras, os
valores em hexadecimal 0x00C82000 e 0x00000046, respectivamente. Isso representa,
em termos de números binários, e tomando como base a estrutura da PDW descrita na
Tabela 5.1, uma LP de 0000000011001000, frequência da portadora igual a
10000000000000 e amplitude de 01000110. Realizando a conversão desses valores para
seus correspondentes decimais, por meio das fórmulas de conversão descritas na Tabela
5.4, tem-se, para a LP, 1 μs, 2 GHz para a frequência da portadora e, para a amplitude, -
40 dBm, estando também de acordo com o esperado.
No caso da primeira palavra, que contém o TOA, tem-se o valor em
hexadecimal 0x803AB400. Este valor, diminuído do valor do TOA encontrado no pulso
seguinte, o qual está ilustrado na Figura 6.52, isto é, 0x803DC140, resulta em
0x00030D40, que, por sua vez, aplicando-se a fórmula de conversão da Tabela 5.4 para
a PRI, conduz ao valor final de 1 ms, exatamente o valor da PRI encontrada para este
pulso.
84
Figura 6.51 – Teste da PDW do modelo S no modo master.
Figura 6.52 – Teste da PDW seguinte do modelo S no modo master.
A seguir, faz-se o mesmo procedimento para o IFM de modelo K. Para isso,
mantém-se modo_operacao = 1 (modo master), impondo agora modelo_ifm = 1. De
forma análoga ao caso do modelo S, é apresentado na Figura 6.53 o padrão de
transmissão da PDW. Através das marcações M1 e M2, é possível fazer M2 – M1,
resultando em 1 ms, conforme previsto.
85
Figura 6.53 – Teste da PRI do modelo K no modo master.
Repetindo o procedimento realizado para o caso do modelo S, pode-se também
ampliar o gráfico para observar o conteúdo do barramento de dados. Representado na
Figura 6.54, o gráfico mostra a segunda palavra contendo o valor em hexadecimal
0x00C87060, enquanto a terceira palavra contém 0x00000046. Da mesma maneira, tais
valores representam, em termos de números binários, e tomando como base a estrutura
da PDW descrita na Tabela 5.2, uma LP de 0000000011001000, frequência da
portadora igual a 111000001100000 e amplitude de 01000110. Realizando a conversão
desses valores para seus correspondentes decimais, por meio das fórmulas de conversão
descritas na Tabela 5.5, tem-se, para a LP, 1 μs, 9 GHz para a frequência da portadora e,
para a amplitude, -40 dBm, conforme o esperado.
Equivalentemente ao modelo S, no caso da primeira palavra, tem-se o valor em
hexadecimal 0x0E44F440, que, diminuído do valor do TOA encontrado no pulso
posterior, ilustrado na Figura 6.55, ou seja, 0x0E480180, resulta em 0x00030D40, o
qual, aplicando-se a fórmula de conversão da Tabela 5.5 para a PRI, conduz ao valor
final de 1 ms, que é novamente o valor exato da PRI encontrada para este pulso.
86
Figura 6.54 – Teste da PDW do modelo K no modo master.
Figura 6.55 – Teste da PDW seguinte do modelo K no modo master.
Para os testes seguintes, o modo operação foi alterado para o modo slave,
fazendo modo_operacao = 0.
A configuração dos valores dos parâmetros transmitidos pela porta serial, para
este caso, com modelo_ifm = 0 (modelo S), é definida no Programa Gerador de PDW
conforme mostra a Figura 6.56.
87
Figura 6.56 – Configuração dos parâmetros de teste do modelo S no modo slave.
Para se ter estes parâmetros de pulso em específico, as três palavras da PDW que
o descreve devem ser, respectivamente: 00000000000000000100111000100000,
00000111110100000001000000000000 e 00000000000000000000000010001100,
conforme a Tabela 5.1 e a Tabela 5.4. Dessa maneira, a Figura 6.57 apresenta
inicialmente a forma de onda da PDW sendo transmitida na interface serial e, no tempo
restante, as primeiras PDWs sendo transmitidas no barramento.
Figura 6.57 – Teste do sinal de serial_entrada do modelo S no modo slave.
88
Aproximando-se o gráfico, pode-se medir, a partir do emprego das marcações
M1 e M2, fazendo-se M2 – M1, a PRI de 100 μs configurada e transmitida via interface
serial. Essa medida encontra-se na Figura 6.58.
Figura 6.58 – Teste da PRI do modelo S no modo slave.
Assim como no modo master, no modo slave pode-se aproximar ainda mais o
gráfico a fim de verificar cada uma das palavras disponibilizadas no barramento de
dados. O gráfico da Figura 6.59 mostra que a segunda palavra contém o valor em
hexadecimal 0x07D01000, ao passo que a terceira, 0x0000008C. Estes valores, em
termos de números binários, representam uma LP de 0000011111010000, frequência da
portadora igual a 01000000000000 e amplitude de 10001100. Realizando a conversão
desses valores para seus respectivos decimais equivalentes, chega-se a uma LP de 10 μs,
frequência da portadora de 1 GHz e amplitude igual a -5 dBm, estando portanto de
acordo com os definidos para a transmissão serial.
Para a primeira palavra, tem-se o valor em hexadecimal 0x0007A120, o qual,
diminuído do valor do TOA do pulso seguinte, encontrado na Figura 6.60, isto é,
0x0007EF40, resulta em 0x00004E20, cujo valor em decimal está em conformidade
com os 100 μs equivalentes à PRI definida anteriormente.
89
Figura 6.59 – Teste da PDW do modelo S no modo slave.
Figura 6.60 – Teste da PDW seguinte do modelo S no modo slave.
Agora, o mesmo procedimento é executado para o IFM de modelo K. Dessa
forma, o sinal de modo_operacao é mantido em 1, caracterizando modo master, mas
desta vez com modelo_ifm também em 1.
De forma semelhante ao caso do modelo S, a configuração dos valores dos
parâmetros transmitidos pela porta serial, para este caso, com modelo_ifm = 1 (modelo
K), é definida no Programa Gerador de PDW conforme mostra a Figura 6.61.
90
Figura 6.61 – Configuração dos parâmetros de teste do modelo K no modo slave.
Para se ter estes parâmetros, de modo análogo ao que foi visto com o modelo S,
é preciso que as três palavras da PDW sejam, respectivamente:
00000000000000000000000011001000, 00000000000101001000000000000000 e
00000000000000000000000010010110, conforme a Tabela 5.2 e a Tabela 5.5. Dessa
maneira, a Figura 6.62 apresenta inicialmente a forma de onda da PDW sendo
transmitida na interface serial e, no tempo restante, as primeiras PDWs sendo
transmitidas no barramento.
91
Figura 6.62 – Teste do sinal de serial_entrada do modelo K no modo slave.
Com uma aproximação no gráfico é possível medir, com as marcações M1 e
M2, a PRI que caracteriza este pulso. Fazendo-se M2 – M1 na Figura 6.63 resulta 1 μs,
que é exatamente a PRI configurada e transmitida via interface serial.
Figura 6.63 – Teste da PRI do modelo K no modo slave.
Observando-se com mais detalhes o gráfico, como demonstrado na Figura 6.64,
pode-se verificar o conteúdo de cada uma das palavras disponibilizadas no barramento.
A segunda palavra contém o valor em hexadecimal 0x00148000, e a terceira,
0x00000096. Estes valores, em termos de números binários, representam uma LP de
0000000000010100, frequência da portadora igual a 100000000000000 e amplitude de
10010110. Realizando-se a conversão desses valores para seus decimais
correspondentes, encontra-se uma LP de 100 ns, 10 GHz de frequência da portadora e 0
dBm de amplitude, os quais correspondem aos configurados para transmissão via
interface serial.
92
Além disso, a primeira palavra apresenta o valor em hexadecimal 0x00A22E3F,
que, diminuído do valor do TOA do pulso seguinte, da Figura 6.65, isto é, 0x00A22F07,
resulta no valor 0x000000C8, que é, em decimal, igual a 1 μs, de fato a mesma PRI
definida para a transmissão.
Figura 6.64 – Teste da PDW do modelo K no modo slave.
Figura 6.65 – Teste da PDW seguinte do modelo K no modo slave.
Os testes a seguir são usados para ilustrar a lógica de funcionamento dos sinais
de controle.
O primeiro deles, apresentado na Figura 6.66, trata do sinal assíncrono de
reset_n aplicado ao EDIFM operando em modo master. Nota-se que, assim que vai a
nível lógico baixo, o sinal de reset_n reinicializa o sistema, parando a transmissão, a
qual somente retorna quando reset_n = 1, conforme mostra a Figura 6.67. A Figura
6.68, por sua vez, demonstra que assim que a transmissão é retomada, a primeira
93
palavra da PDW está zerada, significando que o TOA é de fato reinicializado. Esse
comportamento reproduz exatamente o que foi simulado.
Figura 6.66 – Teste da ativação do sinal de reset_n no modo master.
Figura 6.67 – Teste da desativação do sinal de reset_n no modo master.
94
Figura 6.68 – Teste da PDW na desativação do sinal de reset_n no modo master.
Adicionalmente, a mesma situação em relação ao sinal de reset_n é apresentada
a seguir, na Figura 6.69, porém com modo de operação slave. Pode-se perceber que, de
forma idêntica à simulação, o funcionamento é similar ao caso anterior, à exceção de
que, neste modo, a transmissão não é retomada com o retorno de reset_n para nível
lógico alto, como pode ser confirmado na Figura 6.70.
Figura 6.69 – Teste da ativação do sinal de reset_n no modo slave.
95
Figura 6.70 – Teste da desativação do sinal de reset_n no modo slave.
Dando prosseguimento, a Figura 6.71 apresenta o sinal de nao_pronto_n e seu
funcionamento, que é idêntico para ambos os modos de operação. Nela pode ser visto
que, quando ativado simultaneamente ao início da transmissão, a mesma não acontece,
até que nao_pronto_n = 1. Após isso, conforme consta na Figura 6.72, este sinal pode ir
novamente a nível lógico baixo, por inúmeras vezes, que ele será ignorado pelo
transmissor, só podendo voltar a ser amostrado caso o sinal de reset_n seja ativado,
reinicializando todo o sistema. Isso também confirma os resultados obtidos na
simulação.
96
Figura 6.71 – Teste da desativação do sinal de nao_pronto_n.
Figura 6.72 – Teste da ativação do sinal de nao_pronto_n.
O próximo sinal de controle cujo funcionamento será testado é o suspender_n.
Na Figura 6.73, tem-se este sinal sendo colocado em nível lógico baixo a fim de
suspender a transmissão, no modo master. Quando em nível alto, a mesma é retomada
imediatamente, de acordo com a Figura 6.74.
97
Figura 6.73 – Teste da ativação do sinal de suspender_n no modo master.
Figura 6.74 – Teste da desativação do sinal de suspender_n no modo master.
Pode-se perceber que o mesmo ocorre quando em modo de operação slave,
onde, diferentemente do sinal de reset_n, após suspensão da transmissão, na Figura
6.75, a mesma é retomada, na Figura 6.76, quando suspender_n é colocado de volta em
nível lógico alto. Tal comportamento do sinal de suspender_n é o mesmo do que foi
simulado na seção 6.1.
98
Figura 6.75 – Teste da ativação do sinal de suspender_n no modo slave.
Figura 6.76 – Teste da desativação do sinal de suspender_n no modo slave.
Em seguida, tem-se a demonstração da lógica do sinal de on_off_n. À
semelhança dos resultados das simulações, seu funcionamento é rigorosamente igual ao
do sinal de suspender_n, sendo o primeiro controlado pelo usuário por meio de uma
chave na Placa de Interface, e o segundo controlado pelo receptor via barramento FPDP,
conforme já explanado nesse texto. Sua ativação encontra-se ilustrada na Figura 6.77 e
99
sua desativação na Figura 6.78, para o modo master, e, para o modo slave, sua ativação
está na Figura 6.79 e desativação na Figura 6.80.
Figura 6.77 – Teste da ativação do sinal de on_off_n no modo master.
Figura 6.78 – Teste da desativação do sinal de on_off_n no modo master.
100
Figura 6.79 – Teste da ativação do sinal de on_off_n no modo slave.
Figura 6.80 – Teste da desativação do sinal de on_off_n no modo slave.
O gráfico de teste da Figura 6.81, por sua vez, demonstra uma transição de
modelo de IFM, neste caso, do modelo S para o modelo K, com o EDIFM operando em
modo master. Isso é feito com o sinal de modelo_ifm passando de nível lógico baixo
para alto. Pelo gráfico, conclui-se que, conforme o que foi simulado, a transmissão da
PDW do modelo S é imediatamente cessada, passando o sistema a transmitir no
101
barramento a PDW definida para o modelo K. Além disso, é importante ressaltar que,
nessa transição, o TOA é zerado, fato que pode ser comprovado na Figura 6.82.
Figura 6.81 – Teste da transição do modelo S para o modelo K no modo master.
Figura 6.82 – Teste da PDW na transição do modelo S para o modelo K no modo
master.
O mesmo teste é feito para o caso de modo de operação slave. Neste caso,
representado pela Figura 6.83, com uma mudança no modelo de IFM a ser emulado, a
102
transmissão é interrompida. A justificativa para esse comportamento é rigorosamente a
mesma para o caso simulado.
Figura 6.83 – Teste da transição do modelo S para o modelo K no modo slave.
Por último, é ilustrada a situação de mudança de modo de operação. A Figura
6.84 apresenta a mudança de modo master para modo slave. Nela pode-se notar que a
transmissão é suspensa por tempo indeterminado, até que uma PDW seja carregada pela
porta serial.
103
Figura 6.84 – Teste da transição do modo de operação master para o slave.
Por sua vez, a Figura 6.85 apresenta a alteração inversa, isto é, de modo slave
para modo master. Nessa situação a transmissão é prontamente reiniciada com as novas
configurações de PDW, estabelecidas pelo próprio programa, e o TOA é zerado,
conforme mostra a Figura 6.86. Ambas as situações repetem o ocorrido nas simulações.
Figura 6.85 – Teste da transição do modo de operação slave para o master.
104
Figura 6.86 – Teste da PDW na transição do modo de operação slave para o master.
105
Capítulo 7
Conclusões
A partir da análise dos resultados dos testes apresentados ao longo de todo o
capítulo 6, pode-se afirmar que, mesmo não tendo sido fabricada a Placa de Interface,
foi possível atestar o funcionamento da lógica do EDIFM conforme modelado e
simulado. Tais resultados também conferiram com os testes feitos sobre as principais
referências para o emulador, isto é, os próprios equipamentos IFM. Tendo em vista tais
fatos, pode-se concluir que o desenvolvimento do presente projeto foi plenamente bem
sucedido.
Diversos pontos positivos decorrentes da metodologia de projeto utilizada
podem ser mencionados. Apenas para citar dois deles, pode-se ressaltar o emprego de
ferramentas gratuitas e de software livre, amplamente utilizadas no mercado, o que
facilita a execução de melhorias no trabalho, e o uso de linguagens de alto grau de
portabilidade, como o VHDL, que permitem a implementação do código em FPGAs
mais modernas do que a utilizada no projeto.
Além disso, é necessário também ratificar a importância das disciplinas cursadas
durante todo o curso de Engenharia Eletrônica e de Computação, pois estas forneceram
as bases sólidas para que o projeto pudesse ser concebido de forma correta e eficiente.
Nesse sentido, a fim de aumentar ainda mais a relevância deste projeto como
aplicação prática, é válido idealizar e propor trabalhos futuros no sentido de trazer
melhorias ao mesmo.
O primeiro e mais óbvio desses trabalhos consiste na fabricação da Placa de
Interface do EDIFM, juntamente com sua modificação para facilitar o “empacotamento”
do sistema como um todo, acomodando-a, por exemplo, como um mezanino sobre a
placa FPGA. Isso permitiria, inclusive, tornar este protótipo um produto
comercializável, face a sua grande aplicabilidade, especialmente para a indústria de
Defesa.
Outra proposta interessante seria a mudança da interface entre o computador e o
EDIFM, de serial RS-232 para USB, o que ampliaria as possibilidades de uso, uma vez
106
que a interface USB, nos dias de hoje, está amplamente difundida, em contraste à
obsolescência da serial RS-232.
Por último, como sugestão de melhoria para o trabalho pode-se citar também a
modificação tanto no programa “gerador_fpdp” quanto no software Gerador de PDW
para incluir a possibilidade de se gerar múltiplos emissores, o que permitiria simular um
cenário ainda mais próximo do real.
107
Bibliografia
[1] STIMSON, G. W., Introduction to Airborne Radar, Second Edition. New Jersey,
SciTech Publishing, Inc., 1998.
[2] American National Standard for Front Panel Data Port Specifications, Report
ANSI/VITA 17-1998, VMEbus International Trade Association, American
National Standards Institute, Inc., 1999.
[3] “Quartus II Web Edition Software”, 2012,
https://www.altera.com/download/software/quartus-ii-we/12.0sp2, (Acesso em 05
Agosto 2014).
[4] “ModelSim-Altera Starter Software”, 2012,
https://www.altera.com/download/software/modelsim-starter/12.0, (Acesso em 05
Agosto 2014).
[5] “OrCAD Downloads”, http://www.orcad.com/resources/orcad-downloads, (Acesso
em 05 Agosto 2014).
[6] “Download Qt”, http://qt-project.org/downloads, (Acesso em 05 Agosto 2014).
[7] BURKE, T., “Writing bytes to a serial port in C”, 2013,
http://batchloaf.wordpress.com/2013/02/13/writing-bytes-to-a-serial-port-in-c/,
(Acesso em 05 Agosto 2014).
[8] “UART, Serial Port, RS-232 Interface VHDL Module”,
http://www.nandland.com/vhdl/modules/module-uart-serial-port-rs232.html,
(Acesso em 05 Agosto 2014).