Desarrollo de etapa digital para radar pulsado multipropósito

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 bloque 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 radio. 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 forma 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 pulso 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 embargo, 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 segundo 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 corrimiento 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
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 sistema 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 linealmente 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 radiofrecuencia, 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 correspondiente. 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 senoidal.
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.
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, procesamiento 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 aplicaciones 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 plataforma 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 proyecto 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.
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 capacidad 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 procesamiento (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 arquitectura 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 tomada 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
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 medio 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 desarrollados sean compatibles con dicha interfaz. En la figura 2.2 se presenta una arquitectura genérica de procesamiento en lógica programable, que tiene interfaces 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, dentro 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 implementa 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 subsistemas 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 para 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 digital 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 receptores 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 intermedia 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 adquirida, 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 radiofrecuencia 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 compensar 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.
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 para 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 microcontroladores.
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 subsistemas 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 frecuencias 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 interfaz 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.
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, implementadas 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 frecuencia 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.
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.
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
Mapa de memoria
La instancia del banco de registros del generador se diseñó con el mapa de memoria 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.
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
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 frecuencia 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 frecuencia.
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.
0 1 1 1 10 0
FIGURA 3.8. Secuencia Barker número siete y definición de “subpulso”.
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 secuencia 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 generar.
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 funciones del mixer y posterior filtrado. Estos son: Complex Multiplier, CIC Compiler y FIR Compiler.
Se diseñó el demodulador previendo algunos escenarios concretos. Estos escenarios 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 intermedia 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 frecuencias 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.
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 compone 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
modifican el comportamiento de la demodulación, es posible configurar la cantidad 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ó utilizando 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 componente 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 salida 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 multipicador. 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.
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 muestras 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 desarrollaron 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 demodulador, 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.
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 como 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 ) ;
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 generador 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 implementada 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 descendente 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.
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 plataforma. 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 desarrollo 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 demodulador. 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 correctamente la operación. Por ejemplo, métodos para configurar las formas de onda en el caso del generador, y métodos para configurar los parámetros de las etapas 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 componentes 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.
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.
4.2.2. Modo pulsado y frecuencia constante
Las figuras 4.7 y 4.8 muestran dos configuraciones para la operación en modo pulsado 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

Documents

Desarrollo de etapa digital para radar pulsado multipropósito