Este proyecto se realiza como parte del proyecto Desarrollo de una consola operativa conectable a través de una interfaz de comunicación bidireccional al sistema de comando y control de las unidades de la Armada Argentina, realizado por la Escuela de Oficiales de Soluciones Embebidas Aplicadas grupo. de la Armada y del Servicio de Análisis Operacional, Armamento y Guerra Electrónica de la Armada Argentina. Lea el registro 0, obtenga la trama ASTERIX CAT240, verifique la pérdida de paquetes, copie y luego transmita las tramas.
Lista de tablas
Introducción
En definitiva, el software creado se encarga en primera instancia de mapear los puertos de lectura de memoria de la FPGA a memorias virtuales para que se pueda acceder a ellas desde el lado HPS. Esta memoria es RAM de doble puerto, que es la memoria compartida entre la FPGA y la HPS.
Descripción del proyecto
- Propuesta de proyecto
- Puesta en marcha y configuración del kit DE1-SoC
- Software (sin la implementación del handshake entre la FPGA y el HPS)
- Parte Qsys
- Parte QtCreator
- Ensayos (sin la implementación del handshake entre la FPGA y el HPS)
- Transmisión y recepción de paquetes UDP utilizando el comando iperf
- Medición de tiempos de lectura y de transmisión con datos fijos Haciendo uso de una PC y del kit de desarrollo DE1-SoC, se realizará una prueba
- Medición de tiempos de lectura y de transmisión con datos fijos empaquetados en protocolo ASTERIX CAT240
- Software (con la implementación del handshake entre la FPGA y el HPS)
- Parte Qsys
- Parte QtCreator
- Ensayos (con la implementación del handshake entre la FPGA y el HPS)
- Medición de tiempos de lectura y de transmisión con datos empaquetados en protocolo ASTERIX CAT240
Se abre con la consola de Linux con el comando quartus & como se muestra en la Figura 33 a continuación. A continuación, toda la memoria FPGA (8192 [bytes]) se escribe con datos fijos empaquetados en el protocolo ASTERIX CAT240 y luego se lee desde el HPS. Este archivo .hex es el que se carga en la RAM de doble puerto, la memoria compartida por la FPGA y el HPS, desde la herramienta de simulación gráfica Qsys para ser escrito o cargado con datos empaquetados en el protocolo ASTERIX CAT240 desde la FPGA.
Copiar la trama ASTERIX CAT240 y posteriormente transmitirla por Ethernet a través del socket UDP. A continuación, usando la función memcpy()[16], el contenido del puntero sram_ptr se transfiere a una matriz de datos para finalmente enviar estos datos a través de Ethernet a través del socket UDP usando la función sendto()[18]. Este archivo.hex es el que se carga en la RAM de doble puerto para simular la escritura con datos empaquetados en el protocolo ASTERIX CAT240 desde el lado FPGA.
Se puede observar que la trama definitivamente está empaquetada en el protocolo ASTERIX CAT240 porque se identifica el primer byte de ese conf0. La variable de datos es una matriz de datos que se utiliza para cargar o copiar el contenido cargado en la memoria SRAM de doble puerto, que es nada más ni nada menos que el paquete o trama empaquetado en el protocolo ASTERIX CAT240 del lado FPGA. Usando la función memcpy()[16], el contenido almacenado en la memoria mem[num_mem] de tamaño payload_size se transfiere a la matriz de datos.
Dichos datos se generan, se empaquetan en el protocolo ASTERIX CAT240 y luego se cargan en la RAM de doble puerto, que es la memoria compartida entre la FPGA y el HPS, desde el lado de la FPGA. Esta prueba consiste en leer los datos empaquetados en el protocolo ASTERIX CAT240, que fue creado previamente, empaquetados en dicho protocolo y cargados en la RAM de doble puerto, que es la memoria compartida entre la FPGA y el HPS, de la FPGA. Luego, usando la función memcpy()[16], el contenido del puntero mem[num_mem] se transfiere a una matriz de datos para finalmente enviar dichos datos a través de Ethernet a través del socket UDP usando la función sendto()[18].
Conclusiones
De las pruebas realizadas encontramos que los datos fueron leídos a una velocidad de 166 [MB/s]15, mientras que la capacidad máxima del canal fue de 112 [MB/s]16. Todas las pruebas presentadas hasta ahora se han realizado sin la lógica de sincronización entre la FPGA y el HPS, es decir, sin el handshake entre escritura y lectura de la memoria compartida, donde la FPGA se encarga de escribir y el HPS de leer. Luego de realizado el ensayo o prueba, se concluyó que efectivamente se había logrado el propósito propuesto, que era leer datos o tramas empaquetadas en el protocolo ASTERIX CAT240 de una memoria compartida entre la FPGA y el HPS, copiarlos y transmitirlos. Ethernet a una velocidad (rendimiento) o velocidad efectiva de transferencia de datos UDP en tiempo real superior a 32 [MB/s], que es la velocidad a la que se escribe la memoria desde el lado FPGA.
La velocidad de transmisión alcanzada en la cuarta fase fue de aproximadamente 290 [Mbps]17. Realizar el protocolo de enlace tiene un efecto negativo en la velocidad de transferencia debido al tiempo muerto que aparece cuando el HPS espera a que la FPGA llene un búfer. Por lo tanto, luego de las pruebas realizadas, se determinó que tramas de hasta 1440 [bytes]18 son ideales para evitar cualquier tipo de retraso y desincronización en ambos lados, lo que lleva a la pérdida de.
Aún así, es posible aumentar el tamaño de los buffers con hardware de tal manera que se aumente el tamaño de muestra de los paquetes y no se produzca pérdida de paquetes, pero esto no se consideró necesario por el momento. Cabe señalar que el valor de MTU se da para lograr la mayor eficiencia en la red, ya que la fragmentación implica una pérdida de eficiencia al tener que procesar más cabeceras[32].
Anexo A: Placa DE1-SoC de Terasic
Placa DE1-SoC de Terasic
- DE1-SoC de Terasic. Diagrama en bloque
- DE1-SoC de Terasic. Layout
La Figura A.2 y la Figura A.3, que se ven a continuación, describen el diseño del kit de desarrollo Terasic DE1-SoC. Para un análisis más extenso y detallado de las características y/o especificaciones del kit de desarrollo DE1-SoC, además de otra documentación relevante, consultar la bibliografía correspondiente.
Cyclone V. Descripción general
- Introducción al HPS de Cyclone V
- Características del HPS
- Interfaces HPS-FPGA
- Proceso de booteo del HPS
El software que configura los pines de E/S del HPS es el precargador, como se explicará en la siguiente sección de este informe. La Figura A.5 a continuación muestra un diagrama de bloques de las características más relevantes del HPS. La primera etapa del software es la ROM de arranque cuyo código localiza y ejecuta la segunda etapa, el llamado precargador, que (si está presente) localiza la siguiente etapa.
Las etapas del precargador y las etapas de software posteriores se denominan colectivamente software de usuario. La Figura A.6 anterior muestra las secuencias de arranque HPS disponibles. Las fases de reinicio y arranque de ROM son las únicas partes fijas del proceso de arranque.
Todo lo incluido en las etapas del software de usuario se puede personalizar. Las fases de reinicio, ROM de arranque y precargador siempre están presentes en el flujo de arranque de HPS.
Uso del Cyclone V. Información general
- Proceso de booteo del HPS
- Estructura del proyecto
En realidad es lo que se llama fuente o recurso porque no se pueden modificar todas las etapas anteriores. En nuestro caso, como veremos en el siguiente apartado de este informe, utilizaremos este último. El código multiproceso es mucho más fácil de escribir ya que el programador tiene acceso a las llamadas de las familias de subprocesos del sistema.
Debido al sistema de memoria virtual creado por el sistema operativo, un programa no puede acceder directamente a los periféricos HPS a través de sus direcciones de memoria física asignadas o asignadas. En términos generales, programar en Linux es superior y mucho más fácil en comparación con el código básico, ya que sus ventajas superan con creces sus desventajas. El proceso de desarrollo crea muchos más archivos en comparación con un diseño exclusivo de FPGA.
La estructura de carpetas que se ve en la Figura A.7 se utilizará para organizar el proyecto. El directorio sdcard contiene todo lo necesario para crear una tarjeta SD válida desde la cual pueda arrancar el SoC DE1.
Anexo B: Protocolo ASTERIX CAT240
Tanto de la Tabla B.1 como de la Figura B.1 se puede observar que el paquete encapsulado en el protocolo ASTERIX consta o está formado por una cabecera (cabecera de vídeo) y un bloque de datos (bloque de datos de vídeo). En el caso real, el marco o paquete está armado con un disparador o un BI, que son señales enviadas por el radar. En otras palabras, para cada nueva señal de activación de BI, se finaliza un cuadro y se inicia uno nuevo.
Por otro lado, para empezar a trazar, siempre esperamos el primer disparo del HM, que también es una señal enviada por el radar. El HM indica el final y el inicio del barrido, que puede estar referido al norte (norte arriba), a proa (proa arriba) o al rumbo actual del buque (rumbo arriba)[27]. Un detalle a tener en cuenta es que el protocolo ASTERIX define que el vídeo RADAR debe apuntar al Norte[13].
De las imágenes observadas anteriormente se puede decir que por cada pulso de disparo se regresa al origen o centro del radar mientras que por cada pulso BI los datos se concatenan al nuevo pulso de disparo, con el cual regresa al centro del radar. . , también indica el alcance del radar. . Además, por barrido o retorno completo al radar, existen 65.536 paquetes cuyo tamaño dependerá del tamaño del paquete o trama empaquetado en el protocolo ASTERIX CAT240, que es variable.
Anexo C: Modelo OSI
Capa física
- Capa de enlace de datos: Ethernet II
- Capa de red: Trama IPv4
- Capa de transporte 1. Trama UDP
- Tamaño máximo del payload en del mensaje UDP
En el segundo caso, la longitud de la trama está determinada por la ubicación del espacio entre los paquetes y el FCS. El valor 0x0800 (2048 en decimal, por tanto corresponde a EtherType) indica que se utiliza el protocolo IPv4. En caso de que la información sea menor que la cantidad mínima permitida (46 [bytes]), se realiza el relleno.
El valor FCS se calcula en función de los campos protegidos MAC: dirección de origen y destino, Ethertype, datos y relleno. DSCP y ECN: (1 [byte]) Estos campos indican el valor de prioridad, la probabilidad de pérdida de paquetes y el servicio de red utilizado. Si el checksum calculado en destino y el recibido es diferente, el paquete es rechazado.
El valor se encuentra sumando todos los campos del encabezado (excepto la suma de verificación en sí) y realizando la suma de uno en uno. Suma de comprobación: (2 [bytes]) coincide con el encabezado UDP, los datos, junto con los campos de longitud, protocolo, dirección de origen y destino de la trama IP.
Agradecimientos
5] https://infoaleph.wordpress.com como-cambiar-el-idioma-del-ambiente -grafico-de-gnulinux-debian-despues-de-la-instalacion/. 6] https://ciksiti.com/es/chapters/8566-how-to-change-debian-desktop-environment [7] https://users.cs.jmu.edu/bernstdh/web/common/lectures/ summary_unix_udp.php [8] https://man7.org/linux/man-pages/man2/socket.2.html. 14] https://gcc.gnu.org/onlinedocs/gcc-3.3/gcc/Type-Attributes.html [15] https://linuxhint.com/gettimeofday_c_language/.
16] https://www.tutorialspoint.com/c_standard_library/c_function_memcpy.htm [17] https://es.wikipedia.org/wiki/Endianness. 19] https://people.ece.cornell.edu/land/courses/ece5760/DE1_SOC/HPS_peripherial s/FPGA_addr_index.html. 22] https://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&Catego ryNo=165&No=836#contents.
