Desarrollo de etapa digital para radar pulsado
multipropósitoMEMORIA DEL TRABAJO FINAL
Autor: Ing. Santiago Abbate
Codirector: Dr. Ing. Javier Areta (UNRN)
Jurados: Ing. Federico Zacchigna (FIUBA)
Mg. Lic. Santiago Germino (FIUBA) Ing. Esteban Volentini
(UNT)
Este trabajo fue realizado en la ciudad de San Carlos de Bariloche,
entre agosto de 2019 y diciembre de 2020.
I
Resumen
El presente trabajo comprende la implementación de un prototipo de
las etapas de transmisión y recepción digitales para un futuro
radar pulsado
multipropósito, enmarcado dentro de las líneas de trabajo del
Centro Interdisciplinario de Telecomunicaciones, Electrónica,
Computación y Ciencia
Aplicada perteneciente a la Universidad Nacional de Río Negro. El
diseño realizado contempla un generador de las señales a
transmitir, moduladas en
frecuencia y fase, empleadas típicamente en sistemas de este tipo,
y además, la implementación de un módulo para demodulación de
señales en fase y
cuadratura. Cada subsistema, desarrollado en lógica programable,
puede configurarse por software de forma de variar los parámetros a
utilizar por el radar, y es posible también la descarga de los
datos a través de una conexión
Ethernet.
Se aplicaron en este trabajo conceptos de lógica programable,
desarrollo de firmware y drivers, sistemas operativos de tiempo
real, protocolos de
comunicación y encapsulamiento de datos, y procesamiento de
señales. Además se desarrolló un banco de pruebas en la PC para
control del sistema, que
incorpora programación de alto nivel.
III
1. Introducción general 1 1.1. Sistemas RADAR . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . 1
1.1.1. Parámetros representativos . . . . . . . . . . . . . . . . .
. . 2 Rango como medida del tiempo de viaje . . . . . . . . . . . 2
Compresión de pulso . . . . . . . . . . . . . . . . . . . . . . . 2
Frecuencia de repetición de pulsos, ambigüedades en rango
y velocidad . . . . . . . . . . . . . . . . . . . . . . . 3 1.1.2.
Señales características . . . . . . . . . . . . . . . . . . . . . .
4
Chirp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. 4 Códigos Barker . . . . . . . . . . . . . . . . . . . . . . . .
. . 4
1.1.3. Radares ejemplo . . . . . . . . . . . . . . . . . . . . . .
. . . 5 1.2. Motivación del desarrollo . . . . . . . . . . . . . .
. . . . . . . . . . 6
1.2.1. Objetivos y especificaciones . . . . . . . . . . . . . . . .
. . . 7
2. Introducción específica 9 2.1. Plataforma de desarrollo . . . .
. . . . . . . . . . . . . . . . . . . . . 9
Arquitectura Zynq-7000 . . . . . . . . . . . . . . . . . . . . . 9
2.2. Buses y camino de datos . . . . . . . . . . . . . . . . . . .
. . . . . . 11 2.3. Síntesis digital de señales . . . . . . . . . .
. . . . . . . . . . . . . . 13 2.4. Demodulación I/Q . . . . . . .
. . . . . . . . . . . . . . . . . . . . . 14
2.4.1. Decimación y filtrado . . . . . . . . . . . . . . . . . . .
. . . 15 2.5. Protocol Buffers . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . 16
3. Diseño e implementación 17 3.1. Arquitectura del sistema . . . .
. . . . . . . . . . . . . . . . . . . . . 17 3.2. Lógica
programable . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
3.2.1. Banco de registros AXI-Lite . . . . . . . . . . . . . . . .
. . . 19 3.2.2. Generador . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . 20
Modos de operación . . . . . . . . . . . . . . . . . . . . . . . 21
Mapa de memoria . . . . . . . . . . . . . . . . . . . . . . . . 23
Modo continuo o pulsado . . . . . . . . . . . . . . . . . . . . 25
Modulación en frecuencia . . . . . . . . . . . . . . . . . . . . 25
Modulación en fase . . . . . . . . . . . . . . . . . . . . . . . .
26
3.2.3. Demodulador . . . . . . . . . . . . . . . . . . . . . . . .
. . . 28 Mapa de memoria . . . . . . . . . . . . . . . . . . . . .
. . . 29 Mixer . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . 30 Decimación y filtrado . . . . . . . . . . . . . . .
. . . . . . . 31
3.2.4. Empaquetamiento de datos . . . . . . . . . . . . . . . . . .
. 32 3.3. Software . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . 33
3.3.1. Drivers . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . 34 3.3.2. Aplicación . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . 36
IV
4. Ensayos y Resultados 39 4.1. Banco de pruebas . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . 39 4.2. Generador . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.2.1. Modo continuo y frecuencia constante . . . . . . . . . . . .
. 41 4.2.2. Modo pulsado y frecuencia constante . . . . . . . . . .
. . . 44 4.2.3. Modo continuo y modulación en frecuencia . . . . .
. . . . 45 4.2.4. Modo pulsado y modulación en frecuencia . . . . .
. . . . . 47 4.2.5. Modo pulsado y modulación en fase . . . . . . .
. . . . . . . 47
4.3. Demodulador . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . 50 4.3.1. Modo continuo . . . . . . . . . . . . . . . .
. . . . . . . . . . 50 4.3.2. Modo pulsado . . . . . . . . . . . .
. . . . . . . . . . . . . . . 55
4.4. Recursos utilizados . . . . . . . . . . . . . . . . . . . . .
. . . . . . . 58
5. Conclusiones 59 5.1. Resultados obtenidos . . . . . . . . . . .
. . . . . . . . . . . . . . . . 59 5.2. Próximos pasos . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . 60
Bibliografía 61
Índice de figuras
1.1. Principio de operación de un RADAR. . . . . . . . . . . . . .
. . . . 1 1.2. Tiempo de repetición entre pulsos y ambigüedad en
rango. . . . . . 3 1.3. Representación de una señal de radar
modulada linealmente en
frecuencia (chirp). . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . 4 1.4. Código Barker número 7 aplicado a una señal
senoidal. . . . . . . . 5
2.1. Arquitectura interna del SoC Zynq-7000. . . . . . . . . . . .
. . . . . 11 2.2. Sistema de procesamiento con interconexiones AXI.
. . . . . . . . . 12 2.3. Arquitectura genérica de un DDS. . . . .
. . . . . . . . . . . . . . . 13 2.4. Demodulador I/Q. . . . . . .
. . . . . . . . . . . . . . . . . . . . . . 14 2.5. Espectro de las
etapas de demodulación. . . . . . . . . . . . . . . . . 15 2.6.
Cascada de elementos para decimación y filtrado. . . . . . . . . .
. 16
3.1. Arquitectura del sistema implementado. . . . . . . . . . . . .
. . . . 17 3.2. Banco de registros implementado. . . . . . . . . .
. . . . . . . . . . 19 3.3. Máquinas de estado del protocolo
AXI4-Lite. . . . . . . . . . . . . . 20 3.4. Arquitectura general
del módulo generador. . . . . . . . . . . . . . 21 3.5. Diagrama
esquemático del bloque modulador. . . . . . . . . . . . . 22 3.6.
Contador para generación de pulsos. . . . . . . . . . . . . . . . .
. . 25 3.7. Contador para modulación en frecuencia. . . . . . . . .
. . . . . . . 26 3.8. Secuencia Barker número siete y definición de
“subpulso”. . . . . . 27 3.9. Selección de cambio de fase en
función de la secuencia Barker. . . . 27 3.10. Espectros de
posibles señales a demodular. . . . . . . . . . . . . . . 28 3.11.
Arquitectura interna del módulo demodulador. . . . . . . . . . . .
29 3.12. Campos de datos de los buses AXI-Stream del multipicador.
. . . . 31 3.13. Respuesta de las etapas de decimación y filtrado
para R = 70. . . . 33 3.14. Capas del software desarrollado. . . .
. . . . . . . . . . . . . . . . . 34 3.15. Estructura de los
mensajes diseñados con Protobuf. . . . . . . . . . 38
4.1. Esquema de conexiones del sistema. . . . . . . . . . . . . . .
. . . . 39 4.2. Diagrama de clases del banco de pruebas. . . . . .
. . . . . . . . . . 40 4.3. Muestras I y Q generadas para una señal
de 1 MHz. . . . . . . . . . 41 4.4. Espectro de la señal mostrada
en la figura 4.3. . . . . . . . . . . . . . 42 4.5. Muestras I y Q
generadas para una señal de 20 MHz. . . . . . . . . 42 4.6.
Espectro de la señal mostrada en la figura 4.5. . . . . . . . . . .
. . . 43 4.7. Muestras I y Q generadas para una señal pulsada de
200 kHz, pe-
ríodo de 100 µs y ancho de pulso de 20 µs. . . . . . . . . . . . .
. . . 44 4.8. Muestras I y Q generadas para una señal pulsada de 1
MHz, perío-
do de 15 µs y ancho de pulso de 10 µs. . . . . . . . . . . . . . .
. . . 45 4.9. Muestras I y Q generadas para una señal modulada en
frecuencia
de 0 Hz a 300 kHz en un intervalo de 250 µs. . . . . . . . . . . .
. . 46 4.10. Espectrograma para una señal modulada en frecuencia de
1 MHz
a 5 MHz en un intervalo de 100 µs. . . . . . . . . . . . . . . . .
. . . 46
VI
4.11. Espectrograma para una señal modulada en frecuencia de 0 MHz
a 20 MHz en un pulso de ancho 200 µs y un período de 250 µs. . . .
47
4.12. Secuencia Barker número 7 y su correlación. . . . . . . . . .
. . . . 48 4.13. Secuencia Barker número 13 y su correlación. . . .
. . . . . . . . . . 49 4.14. Señal de 1 MHz de ancho de banda
centrada en una frecuencia
intermedia de 40 MHz, inyectada al demodulador. . . . . . . . . . .
51 4.15. Señal de 1 MHz de ancho de banda, demodulada a banda base.
. . 51 4.16. Señal de 5 MHz de ancho de banda centrada en una
frecuencia
intermedia de 20 MHz, inyectada al demodulador. . . . . . . . . . .
52 4.17. Señal de 5 MHz de ancho de banda, demodulada a banda base.
. . 52 4.18. Señal de 20 MHz de ancho de banda centrada en una
frecuencia
intermedia de 30 MHz e inyectada al demodulador. . . . . . . . . .
53 4.19. Señal de 20 MHz de ancho de banda demodulada a banda base.
. . 54 4.20. Señal de 20 MHz de ancho de banda demodulada a banda
base. . . 55 4.21. Señal de 15 MHz de ancho de banda, centrada en
una frecuencia
de 40 MHz y pulsada con un ancho de pulso y período de 100 µs y 250
µs, respectivamente. . . . . . . . . . . . . . . . . . . . . . . .
. . 56
4.22. Señal de 15 MHz de ancho de banda y pulsada con un ancho de
pulso y período de 100 µs y 250 µs, respectivamente, demodulada a
banda base. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . 56
4.23. Señal de 1 MHz de ancho de banda, centrada en una frecuencia
de 10 MHz y pulsada con un ancho de pulso y período de 100 µs y 250
µs, respectivamente. . . . . . . . . . . . . . . . . . . . . . . .
. . . . 57
4.24. Señal de 1 MHz de ancho de banda y pulsada con un ancho de
pulso y período de 100 µs y 250 µs, respectivamente, demodulada a
banda base. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . 57
4.25. Reporte de utilización global, en porcentaje del total de
cada blo- que lógico, y en cantidad de elementos utilizados. . . .
. . . . . . . 58
VII
Índice de tablas
1.1. Códigos Barker. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . 5 1.2. Ejemplo de algunos sistemas radar para
aplicaciones diversas. . . . 6 1.3. Requerimientos del trabajo. . .
. . . . . . . . . . . . . . . . . . . . . 8
2.1. Plataformas de desarrollo evaluadas. . . . . . . . . . . . . .
. . . . . 10
3.1. Parámetros de las interfaces a nivel sistema. . . . . . . . .
. . . . . . 18 3.2. Parámetros de radar elegidos. . . . . . . . . .
. . . . . . . . . . . . . 18 3.3. Campos de configuración del DDS
Compiler presentes en el canal
de configuración PHASE del core. . . . . . . . . . . . . . . . . .
. . . 21 3.4. Modos de operación y acciones sobre los canales de
configuración
del DDS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . 22 3.5. Mapa de memoria del módulo generador. . . . . . .
. . . . . . . . . 24 3.6. Rangos de operación del demodulador. . .
. . . . . . . . . . . . . . 29 3.7. Mapa de memoria del módulo
demodulador. . . . . . . . . . . . . . 30 3.8. Atenuación para cada
escenario de ancho de banda esperado. Fil-
tro CIC configurado con M = 1 y N = 3. . . . . . . . . . . . . . .
. . 32 3.9. Tareas del sistema completo ordenadas de forma
descendente por
orden de creación y ejecución. . . . . . . . . . . . . . . . . . .
. . . . 37
4.1. Rangos de operación del demodulador. . . . . . . . . . . . . .
. . . 50 4.2. Configuraciones de ensayos de la sección. . . . . . .
. . . . . . . . . 55 4.3. Detalle de uso de los bloques DSP. . . .
. . . . . . . . . . . . . . . . 58
IX
1.1. Sistemas RADAR
El nombre RADAR (RAdio Detection And Ranging) indica ya desde sus
siglas la capacidad para medir rango (o distancia) mediante algún
tipo de sistema de ra- dio. La distancia a un objetivo puede
calcularse en base al tiempo que transcurre entre la emisión de un
pulso de radiofrecuencia y la recepción del eco de esa señal
transmitida. En la figura 1.1 se muestra esquemáticamente el
principio de opera- ción de un radar en el que se obtiene como
medición el tiempo de viaje del pulso transmitido.
Otra de las variables importantes que se obtiene del análisis de
los ecos que retor- nan es lo que se conoce como corrimiento
Doppler. Si el objetivo al que se apunta se mueve a una velocidad
relativa al radar, en línea al haz de la antena, la señal recibida
sufrirá una modificación en su frecuencia. A partir de la medición
de este fenómeno se pueden obtener mediciones de velocidad.
Asimismo, la magnitud de los ecos recibidos se puede utilizar para
obtener ca- racterísticas del objetivo, ya que la intensidad del
rebote dependerá de la reflecti- vidad del objeto respecto de las
señales de radiofrecuencia emitidas.
Transmisión
Recepción
Pulso
Eco
2
FIGURA 1.1. Principio de operación de un RADAR.
Los radares pueden dividirse en dos categorías: radar de onda
continua o radar pulsado. En el primero de los casos el sistema
está transmitiendo señales de for- ma continua mientras recibe la
energía retransmitida como eco desde el objetivo. Estos radades
resultan útiles para obtener mediciones de velocidad y, como se
está emitiendo constantemente, la medición de distancias se puede
realizar úni- camente al aplicar algún tipo de modulación a la
señal transmitida.
2 Capítulo 1. Introducción general
Por el contrario, un radar pulsado realiza una secuencia de
transmisión, espera y recepción, en la que emite los pulsos, se
apaga y luego “escucha” el retorno de los pulsos emitidos. Los
radares pulsados pueden utilizar la misma antena para transmisión y
recepción de señales, no así los radares de onda continua, pero
cuentan con la desventaja de requerir mayor complejidad en la
sincronización de transmisión y recepción.
1.1.1. Parámetros representativos
A continuación se describen algunos de los parámetros más
representativos de un radar pulsado. El detalle de estos parámetros
puede encontrarse en libros de texto sobre sistemas radar [1] y
sobre radar pulsado [2].
Rango como medida del tiempo de viaje
La ecuación 1.1 relaciona el tiempo de viaje t con la velocidad de
propagación c de las ondas de radiofrecuencia.
R = c · t 2
(1.1)
La capacidad de discernir la distancia entre dos objetivos está
relacionada, según la ecuación 1.2, con la duración τ de los pulsos
que se transmiten. Si el tiempo que demora el pulso en viajar la
distancia R que los separa es menor a la duración del pulso en sí
mismo, los ecos estarán superpuestos. El parámetro R se conoce como
resolución en rango. La ecuación 1.2 es válida para la transmisión
de pulsos rectangulares, es decir, una ventana de tiempo en la cual
se transmite una señal senodidal sin modulación en amplitud,
frecuencia o fase.
R = c · τ
Compresión de pulso
Si bien la ecuación 1.2 presenta un primer parámetro de diseño –el
ancho del pul- so a transmitir–, la resolución en rango de un radar
se puede definir también en base a otro parámetro de la señal que
se transmite. Mediante procesamiento de señales, en lo que se
conoce como “compresión de pulso”, se pueden transmitir pulsos de
mayor duración y menos energía e igualmente obtener mejor resolu-
ción en rango y detección de objetivos sobre el piso de ruido que
en situaciones de pulsos muy cortos.
La compresión de pulso mejora la resolución en rango mediante la
transmisión de pulsos de señales moduladas en frecuencia o en fase.
El resultado es la generación de señales en banda pasante, con un
cierto ancho de banda BW , cuyos ecos son procesados, por ejemplo,
mediante la “comparación” con la señal transmitida. Luego, lo que
se obtiene es una resolución en rango dada por:
R = c
1.1. Sistemas RADAR 3
El procesamiento sobre las señales recibidas se lleva a cabo
mediante la utilización de un filtro adaptado [3] que, básicamente,
realiza la correlación del eco recibido con la forma de onda
enviada. Es debido a esto que se busca en los sitemas radar la
transmisión de señales de gran ancho de banda y picos máximos de
autocorre- lación [4] grandes.
Frecuencia de repetición de pulsos, ambigüedades en rango y
velocidad
En un radar pulsado se emiten pulsos separados por un intervalo de
tiempo que se define como PRI (Pulse Repetition Interval). Y a su
vez, el recíproco de este intervalo se designa PRF (Pulse
Repetition Frequency). Si bien transmitir pulsos garantiza la
posibilidad de medir distancias, el valor de la PRF trae aparejadas
algunas particularidades respecto a qué magnitudes se podrán
medir.
La ecuación 1.1 parecería definir unívocamente la distancia a un
objetivo. Sin em- bargo, en el ámbito de un radar pulsado, esa
ecuación tiene un límite fijado por la PRF. Si se recibiera un eco
instantánteamente después de haber transmitido un segundo pulso,
podría no discernirse si se trata de un eco del primer o del segun-
do pulso. Esto se conoce como ambigüedad en rango, y se muestra un
esquema en la figura 1.2.
Pulsos
Ecos
R1
ambiguos
Tiempo
FIGURA 1.2. Tiempo de repetición entre pulsos y ambigüedad en
rango.
La ambigüedad en rango se define según la ecuación 1.4.
Rmu = c
2 · PRF (1.4)
Se mencionó anteriormente que otro de los parámetros que pueden
medirse con un sistema radar es la velocidad de un objetivo,
mediante la detección del corri- miento Doppler de la frecuencia de
la señal retransmitida a la antena. En radares pulsados, la
medición de velocidad también presenta un límite de ambigüedad que,
igual que el rango, está afectado por la PRF. Se puede demostrar
que esta
4 Capítulo 1. Introducción general
ambigüedad está dada por la ecuación 1.5, con λ igual a la longitud
de onda de la señal transmitida.
Vrmu = ±λ · PRF 4
(1.5)
Una vez definidos los parámetros más generales y representativos de
un siste- ma radar pulsado, como son el ancho de pulso (τ ), el
ancho de banda (BW ), la frecuencia de repetición de pulsos (PRF )
y la longitud de onda (λ), se pueden establecer requerimientos
sobre el sistema a implementar en función de los pro- ductos que se
esté buscando obtener.
1.1.2. Señales características
En función de los parámetros y características presentados en la
sección anterior, se detallan a continuación algunas de las señales
que suelen utilizarse en radares y que fueron aplicadas en este
trabajo.
Chirp
Una de las modulaciones más utilizadas es la modulación lineal en
frecuencia, en la que se varía de forma constante la frecuencia
instantánea de la señal. Si se utilizan señales de este tipo,
conocidas como chirps, se logran anchos de banda superiores que su
contraparte sin modulación, y se puede llevar a cabo la com-
presión de pulso descripta en la sección 1.1.1.
En la figura 1.3 se presenta una señal up-chirp. Se denomina de
esta manera ya que la frecuencia de la señal se varía de forma
lineal ascendente durante la duración τ del pulso, desde una
frecuencia inicio a una frecuencia fin.
τ
Frecuencia inicial
Frecuencia final
FIGURA 1.3. Representación de una señal de radar modulada li-
nealmente en frecuencia (chirp).
Códigos Barker
Para el caso de la modulación en fase se utiliza un tipo de señales
que, al igual que la modulación en frecuencia, tienen
características de autocorrelación con un máximo bien definido
respecto a los lóbulos laterales.
1.1. Sistemas RADAR 5
Los códigos Barker [5] son un conjunto de secuencias binarias para
las cuales se ha demostrado que presentan un resultado óptimo de
autocorrelación, con lóbulos laterales entre -6 dB y -22 dB
respecto al máximo de correlación.
El listado de códigos Barker se muestra en la tabla 1.1. En señales
de radiofre- cuencia, como en los sitemas radar, las secuencias
Barker se utilizan para generar pulsos que tengan cambios de fase
de 180 de acuerdo con el código correspon- diente. En la figura 1.4
se observa cómo se aplican los elementos de la secuencia Barker a
una señal senoidal.
TABLA 1.1. Códigos Barker.
Número de bits Código
2 +1 -1 3 +1 +1 -1 4 +1 +1 -1 +1 5 +1 +1 +1 -1 +1 7 +1 +1 +1 -1 -1
+1 -1 11 +1 +1 +1 -1 -1 -1 +1 -1 -1 +1 -1 13 +1 +1 +1 +1 +1 -1 -1
+1 +1 -1 +1 -1 +1
+1 +1 -1 +1 -1+1 -1
FIGURA 1.4. Código Barker número 7 aplicado a una señal senoi-
dal.
1.1.3. Radares ejemplo
En la tabla 1.2 se detallan cuatro sistemas de radar distintos y
con aplicaciones diversas. Observando los parámetros técnicos de
cada uno se puede notar una gran diversidad de sistemas. Además de
los radares mostrados en la tabla, los sistemas radar se aplican en
variedad de entornos. Se pueden encontrar radares en aplicaciones
civiles y militares, para control de tráfico aéreo, previsión
meteo- rológica, detección de movimiento y gestos, vehículos
autónomos, entre muchas otras.
La frecuencia de operación de los radares puede oscilar en un gran
rango entre las centenas de MHz y las decenas de GHz, con anchos de
banda de las seña- les transmitidas de alrededor de 100 kHz a 1
GHz. Respecto a la frecuencia de repetición de pulsos, esta puede
llegar a valores de decenas de kHz.
6 Capítulo 1. Introducción general
TABLA 1.2. Ejemplo de algunos sistemas radar para aplicaciones
diversas.
Radar Características
Objetivo: radar educativo y de entrenamiento Frecuencia: 8
GHz
Ancho de pulso mínimo: 10,5 ns Resolución en rango: 10 cm
Rango máximo: 30 m PRF configurable
Radar para vigilancia aérea [2]
Objetivo: militar ó civil Frecuencia: 12 GHz
PRF: 20 kHz fija Ancho de pulso: 6,5 µs
Compresión de pulso: secuencia Barker de 13 bits Resolución en
rango: 75m
Rango máximo: 30 km Velocidad máxima: ±500 m/s
Humminbird HB2124 [7]
Objetivo: Navegación marítima Frecuencia: 9354 a 9446 MHz
Ancho de pulso: 400 ns a 20 µs Rango máximo: 44 km
Resolución en rango: 6m
Objetivo: Medición de velocidad de vehículos Frecuencia: 2,4
GHz
Resolución de velocidad: 1 km/h Rango de medición: 10 km/h a 200
km/h
Señal sin modulación
El Centro Interdisciplinario de Telecomunicaciones, Electrónica,
Computación y Ciencia Aplicada (CITECCA) de la Universidad Nacional
de Río Negro, Sede An- dina, es un grupo de investigación
interdisciplinario que lleva a cabo actividades en campos como la
astronomía/radioastronomía, ingeniería electrónica, procesa- miento
de señales de RADAR, simulaciones numéricas de incendios, cómputo
de alto rendimiento, entre otras.
En relación con este trabajo, en el centro se trabaja en
procesamiento de señales de radares de apertura sintética (SAR) y
meteorológicos. A través de vínculos con INVAP, CONAE y el
Instituto Balseiro se ha podido acceder a datos reales de apli-
caciones concretas. Sin embargo, era de interés comenzar a trabajar
en desarrollos in-house de la electrónica asociada a los sistemas
de radar. En este sentido, dentro del centro y como proyecto final
integrador de la carrera de ingeniería electóni- ca, una estudiante
finalizó en febrero de 2020 el desarrollo de un radar de onda
continua para medición de velocidad [8].
En ese contexto se propuso comenzar la implementación de un sistema
de radar
1.2. Motivación del desarrollo 7
pulsado multipropósito de relativo corto alcance, que permita
contar con una pla- taforma de hardware propia sobre la cual
validar algoritmos, modelos y demás temas estudiados.
1.2.1. Objetivos y especificaciones
El trabajo se enmarcó en una etapa de estudio de las primeras
implementaciones y desarrollos de hardware propias dentro de la
universidad. El objetivo del pro- yecto apuntó a la creación de un
prototipo de las etapas digitales de transmisión y recepción de las
señales de radar. Es decir, el backend sobre el cual se implemen-
tarán a futuro los correspondientes subsistemas de
radiofrecuencia.
Los requerimientos del trabajo se listan en la tabla 1.3.
8 Capítulo 1. Introducción general
TABLA 1.3. Requerimientos del trabajo.
Req. Descripción
1.0 - Generales
1.1 El sistema debe contener un canal de transmisión para
generación de formas de onda de radar.
1.2 El sistema debe contener un canal de recepción para recibir
señales de radar muestreadas en frecuencia intermedia.
1.3 El ancho de banda del sistema será de 20 MHz. 1.4 Opcional: los
subsistemas de transmisión y recepción deben operar de
forma sincronizada en función de la frecuencia de repetición de
pulsos.
2.0 - Transmisión
2.1 La señal de salida debe tener dos modos de operación
configurables: señal continua (CW) o pulsada.
2.2 La señal de salida debe ser configurable en dos tipos de
modulación: frecuencia y fase.
2.3 Para la señal de salida en modo pulsado (Req. 2.1), deben poder
configurarse la frecuencia de repetición de pulsos (PRF) y el ancho
del
pulso. 2.4 La validación de la señal generada se hará de forma
digital. (Ver Req.
4.1)
3.0 - Recepción
3.1 La recepción de las señales debe realizarse a través de un
demodulador I/Q.
3.2 El demodulador (Req. 3.1) recibirá las muestras de la señal de
entrada, muestreadas en frecuencia intermedia. (Ver Req. 4.2)
3.3 La validación de la señal demodulada se hará de forma digital.
(Ver Req. 4.3)
4.0 - Debug
4.1 Deberán poder descargarse del sistema las formas de onda
generadas digitalmente, para su verificación.
4.2 Deberán poder cargarse al sistema secuencias simuladas de
señales muestreadas en frecuencia intermedia para verificación
del
demodulador IQ. (Req. 3.1) 4.3 Deberán poder descargarse del
sistema las formas de onda
demoduladas, para su verificación.
5.0 - No funcionales 5.1 Es deseable la implementación del sistema
en una FPGA.
9
2.1. Plataforma de desarrollo
Dentro de los requerimientos generales del trabajo se planteó que
era deseable la implementación del sistema en una FPGA. Otro
supuesto del proyecto plan- teaba la implementación en una placa de
desarrollo. Tomando esto como base se analizaron distintas
alternativas para la implementación. Para la elección de la
plataforma se consideraron características de performance respecto
a la capaci- dad de procesamiento y frontend analógico, costo y
familiaridad previa con los sistemas.
Las placas de desarrollo evaluadas se presentan en la tabla 2.1. La
búsqueda se centró en plataformas basadas en Systems on Chip (SoCs)
del fabricante Xilinx [9] ya que se tenía conocimiento previo en la
arquitectura de estos sistemas. Por otro lado, se puede tener
acceso de forma gratuita a los entornos de desarrollo Vitis Vivado
y utilizar el toolchain completo tanto para diseño de la lógica
programable como de el software embebido.
La elección final de la plataforma resultó en una combinación de la
Arty Z7-10 y la Red Pitaya StemLab 125-10. Ambas placas integran el
mismo sistema de proce- samiento (SoC Zynq-7010 [14]) y representan
la opción de menor costo. La ventaja de la Red Pitaya por sobre la
Arty Z7 radica en que contiene en la misma placa los conversores
digital-analógico y analógico-digital que posibilitan la validación
de forma “analógica” de las señales generadas y demoduladas. Este
último pun- to no era un requerimiento de este trabajo, pero se
consideró como una ventaja para desarrollos a futuro. La Red
Pitaya, además, ha tenido una gran aceptación de usuarios que
desarroyan proyectos en el área de RF y radios definidas por
software (SDRs)
Ambas placas poseen intergrado el transceiver para el controlador
Ethernet que contiene el SoC, por lo que compartían también la
misma interfaz de comunica- ción para control y descarga de datos.
Se tomó entonces la decisión de realizar el trabajo en la placa
Arty Z7-10 y restringir algunos de los parámetros de diseño a las
características del frontend analógico de la Red Pitaya.
Arquitectura Zynq-7000
Los dispositivos Zynq son un System on Chip que integra lógica
programable (FPGA) y procesadores ARM en el mismo chip. La figura
2.1 muestra la arqui- tectura interna de la línea Zynq-7000, que es
la que incluye la placa Arty Z7-10.
10 Capítulo 2. Introducción específica
TABLA 2.1. Plataformas de desarrollo evaluadas.
Placa Costo Performance Familiaridad Ventajas
Ary Z7-10 [10]
desarrollo utilizada en la CESE.
Red Pitaya [11]
$$ ++ - Integra un DAC y un ADC, ambos de dos
canales hasta 50 MHz con una frecuencia de muestreo de 125
MHz.
ADALM- PLUTO
entre 325 MHz y 3.8 GHz con un ancho de
banda de 20 MHz.
radiofrecuencia mediante el conector
FMC.
Se pueden ver los dos subsistemas que la integran: Processing
System (PS) y Pro- grammable Logic (PL), además de los buses de
interconexión entre ambos. La ventaja de estos sistemas radica en
la posibilidad de implementar “aceleradores” o diseños
configurables en lógica programable a un sistema embebido “conven-
cional” basado en un microprocesador.
En este trabajo se utiliza este paradigma para implementar hardware
específico de procesamiento de señales en la FPGA, mientras que se
realizan las tareas de control, configuración y comunicación
utilizando el microprocesador del sistema de procesamiento.
2.2. Buses y camino de datos 11
FIGURA 2.1. Arquitectura interna del SoC Zynq-7000. Imagen to- mada
de la página oficial del fabricante1.
2.2. Buses y camino de datos
AXI (Advanced eXtensible Interface) es un protocolo de comunicación
para buses en sistemas embebidos y microcontroladores que es parte
de las especificaciones de ARM AMBA [15]. La cuarta versión del
protocolo, AXI4, define tres tipos de interfaces de buses:
AXI4: para requerimientos de lectura y escritura a direcciones de
memoria de alta performance.
AXI4-Lite: para comunicación mapeada a memoria de baja tasa de
datos. Por ejemplo, lectura y escritura de registros de control y
estado.
AXI4-Stream: para transmisiones de alta velocidad de un flujo de
datos no mapeado a direcciones de memoria.
1Imagen tomada de
https://www.xilinx.com/content/dam/xilinx/imgs/block-diagrams/
zynq-mp-core-dual.png
12 Capítulo 2. Introducción específica
En la figura 2.1 se puede observar cómo la interconexión entre los
subsistemas de procesamiento y lógica programable en la
arquitectura Zynq se realiza por me- dio de un conjunto diverso de
interfaces que cumplen con el protocolo AXI. Para poder comunicar
bloques de procesamiento implementados en la sección de la FPGA del
chip con los procesadores ARM, es necesario que los subsistemas
desa- rrollados sean compatibles con dicha interfaz. En la figura
2.2 se presenta una arquitectura genérica de procesamiento en
lógica programable, que tiene interfa- ces AXI para la comunicación
con el sistema de procesamiento.
Procesamiento AXI-Stream
Configuración (AXI-Lite)
Procesamiento AXI-Stream
Procesamiento AXI-StreamAXI
(AXI)
FIGURA 2.2. Diagrama ejemplo de un sistema de procesamiento en FPGA
con interconexiones AXI, AXI-Lite y AXI-Stream.
Un conjunto de bloques de hardware que llevan a cabo tareas, por
ejemplo, den- tro de un pipeline de procesamiento de señales se
interconectan por medio de un bus AXI-Stream. Este bus permite un
flujo de datos lineal entre los bloques, los cuales no precisan
enviarlos a direcciones de memoria específicas, sino que pro- cesan
los datos de entrada y los vuelcan a la salida. Cada uno de estos
bloques puede llegar a necesitar de una configuración específica,
por lo que se implemen- ta una comunicación vía AXI-Lite para tener
registros de configuración mapeados al espacio de memoria del
procesador. De esta manera, el software puede acceder a direcciones
de memoria específicas para realizar modificaciones en los subsis-
temas dentro de la lógica programable.
Por último, puede ser necesario transferir grandes cantidades de
datos entre la FPGA y el procesador, desde cada bloque de la cadena
de procesamiento hasta la memoria RAM del sistema. Este paso se
puede realizar mediante la conversión de una interfaz AXI a otra,
por ejemplo de AXI-Stream a AXI.
El fabricante del SoC que trae la placa de desarrollo elegida,
Xilinx, provee, dentro de las herramientas de desarrollo, bloques
de lógica programable llamados IP Cores [16], que pueden
instanciarse y configurarse de acuerdo con la aplicación. Muchos de
estos bloques poseen interfaces que cumplen con los protocolos AXI,
y uno de ellos permite la escritura a memoria RAM desde una
interfaz AXI-Stream, proveyendo acceso directo a memoria. Este
bloque se denomina AXI DMA (AXI Direct Memory Access) [17] y fue
utilizado en el desarrollo de este trabajo. En la figura 2.2 se
ejemplifica su uso, como parte final de la cadena de
procesamiento.
2.3. Síntesis digital de señales 13
2.3. Síntesis digital de señales
La síntesis o generación de señales digital se conoce como Direct
Digital Synthesis y se implementa a través de un Direct Digital
Synthesizer (DDS). Es una técnica pa- ra derivar una señal de una
determinada frecuencia a partir de un circuito digital que trabaja
a una única referencia de reloj [18] [19]. Se muestra en la figura
2.3 un diagrama en bloques representativo de un DDS, que en su
esquema básico se compone de un acumulador o integrador de fase y
un bloque que mapea la fase acumulada a la amplitud de la
señal.
El mapeo entre la fase acumulada y la amplitud corresponde a la
transformación no lineal Θ(n) ⇒ sen(Θ(n)), con Θ(n) la n-ésima
muestra de la fase acumulada, y se implementa generalmente mediante
una tabla de valores en memoria, o Look Up Table (LUT).
Acumulador de fase
sen(Θ(n))Θ(n) Look Up Table
FIGURA 2.3. Arquitectura genérica de un DDS.
Xilinx provee dentro de su catálogo de IP Cores un bloque para la
síntesis digi- tal de señales (DDS Compiler) [20], que fue
utilizado en este proyecto. Este core posee diversas
configuraciones como ser múltiples canales, parámetros de cuan-
tización, capacidad de generar señales en cuadratura, optimización
de ruido y rango dinámico, etcétera.
Una de las principales configuraciones radica en la posibilidad de
modificar di- námicamente la frecuencia de la señal senoidal a su
salida, según se muestra en la ecuación 2.1. Como se mencionó
anteriormente, el mapeo entre la fase y las muestras de la señal
precargadas en memoria permite que se genere una señal cuya
frecuencia es función del incremento de fase del acumulador. En
otras pa- labras, la frecuencia depende de la “velocidad” a la que
se recorre la tabla de valores de la salida.
fout = PINC · fclk
2BΘ(n) (2.1)
A partir de esto, puede obtenerse qué valor de incremento de fase
(PINC) se debe ingresar al DDS para configurar una determinada
frecuencia de salida fout, con una frecuencia de reloj (fclk) fija,
y un acumulador de fase cuantizado a una cantidad de bits igual a
BΘ(n).
PINC = fout · 2BΘ(n)
2.4. Demodulación I/Q
La gran mayoría de los sistemas de radar emplean receptores
superheterodinos para la recepción de los ecos de las señales
transmitidas [2]. En este tipo de re- ceptores las señales de
radiofrecuencia (RF) se mezclan con un oscilador local, en una o
más etapas, hasta una frecuencia intermedia (FI) previa a la
demodulación a banda base.
Por otro lado, la naturaleza del problema de los sistemas radar y
el procesamiento necesario para detectar algunas de las variables
requiere de receptores coherentes que preserven la fase de las
señales. Por medio de la demodulación I/Q o demo- dulación en
cuadratura, se puede recuperar tanto la envolvente como la fase de
una señal.
Se muestra en la figura 2.4 el esquema de un demodulador I/Q en el
contexto de un sistema superheterodino sobre el cual se muestreó la
señal analógica luego de la traslación a frecuencia intermedia.
Este demodulador lleva a cabo la conversión a banda base de la
señal entrante de forma digital y se conoce como Digital Down
Converter (DDC) [21].
ADC
Señal en fase (I)
Señal en cuadratura (Q)
FIGURA 2.4. Demodulador I/Q.
La primera etapa de la demodulación consiste en “trasladar en
frecuencia” la señal entrante desde la frecuencia intermedia hasta
banda base. Esto se realiza mediante la multiplicación de la
entrada con una réplica de la frecuencia inter- media generada
mediante un oscilador local. Para obtener las componentes en fase y
en cuadratura, este paso se realiza con dos señales senoidales
desfasadas 90. La figura 2.5 a) muestra el espectro en frecuencia
de la señal de entrada, que se muestreó a una frecuencia fs. El
resultado de la multiplicación por el oscilador local se observa en
la figura 2.5 b). Se ve cómo el espectro de la señal resulta asi-
métrico respecto al eje de cero Hertz, ya que se representan las
señales I y Q como un número complejo.
Una vez en banda base la representación de las señales demoduladas
no requerirá de una frecuencia de muestreo mucho más elevada que su
máxima componente de frecuencia, por lo que los sistemas de radio y
comunicaciones suelen decimar los valores muestreados. En este
proceso se descartan muestras de la señal ad- quirida, con lo que
se reduce su tasa de muestreo efectiva. Además de decimar la
2.4. Demodulación I/Q 15
f [Hz]
f [Hz]
f [Hz]
FIGURA 2.5. Espectro de las etapas de demodulación. a) Señal de
entrada muestreada a una frecuencia fs, b) señal a la salida de
los
mezcladores y c) señal resultante en banda base y filtrada.
señal, es necesario filtrar las componentes de frecuencia imagen
que se observan en la figura 2.5, por lo que se aplica un filtrado
pasa bajos que conserva única- mente las señales en banda base
(figura 2.5 c).
La etapa de decimación se muestra esquemáticamente en el diagrama
de la figura 2.4 luego de cada instancia de los mezcladores de
señal.
2.4.1. Decimación y filtrado
Una de las estrategias para decimación y filtrado en receptores
digitales de ra- diofrecuencia es la de utilizar filtros CIC
(Cascaded Integrator-Comb) [22]. Este tipo de filtros realizan
decimación y filtrado pasa bajos con una estructura que no requiere
de elementos de memoria o multiplicaciones, lo cual es eficiente
para su implementación en hardware. El filtro se compone de un
número de filtros inte- gradores en cascada, una etapa de
decimación que descarta una cada R muestras y por último una
cascada de filtros comb (peine). Los parámetros del filtro que
modifican su respuesta en frecuencia son la cantidad de etapas N ,
el retraso de cada etapa M y la tasa de decimación R.
La desventaja de los filtros CIC es que no poseen una respuesta en
frecuencia plana en la banda de paso y produce distorsiones en la
señal de salida. Para com- pensar este efecto, se implementa una
cascada de filtros uniendo el filtro CIC con un segundo filtro de
compensación que mejore la respuesta de la banda pasante [23]
[24].
La figura 2.6 resume la estructura de filtros basada en el filtro
CIC.
16 Capítulo 2. Introducción específica
Filtro Compensador
Z -1
Z -1
Z -M
Z -M
Retardo
2.5. Protocol Buffers
La placa de desarrollo elegida cuenta con una interfaz Ethernet que
se utilizó para el control de la plataforma y la descarga de datos
de las señales generadas. Al enviar sobre Ethernet tramas de bytes
que era necesario decodificar en origen y destino, se buscó un
mecanismo para serializar la información correspondiente a comandos
de configuración, señales de estado y datos descargados, y poder
reconstruirla en el otro extremo de la comunicación.
La librería Protocol Buffers [25] de Google provee un mecanismo
para definir mensajes de forma estructurada mediante una interfaz
de descripción particular. Los mensajes pueden incluir tipos de
datos específicos, mensajes repetidos para generar colecciones de
datos, valores enumerados, o ser mensajes abstractos que contienen
alguno de muchos tipos previamente definidos. Una vez estructura-
dos los mensajes, el compilador protoc genera el código fuente
correspondiente al lenguaje de programación elegido.
La implementación de Protocol Buffers, o protobufs, de Google
genera código pa- ra C++, Python, Java, entre otros lenguajes. A su
vez, hay implementaciones de terceros para otros lenguajes. Una de
estas implementaciones es Nanopb [26], que genera en lenguaje C los
mecanismos de serialización y de-serialización de estructuras
definidas con Protocol Buffers, y está orientado a la utilización
en mi- crocontroladores.
17
Diseño e implementación
En este capítulo se detalla el diseño e implementación del sistema.
Se presentan las arquitecturas y consideraciones de diseño de los
módulos implementados en lógica programable, así como del software
desarrollado.
En el repositorio [27] del proyecto se puede consultar el código
desarrollado.
3.1. Arquitectura del sistema
El sistema implementado está dividido en un subsistema de lógica
programable y en otro de software embebido. Esto va en línea con la
arquitectura Zynq descripta en la sección 2.1. A su vez, cada uno
de estos subsistemas puede dividirse en módulos funcionales.
La figura 3.1 muestra de forma esquemática la arquitectura del
sistema. Se im- plementaron en lógica programable los módulos
generador y demodulador en- cargados de generar y/o procesar las
señales de acuerdo con los requerimientos, mientras que en el
sistema de procesamiento ARM se desarrollaron los subsiste- mas de
control y comunicaciones hacia el exterior.
Ethernet
n A
FIGURA 3.1. Arquitectura del sistema implementado.
Las interfaces del nivel superior del sistema (entradas y salidas
de datos y confi- guración) están relacionadas con la plataforma de
desarrollo que se utilizó (Arty
18 Capítulo 3. Diseño e implementación
Z7-10) y, tal como se menciona en la sección 2.1, con la elección
de la placa Red Pitaya para una futura implementación de un radar
pulsado completo. La tabla 3.1 resume los parámetros de diseño
elegidos.
Por el lado de las comunicaciones se decidió utilizar una interfaz
UART para impresión de mensajes de información y depuración,
mientras que se utilizó una comunicación Ethernet para la descarga
de datos e intercambio de señales de control al sistema. Se
aprovechó en este caso la conexión que ya brinda la placa de
desarrollo elegida, con un controlador de 1 Gb Ethernet.
TABLA 3.1. Parámetros de las interfaces a nivel sistema.
Parámetro Configuración Justificación
Frecuencia de reloj de la FPGA
125 MHz Misma frecuencia de operación que el ADC y DAC de la Red
Pitaya
Ancho del bus de datos a
generar y recibir
14 bits Ancho del bus de datos del ADC y DAC de la Red Pitaya
Conexión para comandos y descarga de
datos
Gigabit Ethernet Misma característica tanto en la Red Pitaya como
en la
Arty Z7-10
De los parámetros característicos de un sistema radar que se
presentaron en la sección 1.1.1, el único parámetro definido como
requerimiento del trabajo refe- ría al ancho de banda de 20 MHz. Se
definió el resto de los parámetros según se muestran en la tabla
3.2. Las consideraciones para seleccionar estos parámetros tuvieron
en cuenta las capacidades de la plataforma de desarrollo, el uso de
fre- cuencias de la etapa de RF en bandas no licenciadas (ISM
[28]), y una aplicación final ejemplo como la medición de distancia
y velocidad de vehículos.
TABLA 3.2. Parámetros de radar elegidos.
Parámetro Valor Características del radar
Ancho de banda
20 MHz Resolución en rango con señal modulada: 7,5 m
PRF 4 a 250 kHz Máximo rango sin ambigüedad: 37,5 km a 600 m
Máxima velocidad sin ambigüedad: 450 a 22500 km/h 1
Ancho de pulso
Mínimo 5 µs Resolución en rango sin modulación: 750 m
1Valores calculados para una frecuencia de operación de 2,4
GHz.
3.2. Lógica programable 19
3.2. Lógica programable
Los módulos implementados en la FPGA se desarrollaron en
Verilog/SystemVe- rilog, y se utilizaron diversas instancias de IP
Cores provistos por Xilinx, que se integraron a los bloques de
desarrollo propio mediante diagramas en bloques de la herramienta
Vivado. Las secciones a continuación describen la implementación y
criterios de diseño de los módulos desarrollados.
3.2.1. Banco de registros AXI-Lite
Se implementó en lógica programable un módulo de banco de registros
con inter- faz AXI-Lite para acceder desde el procesador ARM a
datos y configuraciones de los módulos generador y demodulador. El
banco de registros permite la lectura y escritura a direcciones de
memoria específicas que se configuraron para cada banco de
registros instanciado.
Las líneas de entrada y salida correspondientes al bus cumplen con
el protocolo AXI4 en su versión Lite [15]. Se muestra de forma
esquemática en la figura 3.2 el bloque implementado.
Registros config_reg_0
Write data signals
Write response signals
Read address signals
Read data signals
FIGURA 3.2. Esquema de entradas y salidas del banco de registros
implementado.
Se codificaron las máquinas de estado que se muestran en la figura
3.3, que imple- mentan la escritura y lectura a los registros por
medio del protocolo de escritura y lectura al bus.
La escritura y lectura a los registros a través del bus AXI4-Lite
se verificaron por simulación del módulo mediante un testbench
específico.
20 Capítulo 3. Diseño e implementación
WIDLE_S awvalid == 0
rvalid=1
arvalid ==1
rready == 0
rready ==1
a) b)
FIGURA 3.3. Máquinas de estado del protocolo AXI4-Lite, imple-
mentadas para a) escritura y b) lectura.
3.2.2. Generador
El módulo generador se implementó en base al IP Core DDS Compiler
[20] para la síntesis digital de señales. Se creó una instancia del
banco de registros mostra- do en la sección 3.2.1 y desarrollaron
bloques en lógica programable que toman los parámetros de
configuración de los registros. En función de estos parámetros se
controla la entrada de configuración PHASE del DDS Compiler. Esta
forma de operación del IP Core permite la generación de ondas con
modulaciones de fre- cuencia y fase dinámicas, y es la sugerida por
Xilinx [20]. Los datos de salida son leídos también por una
instancia del IP Core AXI DMA, que se presentó en la sec- ción 2.2
y se utilizó para la transferencia de datos al sistema de
procesamiento en el modo de debug de las señales generadas.
La arquitectura del generador se muestra en la figura 3.4.
El canal de configuración del DDS Compiler posee los campos de
control que se muestran en la tabla 3.3. Se diseñó el generador
para la operación en seis modos de funcionamiento dependiendo de
las señales a generar, y en función de estos el modulador genera
los estímulos correspondientes en los campos PINC, POFF y
RESYNC.
3.2. Lógica programable 21
FIGURA 3.4. Arquitectura general del módulo generador.
TABLA 3.3. Campos de configuración del DDS Compiler presentes en el
canal de configuración PHASE del core.
Campo Bits Función
PINC 29 a 0 Configura el incremento de fase del sintetizador de
señales y establece la frecuencia de la señal de salida.
Usado para generar la modulación en frecuencia.
POFF 61 a 32 Configura la suma de una fase constante al
sintetizador de señales. Usado para generar la
modulación en fase.
RESYNC 64 Restablece la fase del acumulador del sintetizador de
señales a un valor ingresado por el campo PINC.
Utilizado para restablecer las señales en la generación de
pulsos.
Modos de operación
La tabla 3.4 resume los seis modos de operación del generador,
junto con los estí- mulos que se aplicaron al DDS Compiler para
generar cada una de las formas de onda deseadas. En las
subsecciones siguientes se detallan en profundidad cada uno de
estos estímulos.
Los distintos modos de operación se decodifican en el módulo
dds_modulator (re- presentado esquemáticamente en la figura 3.5),
dentro del cual se generan los estímulos sobre PINC, POFF y
RESYNC.
22 Capítulo 3. Diseño e implementación
TABLA 3.4. Modos de operación y acciones sobre los canales de
configuración del DDS.
Tipo de modulación
POFF: Cero POFF: Cero RESYNC: Cero RESYNC: Luego de cada
pulso
POFF: Cero POFF: Cero RESYNC: Cero RESYNC: Luego de cada
pulso
POFF: 0 ó 180 en función de la secuencia Barker
POFF: 0 ó 180 en función de la secuencia Barker
RESYNC: Luego de cada subpulso
RESYNC: Luego de cada subpulso y al final de la
secuencia
pulse_counter
Modulador
PINC
modulation_counter
POFF
3.2. Lógica programable 23
Mapa de memoria
La instancia del banco de registros del generador se diseñó con el
mapa de memo- ria que se muestra en la tabla 3.5. A través del
acceso a estos registros mediante el bus AXI-Lite, se puede
configurar la operación del generador desde el sistema de
procesamiento ya que una vez generado el sistema completo queda
mapeada esta sección dentro del espacio de memoria del
procesador.
Además de los seis modos mencionados anteriormente, existe un modo
de depu- ración (debug) que puede habilitarse a través de los
registros de configuración. Si se habilita este modo, es posible
descargar desde el procesador ARM una trama de las muestras
generadas.
24 Capítulo 3. Diseño e implementación
TABLA 3.5. Mapa de memoria del módulo generador.
Reg. Dir. Campos
Bits Nombre Función
1 DBG 0 = Debug deshabilitado
1 = Debug habilitado
1 MOD 0 = Modulación deshabilitada
1 = Modulación habilitada
1 = Modulación en frecuencia
2 0x08 14 a 0 period En modo pulsado, período del
pulso, en unidades del ciclo del reloj
30 a 16 tau En modo pulsado, ancho del pulso, en unidades del ciclo
del reloj
3 0x0c 29 a 0 pinc En modo continuo o modulado en
fase, incremento de fase (constante) para el DDS
29 a 0 pinc_low En modo modulado en frecuencia, equivale al
incremento de fase
inicial del DDS
4 0x10 29 a 0 pinc_high En modo modulado en frecuencia,
equivale al incremento de fase final del DDS
29 a 0 barker_subpulse En modo modulado en fase, Ancho de cada
subpulso, en unidades del
ciclo del reloj
5 0x14 29 a 0 delta_pinc En modo modulado en frecuencia,
equivale a la pendiente de cambio de la fase del DDS
12 a 0 barker_sequence En modo modulado en fase, Código binario
correspondiente al
código Barker
31 a 28 barker_seq_num En modo modulado en fase, Número de código
Barker
3.2. Lógica programable 25
Modo continuo o pulsado
La generación de pulsos es comandada mediante un acumulador que se
imple- mentó para el conteo del período y ancho de pulso de la
señal deseada. La forma de operación se muestra en la figura 3.6.
La señal pulse_timeout se genera inter- namente como salida del
contador, y se utiliza para controlar la generación o no de
señales. Una vez finalizado el tiempo correspondiente al ancho de
pulso, se mantiene detenido el incremento de fase del DDS Compiler
mientras se retiene en alto el canal de configuración RESYNC.
pulse_counter
tiempo
tau
pulse_timeout_n
FIGURA 3.6. Lógica de funcionamiento del contador para genera- ción
de pulsos.
Modulación en frecuencia
Como se introdujo en la sección 2.3, el DDS Compiler genera a su
salida una señal cuya frecuencia instantánea es función del
incremento de fase PINC que recibe a través del canal de
configuración. Se implementó la modulación en frecuencia mediante
un contador que se incrementa a una tasa dada por la rampa de fre-
cuencia que se desee generar. La figura 3.7 contiene un esquema de
la lógica de operación.
A través de los parámetros de configuración pinc_low, pinc_high y
delta_pinc el contador implementado genera una rampa sobre el canal
PINC del IP Core, que se traduce en una señal que incrementa su
frecuencia desde un valor mínimo a un valor máximo.
Se tomó la ecuación 2.2 que describe el comportamiento del DDS
Compiler para representar los parámetros que configuran la rampa de
frecuencia en función de las frecuencias de inicio y fin, y la
duración de la modulación. En las ecuaciones 3.2 y 3.1 se muestra
cómo obtener los parámetros pinc_low, pinc_high y delta_pinc que
deben escribirse al banco de registros para configurar la
modulación en fre- cuencia.
PINC(low,high) = fout(min,max) · 2BΘ(n)
delta_PINC = 2BΘ(n)
Donde:
BΘ(n) = Ancho en bits del acumulador de fase interno del DDS (30
bits). fclk = Frecuencia de reloj de la FPGA (125 MHz).
fout(min,max) = Frecuencias de salida deseadas, mínima y máxima.
pulse_length = Duración de la modulación.
tiempo
pulse_length
FIGURA 3.7. Lógica de funcionamiento del contador para modu- lación
en frecuencia.
Modulación en fase
Se implementó la modulación en fase a través del canal de
configuración POFF del DDS Compiler. Esto permitió aplicar cambios
de fase constantes a la senoidal de salida del DDS en función de la
secuencia Barker que se desea generar. Se dividió cada secuencia
Barker (sección 1.1.2) en “subpulsos” para cada bit de la
secuencia, tal como se muestra en la figura 3.8. En este caso los
valores “+1” y “-1” de los códigos están representados con los
valores cero y uno. Dependiendo del valor del bit durante cada uno
de los subpulsos se aplica sobre el canal POFF, mediante un
multiplexor, un corrimiento en fase correspondiente a un valor de
180.
Se reutilizó el contador implementado para la modulación en
frecuencia (modula- tion_counter), para llevar la cuenta del ancho
de cada uno de los subpulsos. A su vez, se implementó el contador
barker_subpulse_counter para indexar la secuencia que se quiere
generar y extraer el cambio de fase a partir del valor de cada bit.
Este contador se incrementa cada vez que modulation_counter termina
de contar la duración de cada subpulso. Puede observarse el
funcionamiento en la figura 3.9.
3.2. Lógica programable 27
0 1 1 1 10 0
FIGURA 3.8. Secuencia Barker número siete y definición de “sub-
pulso”.
barker_subpulse_counter "3"
1 1 1 0 0 0 1 0 0 1 0 10 9 8 7 6 5 4 3 2 1 0
"0"
180°
barker_subpulse_counter "4"
1 1 1 0 0 0 1 0 0 1 0
"1"
0°
10 9 8 7 6 5 4 3 2 1 0
modulation_counter_expired
FIGURA 3.9. Selección de cambio de fase en función de la secuen-
cia Barker.
Los parámetros de configuración de la modulación en fase que se
observan en el mapa de memoria ya presentado en la tabla 3.5 son
los siguientes:
pinc, para configurar la frecuencia de la señal de salida según la
ecuación 2.2.
barker_subpulse, para configurar la duración de cada subpulso, en
cantidad de ciclos de reloj.
barker_seq_num, número de la secuencia Barker cargada.
barker_sequence, secuencia de bits correspondiente al código Barker
a gene- rar.
28 Capítulo 3. Diseño e implementación
3.2.3. Demodulador
El módulo demodulador se implementó en base al diseño expuesto en
la sección 2.4. La cadena de procesamiento se compone de tres IP
cores que realizan las fun- ciones del mixer y posterior filtrado.
Estos son: Complex Multiplier, CIC Compiler y FIR Compiler.
Se diseñó el demodulador previendo algunos escenarios concretos.
Estos escena- rios no se plantearon inicialmente como
requerimiento, sin embargo se estable- cieron durante el diseño de
este prototipo de forma de acotar el problema a un número de
configuraciones posibles. En la figura 3.10 se muestran dos
ejemplos de la posible composición en frecuencia de las señales a
demodular. Se restrin- gió la operación a cuatro valores de
oscilador local para el mixer. Esto asume que se pueden demodular
correctamente señales digitalizadas cuya frecuencia inter- media
del frontend de RF sea de alguno de estos cuatro valores. Por otro
lado, se definieron seis escenarios posibles respecto al ancho de
banda de las señales a demodular, y en función del ancho de banda
es que se eligieron las posibles configuraciones de tasas de
decimación.
10 20 30 40 50 f [MHz]
M a g n it
u d
M a g n it
u d
a)
b)
FIGURA 3.10. Espectros de posibles señales a demodular, con fre-
cuencias intermedias en una de las configuraciones de oscilador
local para a) 20 MHz de ancho de banda y b) 10 MHz de ancho
de
banda.
En la tabla 3.6 se incluye un resumen de todas las configuraciones
posibles, junto con la tasa de muestreo resultante que se obtiene
luego de la demodulación. Un punto importante a observar respecto a
la tasa de datos de salida es que al tratarse de señales complejas
con sus componentes I y Q, se satisface el criterio de Nyquist para
reconstrucción de la señales muestreadas, con una frecuencia de
muestreo superior a la máxima componente de frecuencia de la señal
a muestrear. Para el caso de una señal que no sea compleja, el
requisito sería de una frecuencia de muestreo del doble de la
máxima frecuencia presente en la señal.
Los parámetros de configuración del demodulador son la frecuencia
del oscilador local y la tasa de decimación.
3.2. Lógica programable 29
Oscilador local [MHz]
Ancho de banda
Factor de decima-
1
125
10 8 15.63 15 5 25 20 4 32.25
La arquitectura interna del demodulador se muestra en la figura
3.11. Se com- pone de una cascada de bloques de procesamiento
conectados entre sí a través de un bus AXI-Stream. Los bloques
realizan las etapas de multiplicación con un oscilador local,
decimación y posterior filtrado. Por último, por acceso directo a
memoria se copia una cantidad de muestras a la memoria DDR de la
plataforma de desarrollo.
Demodulador
Configuración
Mapa de memoria
La configuración del demodulador se realiza a través de una
instancia del banco de registros implementado (sección 3.2.1).
Puede verse el mapa de memoria de los registros de configuración en
la figura 3.7. Además de las configuraciones que
30 Capítulo 3. Diseño e implementación
modifican el comportamiento de la demodulación, es posible
configurar la canti- dad de muestras de la señal demodulada que se
pretende transferir al sistema de procesamiento desde la
FPGA.
TABLA 3.7. Mapa de memoria del módulo demodulador.
Reg. Dir. Campos
Bits Nombre Función
1 = Demodulador habilitado
DMA deshabilitada
2 SRC 0 = Origen de los datos: externo 1 = Origen de los datos:
interno
1 0x04 29 a 0 if_pinc Incremento de fase (constante) para
generación del oscilador local mediante el IP Core DDS
Modulator
2 0x08 7 a 0 decimation_rate Factor de decimación de las señales
demoduladas
3 0x10 31 a 0 num_samples Cantidad de muestras a transferir desde
la FPGA a la memoria DDR
Mixer
La generación de la señal del oscilador local para el demodulador
se realizó utili- zando nuevamente una instancia del IP Core DDS
Compiler [20]. La frecuencia de la señal generada es configurada
mediante los registros de configuración ingre- sando el incremento
de fase que corresponda según la ecuación 3.2. La demodu- lación
I/Q requiere dos señales senoidales, tal como se explica en la
sección 2.4, por lo que se configuró el DDS Compiler de forma de
generar una señal coseno y una señal seno invertido para tener el
desfasaje correcto (−π/2).
En la multiplicación de señales necesaria para “bajar en
frecuencia” el espectro a demodular se utilizó el IP Core Complex
Multiplier [29]. Se configuró para operar con señales de un ancho
de 14 bits y de esta manera mantener compatibilidad con los datos
de las señales a adquirir por la placa de desarrollo Red Pitaya
3.1.
El core opera sobre dos buses AXI-Stream de entrada que contienen
una señal compleja y genera a la salida la multiplicación de las
entradas nuevamente en un bus AXI-Stream. La operación realizada se
describe en la ecuación 3.3, en la que se obtiene a la salida la
señal p como resultado de la multiplicación de las señales a y
b.
a = ar + jai
b = br + jbi
p = a · b = pr + jbi = (ar · br − ai · bi) + j · (ar · bi + ai ·
br) (3.3)
En este caso, una de las señales de entrada (a) contiene únicamente
la compo- nente real, que corresponde a las muestras de la señal de
RF a demodular (x[n]), muestreada en frecuencia intermedia,
mientras que en la otra componente se in- gresan las señales
senoidales generadas como oscilador local mediante el DDS Compiler.
Como resultado de la multiplicación (ecuación 3.4) se obtienen a la
sali- da del multiplicador las señales I y Q presentadas en la
sección 2.4. La figura 3.12 muestra la composición de los buses de
entrada y salida del multiplicador.
a[n] = x[n]
b[n] = cos[ωn]− j · sen[ωn]
p[n] = a[n] · b[n] = x[n]cos[ωn]− j · x[n]sen[ωn] (3.4)
x[n] cos[ωn]
a)
b)
c)
FIGURA 3.12. Campos de datos de los buses AXI-Stream del mul-
tipicador. a) Señal real de entrada, b) componentes del
oscilador
local, c) señales I y Q de salida.
Decimación y filtrado
La etapa de decimación se realizó con dos instancias del IP Core
CIC Compiler, una para el canal I y otra para el canal Q. Se
estudió la respuesta del filtro para los distintos escenarios de
ancho de banda mostrados en la sección 3.2.3 y en la tabla 3.6. De
los parámetros de configuración del filtro CIC (sección 2.4.1),
como son M (retraso de cada etapa integradora), N (cantidad de
etapas) y R (factor de decimación), se tenía inicialmente fijo el
valor de R, que ya había sido definido en función de los escenarios
de señales a demodular (tabla 3.6). Se fijó a uno el valor del
parámetro M, que usualmente se limita a los valores uno o dos [30]
y se iteraron distintos valores de N para evaluar la respuesta.
Finalmente se configuró el filtro con N = 3.
32 Capítulo 3. Diseño e implementación
La tabla 3.8 muestra la respuesta en frecuencia con los parámetros
configurados para el ancho de banda de cada escenario. Se puede
notar una atenuación de entre tres y cuatro decibeles en la
frecuencia de la banda pasante, que en banda base corresponde
aproximadamente a la mitad del ancho de banda. La última etapa de
filtrado, como se mostró en la sección 2.4.1 se implementó con el
IP Core FIR Complier provisto por Xilinx, el cual se diseñó y
configuró para compensar la caída en la banda pasante del filtro
CIC.
TABLA 3.8. Atenuación para cada escenario de ancho de banda
esperado. Filtro CIC configurado con M = 1 y N = 3.
Ancho de banda (BW)
Frecuencia superior de la banda pasante del filtro FIR [MHz]
1 70 -3,45 0,89 2 40 -4,54 1,56 5 16 -4,53 3,91 10 8 -4,48 7,81 15
5 -3,82 12,50 20 4 -4,27 15,63
El FIR Complier permite la configuración de uno o más canales por
instancia del core, por lo que se configuró para utilizar dos
canales, que toman las salidas I y Q previamente decimadas por el
filtro CIC. La respuesta del filtro es la inversa de la respuesta
del filtro CIC, para compensar la caída que se ve en la tabla 3.8.
Se tomó como frecuencia de corte un valor igual a la mitad de la
tasa de muestreo de salida (fcorte = 0,5fs
R ) y se calcularon los coeficientes del filtro FIR tomando las
recomendaciones vistas en [30].
La tabla 3.8 muestra también en la última columna la frecuencia
superior de la banda pasante para cada factor de decimación.
En la figura 3.13 se muestra un ejemplo de la respuesta de la
cascada de deci- mación y filtrado implementadas. Se observa la
respuesta por separado de cada filtro, CIC y FIR, y la respuesta
del conjunto para un factor de decimación de setenta.
3.2.4. Empaquetamiento de datos
El IP Core AXI DMA requiere el ingreso de la señal tlast presente
en el bus AXI- Stream para detectar el fin de una trama de datos
que se transmite a través del bus. Para el caso del módulo
generador, se estableció una cantidad fija de mues- tras a
transferir desde la FPGA a la memoria DDR de la placa y se
implementó un contador que genera un pulso de la señal tlast una
vez transferidas todas las muestras. Para el caso del demodulador,
la cantidad de muestras a transferir se puede definir a través de
los registros de configuración y se generó en este caso un bloque
en lógica programable que “empaqueta” una transferencia de datos
según la cantidad de muestras a transferir. Este bloque se observa
en la figura 3.11 y genera, nuevamente a través de un contador, un
pulso de la señal tlast del bus, para indicar el final de la
transferencia al core AXI DMA.
3.3. Software 33
-50
-45
-40
-35
-30
-25
-20
-15
-10
-5
0
u d [
d B
Cascada
FIGURA 3.13. Respuesta de las etapas de decimación y filtrado para
R = 70.
3.3. Software
El objetivo del software es el control de los módulos implementados
en lógica programable y la transmisión de los datos generados y
demodulados hacia una PC, para realizar la validación. El diseño se
dividió en capas, según se muestra en la figura 3.14.
Se implementó el desarrollo utilizando la herramienta Vitis, de
Xilinx. Se desa- rrollaron drivers de bajo nivel para la lógica
programable y una aplicación en FreeRTOS con subaplicaciones para
control de los módulos generador y demo- dulador,
respectivamente.
La elección de FreeRTOS se basó en la familiaridad adquirida
durante la especiali- zación y la disponibilidad de un port [31]
del sistema para plataformas de FPGAs y SoCs de Xilinx. Como base
para implementar la comunicación mediante sockets a la PC, se
tomaron además los ejemplos de aplicación del stack TCP/IP lwIP
[32] que vienen incluidos dentro de las librerías que provee Xilinx
en su paquete de software.
34 Capítulo 3. Diseño e implementación
Drivers generador y demoduladorDrivers
Xilinx
FreeRTOS
lwIP
Aplicación
FIGURA 3.14. Capas del software desarrollado. En gris, el código
propio y en blanco, las librerías utilizadas.
3.3.1. Drivers
Los módulos desarrollados en lógica programable, generador y
demodulador, cuentan con registros de configuración accesibles
desde el espacio de memoria del procesador vía buses AXI-Lite. Los
drivers desarrollados para ambos módu- los realizan el acceso a
bajo nivel de estos registros de configuración, mediante
estructuras de control y métodos de configuración y control de la
operación de cada módulo.
Los listados de código 3.1 y 3.2 muestran las estructuras de
control, mientras que los listados 3.3 y 3.4 contienen los
prototipos de las funciones implementadas para el generador y el
demodulador.
Para ambos drivers es posible la utilización tanto en una
aplicación baremetal co- mo con FreeRTOS.
1 typedef s t r u c t Waveform_Generator 2 { 3 /∗ General a t t r i
b u t e s ∗/ 4 u i n t 3 2 _ t address ; 5 u i n t 8 _ t enabled ;
6 generator_mode_t mode ; 7 u i n t 8 _ t modulation_en ; 8 u i n t
8 _ t modulation_mode ; 9 /∗ Continuous mode a t t r i b u t e s
∗/
10 u i n t 3 2 _ t cont_freq_khz ; 11 /∗ Pulsed mode A t t r i b u
t e s ∗/ 12 u i n t 3 2 _ t period_us ; 13 u i n t 3 2 _ t
pulse_length_us ; 14 /∗ Frequency modulation a t t r i b u t e s ∗/
15 u i n t 3 2 _ t low_freq_khz ; 16 u i n t 3 2 _ t high_freq_khz
; 17 u i n t 3 2 _ t de l ta_p inc ; 18 /∗ Phase mode a t t r i b u
t e s ∗/ 19 u i n t 3 2 _ t barker_subpulse_length_us ; 20 u i n t
8 _ t barker_seq_num ; 21 /∗ AXI−DMA IP Core a t t r i b u t e s
∗/
3.3. Software 35
22 u i n t 3 2 _ t axi_dma_device_id ; 23 XAxiDma axi_dma_inst ; 24
XAxiDma_Config ∗axi_dma_cfg_ptr ; 25 /∗ Debug a t t r i b u t e s
∗/ 26 u i n t 3 2 _ t ∗debug_samples_ptr ; // Locat ion of
generated samples 27 u i n t 3 2 _ t valid_debug_samples ; //
Amount of samples copied from FPGA
by DMA 28
CÓDIGO 3.1. Estructura de control del módulo generador.
1 typedef s t r u c t IQ_Demod 2 { 3 /∗ General a t t r i b u t e s
∗/ 4 u i n t 3 2 _ t address ; 5 u i n t 8 _ t enabled ; 6 source_e
source ; 7 /∗ Amount of samples to t r a n s f e r from FPGA ∗/ 8 u
i n t 3 2 _ t num_samples ; 9 /∗ Local o s c i l l a t o r ∗/
10 l o _ f r e q _ e lo_freq_khz ; 11 r a t e s _ e dec imat
ion_rate ; 12 /∗ AXI−DMA IP Core a t t r i b u t e s ∗/ 13 u i n t
3 2 _ t axi_dma_device_id ; 14 XAxiDma axi_dma_inst ; 15
XAxiDma_Config ∗axi_dma_cfg_ptr ; 16 /∗ Data re c e pt i on a t t r
i b u t e s ∗/ 17 u i n t 6 4 _ t ∗bb_samples_ptr ; // Locat ion of
baseband demodulated
samples 18 u i n t 3 2 _ t valid_bb_samples ; // Amount of samples
copied from FPGA by
DMA 19 } IQ_Demod_t ;
CÓDIGO 3.2. Estructura de control del módulo demodulador.
1 void g e n e r a t o r _ i n i t ( Waveform_Generator_t ∗ g , u i
n t 3 2 _ t hw_address , u i n t 3 2 _ t axi_dma_device_id )
;
2 i n t generator_enable_debug ( Waveform_Generator_t ∗ g ) ; 3 i n
t g e n e r a t o r _ s t a r t ( Waveform_Generator_t ∗ g ) ; 4 i
n t generator_s top ( Waveform_Generator_t ∗ g ) ; 5 i n t
set_continuous_mode_constant_freq ( Waveform_Generator_t ∗ g
,
u i n t 3 2 _ t freq_khz ) ; 6 i n t set_continuous_mode_freq_mod (
Waveform_Generator_t ∗ g , u i n t 3 2 _ t
low_freq_khz , u i n t 3 2 _ t high_freq_khz , u i n t 3 2 _ t
length_us ) ; 7 i n t set_continuous_mode_phase_mod (
Waveform_Generator_t ∗ g , u i n t 3 2 _ t
freq_khz , u i n t 8 _ t barker_seq_num , u i n t 3 2 _ t
barker_seq_length_us ) ; 8 i n t set_pulsed_mode_constant_freq (
Waveform_Generator_t ∗ g , u i n t 3 2 _ t
period_us , u i n t 3 2 _ t pulse_length_us , u i n t 3 2 _ t
freq_khz ) ; 9 i n t set_pulsed_mode_freq_mod (
Waveform_Generator_t ∗ g , u i n t 3 2 _ t
period_us , u i n t 3 2 _ t pulse_length_us , u i n t 3 2 _ t
low_freq_khz , u i n t 3 2 _ t high_freq_khz ) ;
10 i n t set_pulsed_mode_phase_mod ( Waveform_Generator_t ∗ g , u i
n t 3 2 _ t period_us , u i n t 3 2 _ t pulse_length_us , u i n t 3
2 _ t freq_khz , u i n t 8 _ t barker_seq_num ) ;
11 i n t generator_tr igger_debug ( Waveform_Generator_t ∗ wg) ; 12
void generator_get_ i_samples ( Waveform_Generator_t ∗wg, s32 ∗
i_samples ,
u32 num_samples ) ; 13 void generator_get_q_samples (
Waveform_Generator_t ∗wg, s32 ∗q_samples ,
u32 num_samples ) ;
36 Capítulo 3. Diseño e implementación
1 i n t iq_demod_init ( IQ_Demod_t ∗demod , u i n t 3 2 _ t
hw_address , u i n t 3 2 _ t axi_dma_device_id ) ;
2 i n t iq_demod_set_lo ( IQ_Demod_t ∗demod , l o _ f r e q _ e f r
e q ) ; 3 i n t iq_demod_set_decimation ( IQ_Demod_t ∗demod , r a t
e s _ e r a t e ) ; 4 i n t iq_demod_tr igger_transfer ( IQ_Demod_t
∗demod , u i n t 3 2 _ t num_samples )
; 5 void iq_demod_set_ source_e x t e r n a l ( IQ_Demod_t∗ demod)
; 6 void iq_demod_set_source_internal ( IQ_Demod_t∗ demod) ; 7 void
iq_demod_start ( IQ_Demod_t ∗demod) ; 8 void iq_demod_stop (
IQ_Demod_t ∗demod) ; 9 void iq_demod_get_i_samples ( IQ_Demod_t
∗demod , s32 ∗ i_samples , u32
num_samples ) ; 10 void iq_demod_get_q_samples ( IQ_Demod_t ∗demod
, s32 ∗q_samples , u32
num_samples ) ;
3.3.2. Aplicación
La aplicación desarrollada cumple la función de plataforma de
pruebas del ge- nerador y el demodulador, y también constituye un
primer paso para lograr un sistema de adquisición de datos que en
un futuro pueda operar en tiempo real vía la conexión Ethernet.
Está dividida en diversas tareas que controlan las distintas
funciones concurrentemente.
Se eligió trabajar el stack lwIP con su API de sockets [33] ya que
es el modo de operación compatible con FreeRTOS2. Se tomó como base
para el desarrollo uno de los ejemplos provistos por Xilinx [34]
que presenta la implementación de un servidor eco.
La tabla 3.9 detalla las tareas que componen la aplicación,
listadas en orden tem- poral de creación y ejecución.
La operación de la plataforma se realiza completamente vía comandos
de confi- guración y control que se envían a través del socket TCP
creado desde la aplica- ción principal. Para realizar la validación
del sistema generador y demodulador se crearon dos subaplicaciones
que son lanzadas o eliminadas por la aplicación principal en
función del modo de operación configurado a través de la interfaz
de red. Una vez establecida la comunicación puede comandarse la
operación de los módulos generador y demodulador con una estructura
de comandos imple- mentada mediante el mecanismo de Protocol
Buffers (ó Protobuf) descripto en la sección 2.5.
2De forma contraria a la API de sockets, la API RAW de lwIP corre
en aplicaciones de un solo hilo.
3.3. Software 37
TABLA 3.9. Tareas del sistema completo ordenadas de forma des-
cendente por orden de creación y ejecución.
Tarea Descripción
lwip_init_thread Inicializa el stack lwIP.
network_thread Configura e inicializa las interfaces de red vía la
función xemac_add (que es parte de la librería de
Xilinx) y a su vez crea la tarea link_detect_thread para detección
periódica del link Ethernet. Luego se lanza
la tarea xemacif_input_thread.
xemacif_input_thread Realiza el vínculo entre la interfaz de red y
el stack lwIP ante la llegada de paquetes. Esta tarea es
mandatoria para la utilización de la API de sockets en
controladores de Ethernet de Xilinx, y es provista por Xilinx como
parte de las librerías de lwIP. Una
vez levantada la interfaz de red, se inicia la aplicación
principal.
main_app_thread Aplicación principal. Inicializa las instancias de
hardware del generador y el demodulador, crea el
socket TCP y espera conexiones. Una vez aceptadas las conexiones se
bloquea esperando comandos de
configuración para lanzar alguna de las subaplicaciones del
generador o del demodulador.
incoming_data_thread Esta tarea se crea una vez que se acepta la
conexión de un socket y se encarga de manejar los datos
entrantes.
output_data_thread Esta tarea se crea una vez que se acepta la
conexión de un socket y se encarga de manejar los datos
salientes.
generator_app_thread Subaplicación creada para controlar y operar
el módulo de lógica programable generador.
Decodifica los mensajes recibidos y aplica las configuraciones al
hardware.
iq_demod_app_thread Subaplicación creada para controlar y operar el
módulo de lógica programable demodulador. Decodifica los mensajes
recibidos y aplica las
configuraciones al hardware.
38 Capítulo 3. Diseño e implementación
Los mensajes de configuración y control creados mediante Protobuf
se estructu- raron como se muestra en la figura 3.15. Se diseñó un
mensaje base como contene- dor de los tipos posibles de mensajes a
intercambiar entre la plataforma y el usua- rio a través del socket
TCP. Los tres tipos de mensaje corresponden a estructuras de
control, de configuración (que a su vez pueden corresponder al
generador o al demodulador) o de acknowledge, para interpretar la
respuesta enviada desde la plataforma.
Una vez diseñados los mensajes, que se codificaron con el lenguaje
de descripción de interfaz en un archivo messages.proto, se
generaron los códigos fuente para uti- lización en C y
Python.
Base_msg
39
Ensayos y Resultados
A continuación se presenta un esquema general de los ensayos
realizados a la plataforma y un reporte de los recursos utilizados
de lógica programable.
4.1. Banco de pruebas
Se desarrolló una aplicación en Python a modo de banco de pruebas
de la pla- taforma. A través de la aplicación se puede controlar el
sistema y descargar los datos para depuración y análisis de las
señales generadas.
Como fuera presentado anteriormente en la sección 3.3.2, se utilizó
en el desa- rrollo del software embebido, el stack lwIP con su API
basada en sockets para la comunicación vía Ethernet a una PC. A
través de la biblioteca de sockets de Python se implementó la
comunicación entre el banco de pruebas en la PC y la placa, y se
crearon módulos de Python correspondientes al generador y al demo-
dulador. Se muestra en la figura 4.1 la configuración utilizada
para llevar a cabo las pruebas.
radar_test_platform.py
FIGURA 4.1. Esquema de conexiones del sistema.
La figura 4.2 muestra el diagrama de clases de la aplicación del
banco de pruebas. Las clases Generator e IQ_Demod modelan el
comportamiento de los subsistemas
40 Capítulo 4. Ensayos y Resultados
correspondientes en la FPGA y proveen métodos para configurar y
comandar co- rrectamente la operación. Por ejemplo, métodos para
configurar las formas de on- da en el caso del generador, y métodos
para configurar los parámetros de las eta- pas de multiplicación y
filtrado en el demodulador. La clase Radar_Test_Platform contiene
una instancia de cada módulo (demod y generator respectivamente) y,
a través de los métodos demodulator_tests() y generator_tests () se
ejecuta la batería de pruebas implementada.
En las siguientes secciones se muestran, a modo de ejemplo, algunas
de las vali- daciones realizadas dentro del conjunto de
pruebas.
FIGURA 4.2. Diagrama de clases del banco de pruebas.
4.2. Generador 41
4.2. Generador
En el proceso de validación del módulo generador, se deben recorrer
todos los modos de operación establecidos en las especificaciones,
ya sean para la genera- ción continua o pulsada de señales como
para los distintos tipos de modulación. A continuación se presentan
los resultados para algunas configuraciones repre-
sentativas.
4.2.1. Modo continuo y frecuencia constante
Las figuras 4.3 y 4.5 muestran dos casos de prueba para señales con
frecuencia constante de 1 MHz y 20 MHz, respectivamente. Se
acompaña también con un esquema del análisis en frecuencia de ambas
señales en las figuras 4.4 y 4.6. Se puede observar la compomente
de frecuencia presente y notar también que el espectro es
asimétrico al tratarse de una señal compleja generada con sus
compo- nentes I y Q.
Las gráficas que se muestran a lo largo de esta sección se
realizaron mediante el paquete de Python matplotlib [35].
Puntualmente, el gráfico para el análisis en frecuencia se realizó
con el método magnitude_spectrum [36].
Tiempo [s]
0 1 2 3 4 5 Tiempo [s] 1e 6
A m
p lit
u d
A m
p lit
u d
0
-8192
8191
0
-8192
8191
FIGURA 4.3. Muestras I y Q generadas para una señal de 1 MHz.
42 Capítulo 4. Ensayos y Resultados
1.0 0.5 0.0 0.5 1.0 Frecuencia [Hz] 1e6
125
100
75
50
25
0
25
50
75
B] Espectro señal de salida
FIGURA 4.4. Espectro de la señal mostrada en la figura 4.3.
Tiempo [s]
0.0 0.2 0.4 0.6 0.8 1.0 Tiempo [s] 1e 6
Muestras Generadas Q
0
-8192
8191
FIGURA 4.5. Muestras I y Q generadas para una señal de 20
MHz.
4.2. Generador 43
2.0 1.5 1.0 0.5 0.0 0.5 1.0 1.5 2.0 Frecuencia [Hz] 1e7
125
100
75
50
25
0
25
50
75
Espectro señal de salida
FIGURA 4.6. Espectro de la señal mostrada en la figura 4.5.
44 Capítulo 4. Ensayos y Resultados
4.2.2. Modo pulsado y frecuencia constante
Las figuras 4.7 y 4.8 muestran dos configuraciones para la
operación en modo pul- sado de señales senoidales a frecuencia
constante. Por inspección de las muestras generadas se observa que
tanto el período como el ancho de pulso de las señales obtenidas se
corresponden con los configurados.
Tiempo [s]
Muestras Generadas Q
100 μs 20μs
0
-8192
8191
FIGURA 4.7. Muestras I y Q generadas para una señal pulsada de 200
kHz, per