sistema para pruebas de alta velocidad y bajo ruido en...
TRANSCRIPT
CARRERA DE ESPECIALIZACIÓN ENSISTEMAS EMBEBIDOS
MEMORIA DEL TRABAJO FINAL
Sistema para pruebas de alta velocidad ybajo ruido en circuitos integrados
Autor:Ing. Matías Paramidani
Director:Ing. Nicolás Alvarez (FIUBA, UNSAM)
Jurados:Mg. Ing. Facundo Larosa (UTN-FRH, FIUBA)
Esp. Ing. Pedro Martos (FIUBA)Dr. Ing. Sebastián Carbonetto (FIUBA)
Este trabajo fue realizado en la Ciudad Autónoma de Buenos Aires,entre junio de 2019 y abril de 2020.
III
Resumen
La presente memoria describe el desarrollo de un sistema que permite realizarensayos de laboratorio sobre distintos circuitos integrados. Este trabajo fue
solicitado por la empresa Allegro Microsystems, dedicada al diseño, fabricacióny evaluación de circuitos integrados.
En la elaboración de este trabajo se han aplicado los conocimientos adquiridossobre diseño de lógica programable, microarquitecturas, diseño de circuitos
impresos, desarrollo de firmware y software.
V
Agradecimientos
Agradezco principalmente a mi familia, a mi novia y a mis amigos por la pacien-cia y el apoyo que me brindaron a lo largo de todo este trabajo.
VII
Índice general
Resumen III
1. Introducción General 11.1. Circuitos integrados en Allegro Microsystems . . . . . . . . . . . . 1
1.1.1. Aplicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.1.2. Arquitectura general . . . . . . . . . . . . . . . . . . . . . . . 31.1.3. Ensayos realizados en el país . . . . . . . . . . . . . . . . . . 4
1.2. Análisis del sistema preexistente . . . . . . . . . . . . . . . . . . . . 61.3. Motivación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.4. Objetivos y alcance . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2. Introducción Específica 92.1. Sistema en chip (SoC) . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.1. Interfaz AXI4 . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.2. Protocolos de comunicación . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.1. SPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.2.2. I2C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.2.3. Manchester . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.3. Requerimientos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.3.1. Requerimientos generales . . . . . . . . . . . . . . . . . . . . 182.3.2. Requerimientos de las pruebas . . . . . . . . . . . . . . . . . 182.3.3. Requerimientos para el manejo de instrumentos de medición 182.3.4. Requerimientos para la comunicación con el DUT . . . . . . 182.3.5. Requerimientos de hardware . . . . . . . . . . . . . . . . . . 192.3.6. Modificaciones realizadas durante el desarrollo . . . . . . . 19
2.4. Planificación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3. Diseño e Implementación 233.1. Arquitectura del sistema desarrollado . . . . . . . . . . . . . . . . . 23
3.1.1. Flujo de diseño . . . . . . . . . . . . . . . . . . . . . . . . . . 243.1.2. Diseño del sistema en chip . . . . . . . . . . . . . . . . . . . 24
3.2. Lógica programable . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.2.1. Módulos para los protocolos de comunicación . . . . . . . . 26
Generación de interfaces AXI . . . . . . . . . . . . . . . . . . 283.2.2. Acceso Directo a Memoria . . . . . . . . . . . . . . . . . . . . 29
Inicialización y uso . . . . . . . . . . . . . . . . . . . . . . . . 303.3. Módulo de procesamiento . . . . . . . . . . . . . . . . . . . . . . . . 30
3.3.1. Mapa de memoria . . . . . . . . . . . . . . . . . . . . . . . . 313.4. Sistema Operativo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.4.1. Primera etapa de bootloader . . . . . . . . . . . . . . . . . . 323.4.2. Segunda etapa de bootloader . . . . . . . . . . . . . . . . . . 333.4.3. Árbol de dispositivos . . . . . . . . . . . . . . . . . . . . . . . 343.4.4. Kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
VIII
3.4.5. Sistema de archivos . . . . . . . . . . . . . . . . . . . . . . . . 363.4.6. Montaje de los componentes en la tarjeta SD . . . . . . . . . 363.4.7. Drivers para la lógica programable . . . . . . . . . . . . . . . 37
Drivers para los módulos de comunicación . . . . . . . . . . 37Drivers para los DMA . . . . . . . . . . . . . . . . . . . . . . 38
3.5. Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393.5.1. Control de la tensión de los DUTs . . . . . . . . . . . . . . . 403.5.2. Interfaces para los protocolos de comunicación . . . . . . . . 40
4. Ensayos y Resultados 434.1. Validación de la lógica programable . . . . . . . . . . . . . . . . . . 43
4.1.1. Simulación de los módulos de comunicación . . . . . . . . . 434.1.2. Simulación de las interfaces AXI . . . . . . . . . . . . . . . . 45
4.2. Pruebas de integración . . . . . . . . . . . . . . . . . . . . . . . . . . 464.2.1. Resultados de las pruebas en baremetal . . . . . . . . . . . . 474.2.2. Resultados de las pruebas en Linux . . . . . . . . . . . . . . 48
4.3. Caso de aplicación . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5. Conclusiones 515.1. Conclusiones generales . . . . . . . . . . . . . . . . . . . . . . . . . . 515.2. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Bibliografía 53
IX
Índice de figuras
1.1. Circuito integrado encapsulado . . . . . . . . . . . . . . . . . . . . . 11.2. Circuito integrado decapado . . . . . . . . . . . . . . . . . . . . . . . 11.3. Arquitectura de un circuito integrado . . . . . . . . . . . . . . . . . 31.4. Micro prober utilizado para mediciones sobre silicio . . . . . . . . . 51.5. Circuito impreso para ensayos en encapsulados . . . . . . . . . . . 51.6. Sistema ASEK - Vista exterior . . . . . . . . . . . . . . . . . . . . . . 71.7. Sistema ASEK - Vista interior . . . . . . . . . . . . . . . . . . . . . . 71.8. Latencia en la comunicación del ASEK . . . . . . . . . . . . . . . . . 7
2.1. Arquitectura de la familia Zynq-7000-SoC . . . . . . . . . . . . . . . 102.2. Canales de las interfaces AXI-Full y AXI-Lite. . . . . . . . . . . . . . 122.3. Módulo de interconexión para AXI4 de Xilinx . . . . . . . . . . . . . 132.4. Señales del protocolo SPI. . . . . . . . . . . . . . . . . . . . . . . . . 142.5. Tramas del protocolo SPI versión estándar y ASIL-D. . . . . . . . . 142.6. I2C: condiciones de INICIO y FIN . . . . . . . . . . . . . . . . . . . 152.7. I2C: comando de escritura de 32 bits . . . . . . . . . . . . . . . . . . 152.8. I2C: comando de lectura de 32 bits . . . . . . . . . . . . . . . . . . . 162.9. Codificación del protocolo Manchester . . . . . . . . . . . . . . . . . 162.10. Comandos del protocolo Manchester . . . . . . . . . . . . . . . . . . 172.11. Diagrama de activity-on-node. . . . . . . . . . . . . . . . . . . . . . . 202.12. Diagrama de Gantt. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.1. Arquitectura del sistema desarrollado . . . . . . . . . . . . . . . . . 233.2. Diagrama en bloques del sistema diseñado con Vivado. . . . . . . . 253.3. Diagrama simplificado de la PL. . . . . . . . . . . . . . . . . . . . . 253.4. Interfaz AXI para los módulos de comunicación con el DUT. . . . . 263.5. Registros internos del bloque AXI_Ctrl. . . . . . . . . . . . . . . . . 273.6. Configuración de las interfaces AXI de los módulos de comunicación. 283.7. Configuración del módulo AXI_DMA. . . . . . . . . . . . . . . . . . 293.8. Sistema de procesamiento ZYNQ7. . . . . . . . . . . . . . . . . . . . 303.9. Mapa de memoria de la lógica programable. . . . . . . . . . . . . . 313.10. Plantilla para la generación del FSBL proporcionada por Xilinx. . . 323.11. Descripción de los módulos PL en el device tree. . . . . . . . . . . . . 353.12. Argumentos definidos en el device tree para la carga del sistema
operativo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353.13. Circuito impreso desarrollado. . . . . . . . . . . . . . . . . . . . . . 403.14. Circuito para la alimentación de los DUTs. . . . . . . . . . . . . . . . 413.15. Circuito aislador utilizado para la comunicación SPI. . . . . . . . . 413.16. Interfaz utilizada para la comunicación I2C. . . . . . . . . . . . . . . 423.17. Diagrama de la interfaz para el protocolo Manchester. . . . . . . . . 42
4.1. Formas de onda simuladas para cada protocolo. . . . . . . . . . . . 444.2. Banco de prueba para las interfaces AXI. . . . . . . . . . . . . . . . . 46
X
4.3. Simulación de la interfaz AXI_Ctrl. . . . . . . . . . . . . . . . . . . . 464.4. Simulación de la interfaz AXIS_Data. . . . . . . . . . . . . . . . . . . 474.5. Prueba de escritura múltiple en baremetal . . . . . . . . . . . . . . . 474.6. Prueba de lectura múltiple en baremetal . . . . . . . . . . . . . . . . 484.7. Prueba de escritura múltiple en Linux . . . . . . . . . . . . . . . . . 484.8. Prueba de lectura múltiple en Linux . . . . . . . . . . . . . . . . . . 48
XI
Índice de Tablas
2.1. Tipos de interfaces AXI4 . . . . . . . . . . . . . . . . . . . . . . . . . 112.2. Diferencias entre SPI y SPI-ASILD . . . . . . . . . . . . . . . . . . . 14
3.1. Entradas y salidas estándar para todos los protocolos. . . . . . . . . 263.2. Entradas y salidas propias de cada protocolo. . . . . . . . . . . . . . 27
1
Capítulo 1
Introducción General
En el presente capítulo se introducen algunos conceptos sobre el diseño y la fa-bricación de circuitos integrados, haciendo foco particularmente en los desarro-llados por la empresa Allegro Microsystems. Se mencionan también los aspectosque motivaron la realización de este trabajo, los objetivos y el alcance.
1.1. Circuitos integrados en Allegro Microsystems
Un circuito integrado (CI), también conocido como chip o microchip, es una es-tructura de pequeñas dimensiones de material semiconductor, normalmente sili-cio, de algunos milímetros cuadrados de superficie, sobre la que se fabrican circui-tos electrónicos. Utilizando distintas técnicas, como implantación de impurezas yfotolitografía, se logran circuitos de muy alta complejidad en un área muy redu-cida y a un bajo costo. La pastilla de silicio se coloca dentro de un encapsulado deplástico o de cerámica que posee conductores metálicos, apropiados para hacerla conexión entre el circuito integrado y un circuito impreso. En la figura 1.1 pue-de verse un CI encapsulado mientras que en la figura 1.2 el encapsulado ha sidodecapado lo que permite visualizar la pastilla de silicio y los hilos de conexión.
FIGURA 1.1:Circuito integradoencapsulado.1
FIGURA 1.2:Circuito integradodecapado.2
Allegro Microsystems es una empresa estadounidense dedicada al diseño de CI,cuyo principal campo de aplicación es la industria automotriz. Cuenta con cuatrounidades de negocio (Business Unit - BU): una orientada al desarrollo de drivers depotencia y reguladores lineales, llamada Power BU, y tres enfocadas al desarrollode sensores. Estas son: Speed BU, para sensores de velocidad; Position and angleBU, para sensores de desplazamiento lineal y angular; y Current and isolators BU,dedicada al desarrollo de sensores de corriente y circuitos aisladores.
1https://www.tme.com/co/es/details/udn2987lw-t/drivers-circuitos-integrados/allegro-microsystems/udn2987lwtr-6-t/
2https://commons.wikimedia.org/wiki/File:Decapped_MSP430F1101A.jpg
2 Capítulo 1. Introducción General
En Argentina la empresa cuenta con un centro de diseño formado por un nu-meroso grupo de profesionales, cada uno de ellos abocado a distintas áreas deldesarrollo de un CI:
Modelado de componentes
Diseño analógico
Diseño digital
Diseño físico
Evaluación funcional
Es necesario aclarar que los circuitos diseñados en el país son fabricados en elexterior, pero una vez completa la manufactura ingresan nuevamente a la Argen-tina para su evaluación funcional. Para esto, la empresa cuenta con un laboratoriobien equipado donde se realizan diversas pruebas que verifican el correcto fun-cionamiento de los CI desarrollados.
1.1.1. Aplicaciones
Las principales aplicaciones en las que se enfoca Allegro Microsystems son enu-meradas a continuación:
Aplicaciones automotrices:
• Soluciones para autos eléctricos
• Control de frenos
• Iluminación
• Seguridad
• Confort
Dispositivos electrónicos de consumo:
• Electrodomésticos
• Consolas de videojuegos
• Computadoras
Industria:
• Control de motores
• Sistemas de control de eficiencia energética
• Instrumental médico
1.1. Circuitos integrados en Allegro Microsystems 3
1.1.2. Arquitectura general
La arquitectura de un chip puede variar entre las distintas unidades de negocio yfamilia de productos. Sin embargo, el diagrama presentado en la figura 1.3 repre-senta, de un modo general, a la mayoría de los CI que desarrolla la empresa.
AMPPRIMARIO
CONVERSORA/D
SISTEMA DEALIMENTACION
AMP SALIDA
SISTEMA DEMEMORIA
INTERFAZSERIE
CONTROLGENERAL PROCESAMIENTO DIGITAL
Transductor
OUTPIN
VCCPIN
GNDPIN
Sistemaanalógico
Sistemadigital
Entradas ysalidas
Sistema dealimentación
Sistema dememoria CONTROL DE
MEMORIA
FIGURA 1.3: Diagrama de la arquitectura de un circuito integrado.
La arquitectura puede ser divida en dos sistemas bien diferenciados por su pro-ceso de diseño; por un lado, tenemos el sistema analógico, y por otro, el sistemadigital.
El sistema analógico incluye:
El transductor, que es el dispositivo sensor propiamente dicho, encargadode detectar la señal a medir y convertirla en una señal eléctrica.
El procesamiento analógico de la señal del transductor, conocido como sig-nal path, que consiste como mínimo en una primera etapa amplificadora yun conversor analógico-digital (ADC).
El amplificador de salida, que sólo está presente en los chips que tienensalida analógica. En los que poseen salida digital esta etapa es simplementeun buffer que asegura un nivel de señal de salida adecuado.
La interfaz de entradas y salidas, que posee los contactos donde se sueldanlos conectores metálicos del encapsulado y los circuitos protectores frente adescargas electrostáticas. Este bloque incluye también los buffers que permi-ten, entre otras cosas, entregar el nivel de corriente adecuado a las salidas,ofrecer un estado de alta impedancia o utilizar un mismo pin como entraday salida.
El sistema de alimentación, que incluye reguladores de tensión para propor-cionar las alimentaciones necesarias a cada parte del circuito, referencias detensión y corriente y, en muchos casos, circuitos de protección por baja oalta tensión de alimentación.
Las celdas de memoria no volátil y su controlador, que es el encargado deescribir, leer y borrar cada una de las celdas.
4 Capítulo 1. Introducción General
El sistema digital adquiere cada vez más importancia: se encarga de la comunica-ción con el mundo exterior, los accesos a la memoria, la configuración del dispo-sitivo, el monitoreo de ciertas variables internas e incluso del procesamiento dela señal. Es desarrollado mediante lenguajes de descripción de hardware (HDLs)y está compuesto al menos por los siguientes bloques:
Procesamiento digital: recibe la señal proveniente del ADC, realiza el pro-cesamiento necesario y genera el formato de salida deseado.
Interfaz serie: se encarga de la comunicación con el mundo exterior; los pro-tocolos más utilizados son Manchester, SPI e I2C, los cuales serán explica-dos en la sección 2.2.
Control de la memoria: atiende los pedidos de lectura y escritura a la me-moria provenientes del exterior o del interior del mismo chip.
Control general: engloba distintos algoritmos particulares de cada CI; susfunciones pueden ser muy variadas, como realizar ajustes en los circuitosanalógicos, generar señales de sincronización o establecer secuencias de en-cendido y apagado.
Por medio de la interfaz serie es posible acceder a los registros de memoria de losCI. Estos son utilizados para diversos fines: hay registros de configuración, regis-tros de ajuste, registros de monitoreo, registros de prueba y registros de salida,por nombrar los más usuales. Algunos registros se encuentran protegidos y losclientes no tienen acceso a ellos.
Los registros de configuración se utilizan para modificar parámetros funcionalesdel CI y le permiten al cliente configurar el chip según la necesidad de su apli-cación. Los registros de ajuste están protegidos para que acceda únicamente elfabricante y se utilizan para compensar dispersiones del proceso de fabricación.
Por su parte, los registros de monitoreo se emplean para detectar fallas en el siste-ma; los CI cuentan con una gran cantidad de monitores que reportan el estado dedistintas variables del sistema y generan un alerta en caso de error. Los registrosde pruebas, por su parte, se utilizan únicamente durante el ciclo de desarrollo delos CI; permiten a los diseñadores realizar ensayos sobre el chip para verificar sufuncionamiento.
Por último, los registros de salida almacenan el valor de las señales de salidaspara que éstas puedan ser consultadas a través del puerto serie.
1.1.3. Ensayos realizados en el país
En Argentina se llevan a cabo una gran variedad de pruebas sobre los CI. Es-tas se realizan durante el ciclo de desarrollo a fin de verificar los requerimientosfuncionales y las especificaciones indicadas en la hoja de datos (tensiones de tra-bajo, protecciones frente a eventos electrostáticos, consumo de corriente, etc.). Laspruebas pueden dividirse en dos etapas: pruebas sobre la oblea de silicio y prue-bas sobre el chip ya encapsulado.
Las pruebas sobre la oblea de silicio se realizan utilizando un equipo llamadomicro prober, como el que se muestra en la figura 1.4. Un micro prober es un dispo-sitivo de alta precisión que cuenta con un microscopio y una serie de agujas, que
1.1. Circuitos integrados en Allegro Microsystems 5
permiten hacer contacto con los pads de prueba del CI. De esta forma es posibleinyectar y medir señales eléctricas en distintas partes del circuito.
(A) micro prober utilizado para pruebas sobresilicio 3.
(B) Detalle de las agujas de un micro probercontactando una oblea de silicio 4.
FIGURA 1.4: Micro prober utilizado para mediciones sobre silicio.
Una vez encapsulado el silicio, los pads de prueba dejan de ser accesibles, por loque todas las pruebas se realizan a través de los pines de entradas y salidas delchip. Por tal motivo, se fabrican circuitos impresos como el que se muestra en lafigura 1.5. Estos poseen un zócalo compatible con el tipo de encapsulado del chip,que permite que sea conectado sin necesidad de soldarlo.
FIGURA 1.5: Circuito impreso para ensayos en encapsulados - 1.Conector universal - 2. Zócalo de conexión - 3. CI bajo prueba.
3https://www.formfactor.com/products/probe-systems/?_probe_systems=150mm4https://www.ecplaza.net/products/se40-micropositioner-positioner-probe-tip-positioner_
4205438
6 Capítulo 1. Introducción General
Por otro lado, las mediciones pueden ser clasificadas en analógicas y digitales.
Algunos ejemplos de ensayos analógicos son:
Caracterización de cada etapa del signal path
Verificación de las especificaciones eléctricas detalladas en la hoja de datos
Respuesta de los reguladores de tensión frente a variaciones en la carga
Caracterización de la salida del chip, medición de rango y error
Pruebas relacionadas con funciones de seguridad (ensayo de monitores)
Mientras que ejemplos de ensayos digitales son:
Ensayo de canales de comunicación
Prueba del funcionamiento de la memoria para lectura y escritura
Funcionamiento del ajuste de parámetros
Caracterización de cada etapa del signal path digital
Pruebas relacionadas con funciones de seguridad (ensayo de monitores)
Para llevar adelante estos ensayos, se utiliza una gran variedad de instrumen-tos: micro probers, osciloscopios, voltímetros, frecuencímetros, amperímetros, pormencionar algunos. Pero hay un dispositivo que es de principal interés para estetrabajo: un kit de pruebas desarrollado por la empresa, llamado ASEK. El sistemaASEK es similar al dispositivo desarrollado en este trabajo, sin embargo, poseealgunas limitaciones que se encuentran detalladas en la sección 1.2.
1.2. Análisis del sistema preexistente
El sistema ASEK fue diseñado en la empresa con el fin de crear una plataformaque permitiese la comunicación con los CI bajo prueba (desde ahora DUT, deviceunder test) utilizando cualquiera de los protocolos serie implementados en loschips de Allegro hasta el momento. Su nombre proviene de las siglas en inglésAllegro Sensor Evaluation Kit y es empleado no sólo por personal de la empresasino también por clientes que necesitan modificar la configuración de los CI orealizar ensayos en el entorno de su aplicación. Las figuras 1.6 y 1.7 muestran lasvistas interior y exterior del ASEK.
El ASEK está implementado sobre una FPGA Spartan-III de la marca Xilinx, quecontiene la lógica necesaria para los protocolos de comunicación con los CI y unmódulo UART para interactuar con una computadora. Ésta es la encargada de co-rrer el programa de cada prueba, comunicarse con los instrumentos de medicióny enviar al ASEK los comandos que luego este transmitirá al DUT.
Inicialmente, los protocolos de comunicación implementados eran SPI, I2C y unprotocolo conocido en la empresa como Serial Programming, que utiliza pulsos dedistintos valores por encima de la tensión de alimentación para formar la trama.Sin embargo, Serial Programming esta siendo discontinuado y reemplazado por elprotocolo Manchester. Por este motivo hace algunos años el firmware y la lógicaprogramable del ASEK fueron adaptadas para implementar Manchester, aunqueel hardware no se modificó y los circuitos necesarios se agregaron en placas ex-ternas.
1.3. Motivación 7
FIGURA 1.6:Sistema ASEK -Vista exterior
FIGURA 1.7:Sistema ASEK -Vista interior
Hoy en día, la principal falencia del ASEK radica en la velocidad de transmisión.A pesar de que los módulos implementados en lógica programable admiten co-municaciones a altas frecuencias, la latencia que agrega la comunicación con lacomputadora hace que el tiempo entre dos paquetes sea mucho mayor al tiem-po mismo de la trama y además, hace que ese tiempo no sea determinístico. Lafigura 1.8 muestra el tiempo entre paquetes para una comunicación SPI a 2 MHz.
(A) Latencia entre dos paquetes consecutivos.
(B) Duración de cada paquete.
FIGURA 1.8: Latencia en la comunicación SPI a 2 MHz utilizandoASEK.
1.3. Motivación
El ASEK20 ha demostrado ser durante años un dispositivo confiable; si bien conalgunas limitaciones conocidas, fueron pocas las ocasiones en las que represen-taron un impedimento para realizar la verificación de los CI en la empresa. Peroaño a año la tecnología avanza, los circuitos integrados se vuelven cada vez máscomplejos y se hacen indispensables sistemas más eficientes para realizar todoslos ensayos pertinentes.
8 Capítulo 1. Introducción General
Los circuitos digitales están ganando terreno frente a los analógicos, aumentandoen tamaño, velocidad y en número de registros a monitorear. Por lo tanto, es fun-damental contar con un sistema que permita adquirir el valor de dichos registrosde una forma rápida y eficiente a fin de lograr una correcta reconstrucción de laseñal.
Por otro lado, es necesario un sistema de pruebas que pueda adaptarse fácilmentea los cambios en la tecnología de los CI, es decir que sea versátil, con software yhardware programable en lenguajes conocidos por el personal del laboratorio.
Los argumentos anteriormente mencionados motivaron la realización de este tra-bajo final.
1.4. Objetivos y alcance
El propósito de este trabajo final de la CESE fue desarrollar una plataforma so-bre la cual se puedan realizar distintos tipos de pruebas en forma automática,rápida y eficiente sobre los diversos tipos de circuitos integrados fabricados en laempresa.
En cuanto al alcance del trabajo, este incluyó:
El desarrollo de la lógica programable necesaria para implementar los dis-tintos protocolos de comunicación.
La implementación de un hardcore5 sobre el que fue posible embeber unsistema operativo Linux.
El desarrollo del software y firmware necesario para lograr la interacciónentre las aplicaciones del sistema operativo y la lógica programable.
Las pruebas de integración que permitieron validar el funcionamiento delsistema.
El presente trabajo no incluyó:
El desarrollo de una interfaz de usuario; el sistema es controlado por líneade comando.
5Un hardcore es un procesador configurable implementado sobre hardware dedicado. Se utilizaeste término para diferenciarlo de un softcore, que es un procesador implementado sobre lógicaconfigurable.
9
Capítulo 2
Introducción Específica
En este capítulo se hace referencia a las tecnologías utilizadas para el desarrollodel trabajo. Se introduce el concepto de sistema en chip, plataforma sobre la cualserá implementado el sistema, y de interfaz AXI. Por otro lado, se describe cadauno de los protocolos mediante los cuales se establecerá la comunicación con losCI. Finalmente se detallan los requerimientos y la planificación del trabajo.
2.1. Sistema en chip (SoC)
El término sistema en chip (SoC) describe la tendencia, cada vez más frecuente,de usar tecnologías de fabricación que integran en una misma pastilla de siliciotodos los módulos que componen un sistema electrónico. En particular para esteproyecto son de interés los SoC que integran en un mismo chip un sistema deprocesamiento (PS) y lógica programable (PL). El resultado de esta combinaciónes un sistema de alto rendimiento que sigue la filosofía "todo programable", esdecir, software y hardware configurables por el programador. Esto brinda unagran flexibilidad y permite la rápida implementación de sistemas complejos.
El sistema de procesamiento consiste en un micro-controlador de hardware confi-gurable, también conocido como hardcore. Está compuesto por un núcleo de pro-cesamiento, memoria caché, controladores de memoria externa y periféricos deentrada/salida. La lógica programable se encuentra fuertemente integrada; esutilizada para extender la funcionalidad del PS y brindar mayor capacidad y ve-locidad de procesamiento.
La arquitectura de un SoC conecta de manera óptima la lógica programable yel software del micro-controlador. Esta integración proporciona niveles de rendi-miento que las soluciones de dos chips (por ejemplo, un micro-controlador conuna FPGA) no pueden alcanzar debido al limitado ancho de banda de sus entra-das/salidas y a los problemas que conlleva el acoplamiento de ambos a nivel delcircuito impreso.
Para este proyecto se decidió utilizar la placa de desarrollo ZedBoard [1]. Estacontiene un SoC XC7Z020 de la familia Zynq-7000 [2], fabricado por la empre-sa Xilinx [3]. La decisión de utilizar un SoC de esta empresa se debe al soportedado por la Carrera sobre sus herramientas de diseño. La elección de la placaZedboard fue tomada debido a su disponibilidad en el laboratorio de Allegro Mi-crosystems, aunque su especificación superara los requisitos mínimos para estetrabajo y podría haberse utilizado una placa más económica de la misma familia.
10 Capítulo 2. Introducción Específica
La figura 2.1 muestra un diagrama de la arquitectura de la familia SoC Zynq-7000.En él pueden observarse claramente diferenciados los componentes del PS y dela PL.
FIGURA 2.1: Arquitectura de la familia Zynq-7000-SoC 1.
La comunicación entre el PS y la PL se realiza a través de una interfaz AMBA-AXI4, un protocolo estándar creado por ARM que se encuentra detallado en lasección 2.1.1.
Las características más destacables que ofrece el PS de este dispositivo son:
Procesador doble núcleo ARM Cortex-A9 con una frecuencia de trabajo dehasta 866 MHz
Cache L1: 32 KB para instrucciones más 32 KB para datos por procesador
Cache L2: 512 KB
1https://www.xilinx.com/products/silicon-devices/soc/zynq-7000.html
2.1. Sistema en chip (SoC) 11
Memoria: 256 KB en el SoC más 512 MB en una DDR3 externa
8 canales DMA
Periféricos: 2x UARTs, 2x CAN 2.0, 2x I2C, 2x SPI, 4x 32b GPIO
Por otro lado, el SoC XC7z020 tiene lógica programable equivalente a un Artix-7.Algunas de sus características son:
85.000 celdas lógicas
53.200 Look-Up-Tables
106.400 Flip-flops
4.9 MB de RAM
2.1.1. Interfaz AXI4
ARM Advanced Microcontroller Bus Architecture (AMBA) es un estándar abierto deinterconexión para circuitos integrados. Es utilizado para la conexión y gestión debloques funcionales en diseños sobre SoCs. Facilita el desarrollo de sistemas mul-tiprocesador con un gran número de controladores, componentes y periféricos.AMBA fue presentado por ARM en 1996, los primeros buses fueron ASB, Advan-ced System Bus, y APB, Advanced Peripheral Bus. En el año 2010 ARM presentó laversión 4.0 de AMBA llamada AXI4 [4], por las siglas en inglés Advance ExtensibleInterface. Esta versión de AMBA es la que se encuentra implementada en el SoCutilizado para este trabajo.
AXI4 es una interfaz paralela de alto rendimiento, sincrónica, multi-maestro ymulti-esclavo. Puede trabajar a altas frecuencias, del orden de los cientos de MHz.Comprende tres tipos de interfaces distintas que son presentadas en la tabla 2.1.
TABLA 2.1: Tipos de interfaces AXI4.
Interfaz Características Aplicación
AXI-Full Dirección y datos Control de módulosAncho de dato configurable (1024b max) Transferencia deModo ráfaga (256 paquetes máx) datos múltiple
AXI-Lite Dirección y datos Control de módulosAncho de dato fijo 32 bits Transferencia deModo ráfaga no soportado datos simple
AXI-Stream Solo dato, sin dirección Transferencia deAncho de dato ilimitado datos masivaModo ráfaga ilimitado
Las interfaces AXI-Full y AXI-Lite poseen cinco canales de transmisión indepen-dientes, que pueden observarse en la figura 2.2. Dos de estos canales son utiliza-dos para realizar la operación de lectura y tres para la operación de escritura:
Canal de dirección de lectura
Canal de dato de lectura
Canal de dirección de escritura
12 Capítulo 2. Introducción Específica
Canal de dato de escritura
Canal de respuesta de escritura
Maestro
Direccióny control
Datoleído
Datoleído
Datoleído
Datoleído
Esclavo
Canal de dirección de lectura
Canal de datos de lectura
Maestro
Direccióny control
Datoleído
Datoleído
Datoleído
Datoleído Esclavo
Canal de dirección de escritura
Canal de datos de escritura
Respuesta
Canal de respuesta
FIGURA 2.2: Canales de las interfaces AXI-Full y AXI-Lite.
La interfaz Axi-Stream, por su parte, contiene solo un canal de datos que va des-de el maestro hacia el esclavo. La dirección de destino es fija, sin embargo, paratransmisiones múltiples (en modo ráfaga) puede incrementarse con la llegada decada paquete.
Las transacciones siempre son iniciadas por el dispositivo maestro. Cada canalindependiente se compone de varias señales. Las más importantes a destacar sonlas señales VALID y READY, que son utilizadas para coordinar la transacción enambos sentidos. El dispositivo de origen de la información a transmitir (ya seadirección, dato o señal de control) usa la señal VALID para indicar que la infor-mación está disponible para ser transmitida. El dispositivo de destino usa la señalREADY para informar si se encuentra disponible para recibir la información. Elsentido de las flechas en la figura 2.2 indica para cada canal cuál dispositivo es elde origen y cuál el destino.
La implementación de AXI4 realizada por Xilinx posee algunas restricciones quepueden encontrarse en la bibliografía proporcionada por el fabricante [5]. Sin em-bargo, Xilinx ofrece distintas herramientas que facilitan el proceso de diseño. Unejemplo de esto es un módulo de interconexión llamado AXI Interconnect CoreIP. Este bloque permite conectar múltiples dispositivos maestros y esclavos, re-suelve la decodificación de las direcciones, y se asegura así que los datos lleguenúnicamente al destino correcto, e incluso, hace posible la conexión entre bloquesde distintos anchos de datos, frecuencias y versiones del protocolo (por ejemplo,
2.2. Protocolos de comunicación 13
permite conectar módulos AXI3 con módulos AXI4). Un diagrama de bloques deeste módulo se muestra en la figura 2.3.
FIGURA 2.3: Módulo de interconexión para AXI4 propiedad inte-lectual de Xilinx2.
2.2. Protocolos de comunicación
En esta sección se realiza una breve explicación de los tres protocolos más utiliza-dos en los chips de Allegro Microsystems: SPI, I2C y Manchester.
2.2.1. SPI
El protocolo SPI (del inglés Serial Peripheral Interface) es un estándar de comu-nicación serie y sincrónico. Está pensado para ser utilizado principalmente encomunicaciones entre distintos circuitos integrados ubicados en el mismo circui-to impreso. La comunicación se realiza en modo full-duplex, bajo una arquitecturade maestro único y esclavos múltiples. El protocolo utiliza al menos cuatro líneas:una línea de reloj (SCLK), una de dato saliente del maestro (MOSI), una de datoentrante al maestro (MISO) y al menos una línea de selección de esclavo (CS).
Las líneas SCLK, CS y MOSI son controladas por el dispositivo maestro, mientrasque la señal MISO es controlada por el esclavo. Para iniciar una transacción elmaestro debe poner en estado bajo la señal de CS correspondiente al esclavo conel que se quiere comunicar. Luego debe enviar las señales de SCLK y MOSI. Elesclavo por su parte responde con la señal MISO de forma sincrónica con SCLK.Es necesario tener en cuenta que la respuesta del esclavo es del tipo out-of-frame,esto significa que, en caso de ejecutar una operación de lectura, la respuesta nollegará en la misma trama en la que se envía el comando sino que lo hará en lasiguiente. Cuando finaliza el envío de la trama, el maestro debe poner la señal CS
2https://www.xilinx.com/support/documentation/ip_documentation/ug761_axi_reference_guide.pdf
14 Capítulo 2. Introducción Específica
en estado alto nuevamente. La secuencia descrita puede observarse en la figura2.4.
FIGURA 2.4: Señales del protocolo SPI.
En Allegro Microsystems se utilizan hasta el momento dos tipos de trama SPIdistintos: una estándar, con 20 bits de datos; y una versión desarrollada reciente-mente para chips que requieren un grado de seguridad ASIL-D [6], con 32 bits dedatos. La tabla 2.2 muestra las diferencias entre ambas. Las tramas incluyen bitsdedicados a la detección de errores. El método utilizado es el de verificación porredundancia cíclica (CRC).
TABLA 2.2: Diferencias entre SPI y SPI-ASIL-D.
Campo Trama estándar Trama ASIL-D
Bits de sincronización 1 1Bits de operación 1 1Bits de dirección 6 5Bits de datos 8 16Bits de CRC 4 5Polinomio CRC g(x) = x4 + x+ 1 g(x) = x5 + x2 + 1
En la figura 2.5 se muestra la descripción bit a bit de cada trama. Los camposmarcados como DC en la figura 2.5b son bits reservados, el valor enviado notiene importancia, mientras que los campos MSG_ID, CNT, S1 y S0 son utilizadospara señalizar distintos tipos de errores internos del chip.
(A) Trama SPI estándar de 20 bits.
(B) Trama SPI para ASIL-D de 32 bits.
FIGURA 2.5: Tramas del protocolo SPI versión estándar y ASIL-D.
2.2.2. I2C
I2C es un protocolo half-duplex de dos líneas, una de reloj (SCL), generada siemprepor el dispositivo maestro, y una de datos (SDA), que puede ser generada por eldispositivo maestro o por el esclavo. Un dispositivo esclavo solo responderá a uncomando cuando este posea la dirección (slave address) correspondiente, de otromodo el mensaje será ignorado.
Cada transacción debe comenzar con una condición de INCIO y terminar con unacondición de FIN. La condición de INICIO consta de una transición de SDA del
2.2. Protocolos de comunicación 15
estado alto al estado bajo, con SCL en alto; mientras que la condición de FIN con-siste en una transición de SDA del estado bajo al estado alto, con SCL también enalto. En la figura 2.6 pueden observarse ambas secuencias. Después de detectadauna condición de inicio, la línea se considerará ocupada, por lo cual no podrá serutilizada por otro dispositivo maestro hasta que no se detecte una condición defin.
SCL
SDA
CondiciónINICIO
CondiciónFIN
FIGURA 2.6: I2C: condiciones de INICIO y FIN.
Para asegurar una correcta transmisión de datos, la señal SDA debe estar esta-ble cuando SCL se encuentre en estado alto, podrá cambiar cuando SCL está enestado bajo.
Cada comando se divide en paquetes de 8 bits, de los cuales el primero es el mássignificativo. No existe un límite para la cantidad de paquetes a transferir. Lue-go de cada byte, debe recibirse una señal de confirmación llamada acknowledge(ACK), en caso de ser correctamente recibido, o non-ackonwledge (NACK), en casode que la recepción sea incorrecta. Cuando se espera una respuesta del disposi-tivo esclavo, el maestro debe liberar el canal SDA y llevarlo a un estado de altaimpedancia.
En la figura 2.7 se puede observar un ejemplo de comando de escritura de 32 bits.Luego de la condición de inicio se envía un byte con la dirección del dispositivoesclavo y el tipo de comando (′0′ para escritura). En un segundo byte, se envía ladirección de registro a la cual se quiere acceder. Por último, se envían los 4 bytesde datos. Observar que entre cada byte enviado, es necesario que el maestro liberela línea para que el esclavo pueda responder con la señal de ACK/NACK.
SDA
INICIO FIN
Direcciónesclavo
[6:0]
E ACK ACK ACK ACKDirecciónregistro[7:0]
Datos_3[7:0]
Datos_2[7:0]
Datos_1[7:0]
ACK Datos_0[7:0]
Byte enviado por el maestro ACK enviado por el esclavo
ACK
FIGURA 2.7: I2C: comando de escritura de 32 bits.
De manera similar, en la figura 2.8 se observa una operación de lectura de 32 bits.Luego de la condición de inicio se envían primero la dirección del esclavo y elcomando de operación de escritura y en el siguiente byte el registro a leer. Luegodel ACK se debe repetir la condición de inicio y volver a enviar la dirección delesclavo, pero esta vez con el bit de operación en alto, es decir, en modo lectu-ra. Luego el maestro debe liberar la línea SDA para comenzar a recibir los bytesleídos, y responder con ACK/NACK entre cada uno de ellos.
16 Capítulo 2. Introducción Específica
SDA
INICIO FIN
Direcciónesclavo[6:0]
E ACK ACK ACK ACK ACKDirecciónregistro[7:0]
Datos_3[7:0]
Datos_2[7:0]
Datos_1[7:0]
ACK Datos_0[7:0]
Byte/ACK enviado por el maestro Byte/ACK enviado por el esclavo
Direcciónesclavo[6:0]
L ACK
INICIO
FIGURA 2.8: I2C: comando de lectura de 32 bits.
2.2.3. Manchester
Manchester es un protocolo serie que provee una interfaz de comunicación bi-direccional del tipo half-duplex. Utiliza un solo hilo de comunicación entre undispositivo maestro y uno esclavo. Un ’0’ lógico es representado con un flancoascendente, y un ’1’ con un flanco descendente. La duración de cada bit es llama-da Tbit. La codificación a nivel de bit del protocolo Manchester se puede observaren la figura 2.9.
Tbit
0 0 0
Tbit Tbit Tbit Tbit
1 1
FIGURA 2.9: Codificación del protocolo Manchester: los ′0′ son re-presentados con flancos ascendentes y los ′1′ con flancos descen-
dentes.
El protocolo Manchester permite operaciones de escritura y lectura. Su trama seencuentra representada en la figura 2.10. La comunicación siempre debe ser ini-ciada por el dispositivo maestro. Cada comando está compuesto por: dos bits desincronización (“00”), seguido por un bit de comando ′1′ para lectura y ′0′ paraescritura, la dirección del dispositivo esclavo, la del registro, los bits de datos y3 bits de CRC. Los bits de sincronización se utilizan para que el esclavo puedadetectar el valor de Tbit.
Los 3 bits de CRC se calculan utilizando el polinomio g(x) = x3 + x + 1, inicia-lizado con ”3′b111”. Los bits de sincronización son ignorados para el cálculo delCRC. Si se detecta un error de CRC, el paquete es descartado.
2.2. Protocolos de comunicación 17
A3 . . . . . . C2 C1 C0D31 D30 D0R5 R4 R0A2 A1 A0
Tbit
0 0 0
Dirección deesclavo
Dirección deregistro 32 bits de dato CRCSinc E
(A) Comando de escritura enviado por el dispositivo maestro.
A3 . . . C2 C1 C0R5 R4 R0A2 A1 A0
Tbit
0 0 1
Dirección deesclavo
Dirección deregistro
CRCSinc L
(B) Comando de lectura enviado por el dispositivo maestro.
. . . C2 C1 C0D31 D30 D0
Tbit
0 0
32 bits de dato CRCSinc
(C) Respuesta al comando de lectura enviado por el dispositivo esclavo.
FIGURA 2.10: Comandos del protocolo Manchester: escritura, lec-tura y respuesta.
18 Capítulo 2. Introducción Específica
2.3. Requerimientos
En esta sección se listan los requerimientos funcionales planteados al inicio delproyecto [7] y las modificaciones realizadas a lo largo de su desarrollo.
2.3.1. Requerimientos generales
REQ#1.1: El dispositivo debe funcionar como un sistema stand-alone.
REQ#1.2: El sistema debe desarrollarse sobre una placa Zedboard - Zynq-7000 de Digilent.
REQ#1.3: Sobre esta placa debe implementarse un hardcore con Linux embe-bido.
REQ#1.4: La versión de Linux utilizada debe ser compatible con Python 3.
REQ#1.5: Debe ser posible comunicarse con el sistema utilizando SSH.
REQ#1.6: [opcional] La conexión a la red debe ser por medio de WiFi.
2.3.2. Requerimientos de las pruebas
REQ#2.1: El código de las pruebas debe poder ser desarrollado en lenguajePython.
REQ#2.2: Los resultados de cada test deben ser almacenados en la tarjetade memoria SD del kit de desarrollo y deben poder ser extraídos con elcomando scp.
REQ#2.3: Debe desarrollarse a modo de ejemplo una prueba para la carac-terización del DAC de salida del chip 330301BA.
REQ#2.4: Debe desarrollarse a modo de ejemplo una prueba que realice untest de Scan Vector sobre el chip 330301BA.
2.3.3. Requerimientos para el manejo de instrumentos de medición
REQ#3.1: Los instrumentos de medición deben conectarse al sistema porUSB, utilizando un conversor GPIB/USB.
REQ#3.2: El sistema debe contemplar la posibilidad de que se conecten has-ta 10 instrumentos a la vez.
2.3.4. Requerimientos para la comunicación con el DUT
REQ#4.1: La comunicación con el DUT debe poder realizarse utilizandocualquiera de los siguientes protocolos: Manchester (G.E. Thomas), I2C ySPI.
REQ#4.2: Las operaciones de lectura y escritura sobre el DUT deben poderrealizarse en modo burst y single frame.
REQ#4.3: Los drivers para cada protocolo deben ser desarrollados sobre lalógica programable de la placa para asegurar mayores velocidades.
REQ#4.4: La conexión entre estos módulos y el micro-controlador debe ha-cerse a través del bus AMBA.
2.4. Planificación 19
REQ#4.5: Los datos provenientes de cada módulo de comunicación con elDUT serán manejados por el micro-controlador a través de DMA.
REQ#4.6: La velocidad de comunicación del módulo Manchester debe serconfigurable por software hasta un máximo de 1 MHz.
REQ#4.7: La velocidad de comunicación del módulo I2C debe ser configu-rable por software para trabajar en los modos: Standard Mode (100 kbps),Fast Mode (400 kbps) y Fast Mode Plus (1 Mbps).
REQ#4.8: La velocidad de comunicación del módulo SPI debe ser configu-rable por software hasta un máximo de 10 MHz.
2.3.5. Requerimientos de hardware
REQ#5.1: El sistema debe contar con cuatro módulos DAC externos paramanejar la tensión de alimentación del DUT y todo otro nivel de tensiónque sea necesario configurar.
REQ#5.2: La tensión de salida del DAC debe llegar hasta 20 V.
2.3.6. Modificaciones realizadas durante el desarrollo
Los requerimientos relacionados con el manejo de los instrumentos de mediciónfueron dados de baja durante el desarrollo del trabajo. La decisión se debió ala imposibilidad de configurar el driver GPIB dentro del plazo previsto para elproyecto y fue informada a todas las partes interesadas. Estos requerimientosfueron agregados en la sección de trabajo futuro.
2.4. Planificación
Al inicio del proyecto se confeccionó el diagrama de actividad (AON, diagramade Activity-On-Node) y el diagrama de Gantt, que se ilustran en las figuras 2.11 y2.12, respectivamente.
Inicialmente se estimó un total de 606 horas para la realización del trabajo, y secalculó como fecha de finalización el 20 de Diciembre de 2019. Sin embargo, estaplanificación no pudo ser cumplida por varias razones que se enumeran a conti-nuación.
En primer lugar, no siempre fue posible dedicar las 20 hs semanales necesariaspara terminar en la fecha pactada. En segundo lugar, el tiempo necesario para eldesarrollo del hardware no fue tenido en cuenta en la planificación inicial. Esteerror no hubiera sido tan grave ya que se esperaba que la complejidad del circuitoimpreso fuese relativamente baja. Sin embargo, durante el avance del proyecto losrequerimientos del hardware crecieron, lo que demandó alrededor de 80 horasextra de trabajo. Por último, la falta de experiencia en algunas tareas provocó queel tiempo estimado para realizarlas no fuera suficiente.
20 Capítulo 2. Introducción Específica
FIGURA 2.11: Diagrama de activity-on-node.
2.4. Planificación 21
(A) Diagrama de Gantt primera parte.
(B) Diagrama de Gantt segunda parte.
FIGURA 2.12: Diagrama de Gantt.
23
Capítulo 3
Diseño e Implementación
En este capítulo se detalla el proceso de diseño de cada una de las partes quecomponen este trabajo: la lógica programable, el hardcore, el sistema operativo,los drivers desarrollados y el hardware.
3.1. Arquitectura del sistema desarrollado
En base a los requerimientos se diseñó un prototipo utilizando el SoC XC7Z020de la familia Zynq-7000. La figura 3.1 muestra la arquitectura del sistema desa-rrollado. En esta sección se realiza una breve descripción de cada uno de suscomponentes. Los distintos módulos son explicados en mayor profundidad enlas secciones sucesivas de este capítulo.
uC CORE
ARM cortex A9
Inte
rfaz
AM
BA
Inte
rfaz
AM
BAEthe
rnet
UA
RT
GP AXI HP AXI
SPI SPIASILD I2C ManchGPIO DMA
Hardware externo
DUTVCC GNDPuerto serie
PL
PS
PCR
ED
Con
trol
ador
Mem
oria
SD
Con
trol
ador
Mem
oria
DD
R
Tarje
ta S
DD
DR
Sistema en chip
FIGURA 3.1: Arquitectura del sistema desarrollado
El sistema de procesamiento (PS) contiene el hardcore, sobre el que está embebidoel sistema operativo Linux, y los periféricos necesarios:
El módulo UART para la comunicación USB con la computadora.
24 Capítulo 3. Diseño e Implementación
El periférico ETHERNET para la conexión a la red.
El controlador de la memoria DDR SDRAM.
El controlador para la memoria en la tarjeta SD.
Los puertos para la lógica programable GP (propósito general) y HP (altorendimiento).
El hardware para los puertos ETHERNET y UART, la memoria DDR y el circuitoasociado a la tarjeta SD se encuentran implementados en la placa de desarrolloZedboard y escapan al alcance de este trabajo.
La conexión entre PS y PL se realiza por medio de los puertos GP-AXI y HP-AXI. El módulo GP-AXI, de las siglas en inglés General Purpose, se utiliza para lasinterfaces AXI4-Full y AXI-Lite. Por su parte, el módulo HP-AXI, High Performan-ce, se emplea para las interfaces AXI-Stream. Los puertos pueden ser maestros oesclavos, según sea su función.
Los módulos para los protocolos SPI, I2C y Manchester están implementados so-bre la lógica programable. Cada protocolo tiene asociado un módulo DMA, me-diante el que se realiza la escritura a memoria de los datos recibidos.
3.1.1. Flujo de diseño
Con el fin de asegurar la verificación de cada paso en el desarrollo del trabajo, seutilizó el siguiente flujo de diseño:
1. Diseño de los módulos SPI, I2C y Manchester en HDL (sección 3.2.1).
2. Pruebas unitarias para cada módulo: diseño del banco de pruebas y simu-lación en ModelSim (sección 4.1).
3. Desarrollo de la interfaz AXI4 para cada módulo (sección 3.2.1).
4. Simulación de cada interfaz AXI4 con el software Vivado (sección 4.1).
5. Diseño del PS y armado del sistema en Vivado (sección 3.1.2).
6. Desarrollo de una prueba baremetal para verificar la interacción entre PS yPL (sección 4.2.1).
7. Integración del sistema operativo Linux (sección 3.4).
8. Desarrollo de los drivers para la PL (sección 3.4.7).
9. Pruebas de integración (sección 4.2).
3.1.2. Diseño del sistema en chip
Utilizando el entorno de desarrollo del software Vivado, se realizó el diseño enbloques del sistema que se observa en la figura 3.2. El bloque con el nombreZYNQ representa al PS; los detalles sobre su configuración se encuentran en lasección 3.3. El resto de los bloques pertenecen a la PL y son explicados en la sec-ción 3.2.
3.2. Lógica programable 25
FIGURA 3.2: Diagrama en bloques del sistema diseñado con Viva-do.
3.2. Lógica programable
Un diagrama simplificado de la PL puede verse en la figura 3.3. Es principalmen-te utilizada para implementar los módulos de comunicación con los CI. Estosreciben del PS la información necesaria para iniciar las transacciones por mediode una interfaz AXI-Full. Cuando se realiza una operación de lectura, la tramarecibida es enviada por AXI-Stream a un bloque DMA; una vez completada laoperación, este envía una señal de interrupción al PS. La configuración de losmódulos DMA se realiza desde la PS utilizando un canal AXI-Lite.
ZYNQPS
HP slaveGP master
DMA_0 DMA_1 DMA_2 DMA_3
SPI SPI ASIL-D I2C MANCH
AXIinterconnect
Dato Rx Dato Rx Dato Rx Dato Rx
AXI-Stream
AXI-Lite
AXI-Full
E/S al DUT E/S al DUT E/S al DUT E/S al DUT
x4
x4
SPIDACGPIO
x1
x1
InterrupcionesDMA
FIGURA 3.3: Diagrama simplificado de la PL.
Otras funciones implementadas en la PL son:
Un bloque de SPI para el manejo del DAC ubicado en el hardware externo.
26 Capítulo 3. Diseño e Implementación
Un módulo GPIO con 8 salidas para realizar ajustes en la placa utilizadapara los ensayos 1.1.3.
3.2.1. Módulos para los protocolos de comunicación
Cada módulo está compuesto por un bloque central, específico del protocolo, unainterfaz AXI_Ctrl (AXI-Full) y una interfaz AXIS_Data (AXI-Stream), como mues-tra la figura 3.4.
Módulo delprotocolo
AXI_
Ctrl
AXIS
_Dat
a
rx_dataPS DMA
DUT
enablespeed_seltx_data
tx_reg_addrrnw_opbusyerror
stream_startstream_lenstream_busy
FIGURA 3.4: Interfaz AXI para los módulos de comunicación conel DUT.
Los bloques centrales contienen los algoritmos específicos de cada protocolo paraenviar y recibir la información a los DUTs. Aunque internamente son muy distin-tos entre sí, todos comparten un conjunto de entradas y salidas que hacen posibleabstraerse del protocolo y usar las mismas interfaces AXI para todos ellos. Latabla 3.1 describe cada una de estas señales. El resto de los puertos son propiosde cada protocolo y se conectan directamente a pines externos del sistema; seencuentran detallados en la tabla 3.2.
TABLA 3.1: Entradas y salidas estándar para todos los protocolos.
Nombre E/S Ancho Descripción
clk E 1 Reloj del sistema.rst_n E 1 Reset sincrónico activo en bajo.
enable E 1 Señal de habilitación, inicia la transferencia.speed_sel E 8 Configuración de la velocidad de transmisión.
tx_data E 32 Palabra de datos a enviar al DUT.tx_reg_addr E 8 Dirección del registro del DUT de destino.
rnw_op E 1 Operación: ′0′ para lectura, ′1′ para escritura.rx_data S 32 Palabra de datos recibidos del DUT.
busy S 1 Indica si hay una transferencia en curso.error S 1 Indica si se produjo algún error.
3.2. Lógica programable 27
TABLA 3.2: Entradas y salidas propias de cada protocolo.
Protocolo Nombre E/S Ancho Descripción
SPI SCLK S 1 Reloj de la comunicación SPI.SPI CS S 1 Señal de habilitación de esclavo.SPI MOSI S 1 Salida del maestro,
1 entrada al esclavo.SPI MISO E 1 Entrada al maestro,
1 salida del esclavo.
I2C SCL S 1 Reloj de la comunicación I2C.I2C SDA E/S 1 Señal de datos bidireccional.
Manch sdata_in E 1 Entrada serie de datos.Manch sdata_out S 1 Salida serie de datos.Manch sdata_out_en S 1 Habilita el buffer de salida.
El bloque AXI_Ctrl posee tres registros internos de 32 bits cada uno. Medianteellos, se realiza la configuración y el control de todo el módulo. En la figura 3.5 sepueden observar los campos de cada uno de ellos. R#0 es el registro de configu-ración y control de estado. Sus campos son:
En (R#0[0]): habilita el módulo pero no dispara la operación.
RnW (R#0[1]): poniendo un ‘1’ en este campo se indica que la operación esde escritura; poniendo un ‘0’, que es de lectura.
Busy (R#0[2]): permanece en ‘1’ mientras haya una operación en progreso.
Err (R#0[3]): se pone en ‘1’ si se detecta algún error (CRC o NACK).
speed_out (R#0[23:16]): se utiliza para configurar la velocidad de transmisióndel protocolo.
FIGURA 3.5: Registros internos del bloque AXI_Ctrl.
Por otro lado, en R#1 se almacena la dirección de memoria del DUT a la cualse quiere escribir o leer. En R#2 se escribe el dato a transmitir. Al escribir esteregistro, si el bit R#0[0] se encuentra en ‘1’, se inicia la operación.
Una vez iniciada la operación, la señal enable le indica al bloque central que puedeenviar el paquete al DUT. En ese momento, la señal busy se pone en ‘1’ y se man-tiene así hasta que finaliza la operación con el DUT. Si la operación es de lectura,
28 Capítulo 3. Diseño e Implementación
el bloque AXI_Ctrl, por medio de la señal stream_start, le indica a AXIS_Data quepuede enviar el dato recibido al DMA.
Es importante destacar, que para generar una transferencia con el DUT, ya seade escritura o de lectura, solo se ejecutan comandos de escritura sobre el busAXI_Ctrl. En resumen los pasos necesarios son los siguientes:
1. Configurar en R#0 los párametros de la operación.
2. Habilitar la comunicación poniendo en ‘1’ el bit_0 de R#0.
3. Escribir en R#1 la dirección del registro destino del DUT.
4. Escribir en R#2 el dato a transmitir. Este paso debe realizarse incluso parauna operación de lectura.
Generación de interfaces AXI
Vivado provee una herramienta que facilita la generación de periféricos AXI4.Para utilizarla se ingresan los puertos AXI deseados y se indica tipo de interfaz,si es maestro o esclavo, y el ancho de la palabra de datos. Las figuras 3.6a y 3.6bmuestran la configuración elegida para los módulos de este proyecto.
(A) Configuración de la interfaz AXI-Full.
(B) Configuración de la interfaz AXI-Stream.
FIGURA 3.6: Configuración de las interfaces AXI-Full y AXI-Stream de los módulos de comunicación.
Luego de configurar los puertos, la herramienta genera tres archivos en lenguajeHDL: uno para cada interfaz ingresada y otro que las instancia a ambas. En estosarchivos de código está resuelta gran parte de la implementación de las interfacesAXI, y únicamente es necesario agregar la lógica propia de cada protocolo.
3.2. Lógica programable 29
3.2.2. Acceso Directo a Memoria
El módulo de Acceso Directo a Memoria (DMA) utilizado fue el proporcionadoen la librería de IPs (Intelectual Properties) de Xilinx, más precisamente la versiónAXI Direct Memory Access 7.1. La función de este módulo es proveer un caminorápido de escritura y lectura de la memoria desde la lógica programable. Tieneuna amplia variedad de modos de uso que se encuentran detallados en el manualdel fabricante [8].
La configuración elegida para este trabajo puede observarse en la figura 3.7. Eneste caso, solo el canal de escritura es necesario y, debido al bajo flujo de datos, seeligió el modo común por sobre el modo scather-gather. De esta forma, el móduloqueda conformado por tres interfaces AXI:
S_AXI_LITE: se utiliza para la inicialización, el control del estado y el ma-nejo de los registros internos.
S_AXIS_S2MM: es la interfaz AXI-Stream que recibe el flujo de datos desdeel módulo del protocolo de comunicación.
M_AXI_S2MM: se conecta al puerto HP del PS y transfiere los datos haciala memoria.
Los prefijos “S” y “M” indican si se trata de una interfaz esclavo o maestro respec-tivamente. El sufijo “S2MM” proviene de las cifras en inglés de Stream to MemoryMapped e indica el sentido del flujo de datos. En este caso, va desde un dispositivoAXI-Stream hacia la memoria del sistema.
Cuando una transferencia termina, se dispara la interrupción IOC (Interrupt OnComplete) para indicarle al PS que los datos están disponibles en la memoria.
FIGURA 3.7: Configuración del módulo AXI_DMA.
30 Capítulo 3. Diseño e Implementación
Inicialización y uso
La inicialización se realiza a través del registro de control “S2MM_DMACR”. Sedeben poner en ‘1’ el bit #12 de este registro para habilitar la interrupción IOC yel bit #1, que habilita las operaciones sobre el módulo.
Luego de la inicialización, para realizar una transferencia primero es necesarioescribir en el registro “S2MM_DA” (Destination Address Register) la dirección de lamemoria de destino. Por último, la transferencia comienza al escribir la longituden bytes del paquete en el registro “S2MM_LENGTH”.
3.3. Módulo de procesamiento
Para el sistema de procesamiento se utilizó el módulo provisto por Xilinx “ZYNQ7Processing System 5.5”. La figura 3.8 muestra las distintas partes que lo compo-nen. Los bloques verdes son configurables; los bloques grises, como los núcleos yla memoria caché, no admiten modificación alguna.
FIGURA 3.8: Sistema de procesamiento ZYNQ7.
Por defecto, algunos periféricos se encuentran ya habilitados. Estos aseguran lafuncionalidad del kit de desarrollo Zedboard e incluso, permiten cargar un siste-ma operativo Linux de prueba otorgado por el fabricante. Estos son:
La interfaz de la memoria DDR3.
El controlador de memoria flash, configurado en modo Quad SPI.
El puerto ENET 0, para la conexión a la red vía ETHERNET.
El puerto USB 0, para programación por JTAG y debugging.
El módulo UART 1, para la comunicación serie con la PC.
El controlador de la memoria SD, para relizar el booteo del sistema operativo.
3.4. Sistema Operativo 31
Para conectar los bloques de PL desarrollados al sistema de procesamiento, fuenecesario realizar algunas configuraciones extra. Primero se habilitaron los puer-tos GP0-AXI maestros para las interfaces de control de cada bloque y los puertosHP0-AXI esclavos para conectar la salida de los DMA. Luego se activaron las in-terrupciones provenientes de la PL. Finalmente, se configuró la frecuencia de relojdeseada para utilizar en estos módulos; en este caso, se eligió una frecuencia de100 MHz.
3.3.1. Mapa de memoria
Las direcciones de memoria de los periféricos propios del PS vienen establecidaspor el fabricante y no es posible, ni necesario para este trabajo, modificarlas.
Los bloques de lógica programable conectados a los puertos GP0 se mapean en elrango de memoria comprendido entre las direcciones 0x4000_0000 y 0x7FFF_FFFF.Es tarea del diseñador asignar la dirección base y el tamaño de cada interfaz co-nectada a dicho puerto. Es necesario asegurarse de que las zonas de memoriaasignadas se encuentren dentro del rango mencionado y que no se solapen en-tre sí. Las direcciones elegidas son empleadas para escribir y leer a los distintosbloques de PL por medio de la interfaz AXI.
La figura 3.9 muestra el mapa de memoria de todas las interfaces conectadas aGP0.
FIGURA 3.9: Mapa de memoria de la lógica programable.
3.4. Sistema Operativo
Aunque el uso del sistema operativo Linux fue requerido por el cliente, son mu-chas las razones que justifican esta decisión. Linux permite desarrollar un sistemastand-alone, con un entorno de trabajo conocido por los usuarios finales del equi-po, fácilmente escalable y con acceso a red. Además provee una gran cantidadde herramientas, soporta muchos lenguajes de programación y ofrece un ampliosoporte para desarrolladores.
Asimismo, se decidió construir una distribución propia de Linux. Esta decisiónfue tomada, por un lado, para aprender acerca de este proceso; y por otro, pornecesidad: compilar una distribución propia permite configurar libremente el usode memoria e incluir la lógica programable en el árbol de dispositivos.
32 Capítulo 3. Diseño e Implementación
Los componentes necesarios para construir la imagen del sistema operativo seenumeran en la siguiente lista y serán explicados en las secciones sucesivas:
Una primera etapa de bootloader, encargada de inicializar el hardware.
Una segunda etapa de bootloader, o “U-Boot”, utilizada para configurar einiciar el sistema operativo.
El núcleo del sistema operativo, llamado kernel.
Un árbol de dispositivos, o device tree, que contenga la descripción de losperiféricos.
El sistema de archivos raíz, donde se montará toda la estructura del sistemaoperativo.
3.4.1. Primera etapa de bootloader
La primera etapa de bootloader, también conocida como “FSBL” (del inglés FirstStage Bootloader), se encarga de configurar la arquitectura del PS y programar laPL. El FSBL inicializa el controlador de la memoria DDR y de esta forma le per-mite al U-Boot acceder a ella.
El entorno de trabajo de Xilinx y sus distintas herramientas permiten generar fá-cilmente el FSBL. Utilizando Vivado, se genera un archivo llamado bitstream, quecontiene la configuración de la PL y el PS. Luego, el bitstream es exportado hacia elsoftware SDK, que se encarga de la construcción del FSBL. Para lograrlo, se debecrear una nueva aplicación de software utilizando la plantilla que se muestra enla figura 3.10.
FIGURA 3.10: Plantilla para la generación del FSBL proporcionadapor Xilinx.
3.4. Sistema Operativo 33
3.4.2. Segunda etapa de bootloader
Para generar U-Boot se utilizaron los archivos fuente proporcionados en el repo-sitorio de Xilinx [9]. Fue necesario importar una versión más antigua del repo-sitorio para que esta fuera compatible con la versión de Vivado utilizada. El tagimportado fue “xilinx-v2018.3”.
La compilación se realizó por medio de compilación cruzada (cross-compilation)desde una PC con Ubuntu 16.04. Para lograrlo fue preciso definir dos variablesde entorno, una para indicar el compilador a utilizar y otra para definir la ar-quitectura. Los comandos para configurarlas se muestran en el algoritmo 3.1. Elcompilador utilizado se obtuvo de los archivos de instalación de Vivado.
1 export CROSS_COMPILE=arm−l inux−gnueabihf− // Compilador2 export ARCH=arm // Arqui tec tura
ALGORITMO 3.1: Variables de entorno para la compilación de U-Boot.
El repositorio de Xilinx provee archivos de configuración específicos para cadamicro-controlador. El archivo para la placa Zedboard se llama “zynq_zed.h”. Seutiliza para configurar el tamaño de la memoria, el uso de algunos periféricose incluir un archivo de configuración más general llamado “zynq_common.h”.Esto puede verse en el algoritmo 3.2.
1 # i f n d e f __CONFIG_ZYNQ_ZED_H2 # def ine __CONFIG_ZYNQ_ZED_H3
4 # def ine CONFIG_SYS_SDRAM_SIZE (512 * 1024 * 1024)5 # def ine CONFIG_ZYNQ_SERIAL_UART16 # def ine CONFIG_ZYNQ_GEM07 # def ine CONFIG_ZYNQ_GEM_PHY_ADDR0 08 # def ine CONFIG_SYS_NO_FLASH9 # def ine CONFIG_ZYNQ_USB
10 # def ine CONFIG_ZYNQ_SDHCI011 # def ine CONFIG_ZYNQ_BOOT_FREEBSD12
13 # include < c o n f i g s/zynq−common . h>14
15 # endi f /* __CONFIG_ZYNQ_ZED_H */
ALGORITMO 3.2: Archivo de configuración zynq_zed.h.
El archivo “zynq_common.h” es común a todos los micro-controladores Zynq.Para este trabajo fue necesario modificar el campo “sdboot”, con el fin de per-mitir que el sistema de archivos residiera en una partición distinta de la tarjetade memoria SD (ver sección 3.4.5). Las diferencias entre el código original y elmodificado pueden observarse en los algoritmos 3.3 y 3.4.
1 " sdboot= i f mmcinfo ; then " \2 " run uenvboot ; " \3 " echo Copying Linux from SD to RAM. . . && " \4 " load mmc 0 $ { kernel_ load_address } $ { kernel_image } && " \5 " load mmc 0 $ { device t ree_ load_address } $ { devicetree_image } && " \6 " load mmc 0 $ { ramdisk_load_address } $ { ramdisk_image } && " \7 " bootm $ { kernel_ load_address } $ { ramdisk_load_address } $ {
device t ree_ load_address } ; " \8 " f i \0 " \
ALGORITMO 3.3: Configuración original del campo “sdboot”.
34 Capítulo 3. Diseño e Implementación
1 " sdboot= i f mmcinfo ; then " \2 " run uenvboot ; " \3 " echo Copying Linux from SD to RAM. . . && " \4 " load mmc 0 $ { kernel_ load_address } $ { kernel_image } && " \5 " load mmc 0 $ { device t ree_ load_address } $ { devicetree_image } && " \6 " bootm $ { kernel_ load_address } − $ { device t ree_ load_address } ; " \7 " f i \0 " \
ALGORITMO 3.4: Configuración modificada del campo “sdboot”.
Finalmente, para la generación del archivo “uboot.elf” se corrieron los siguientescomandos desde el directorio donde fue clonado el repositorio:
1 make d i s t c l e a n2 make zynq_zed_defconfig3 make
3.4.3. Árbol de dispositivos
El device tree es una estructura de datos que describe los componentes del hardwa-re de modo tal que el sistema operativo pueda acceder a ellos y utilizarlos. Dentrode estos están comprendidos: las CPUs, la memoria, los buses y los dispositivosperiféricos, incluidos los módulos de PL. La estructura de datos está compuestapor nodos que representan cada componente y a su vez, los nodos poseen unalista de propiedades que describen sus distintos parámetros.
El software SDK de Xilinx posee una herramienta que ayuda a la construccióndel device tree. Basada en el tipo de SoC utilizado, la configuración elegida parael PS y los bloques de PL desarrollados, la herramienta genera una serie de ar-chivos que describen cada una de las partes del hardware. La figura 3.11 muestracomo ejemplo la descripción de dos bloques de lógica programable incluidos enel sistema, el módulo SPI y el DMA conectado a él.
Por otro lado, el software SDK genera una archivo llamado “system-top.dts” queincluye a los anteriores y agrega ciertos campos de configuración que pueden sereditados por el diseñador. Uno de ellos es el campo “bootargs”, mediante el cualpueden pasarse comandos que serán ejecutados por U-Boot durante la carga delsistema operativo. La figura 3.12 muestra los argumentos pasados a “bootargs”en este trabajo. En ellos se define la interfaz serie a utilizar para la consola y lacantidad de memoria RAM disponible para el kernel. Por otro lado, con el co-mando “root=/dev/mmcblk0p2” se indica que el sistema de archivos raíz debebuscarse en la segunda partición de la tarjeta SD. Esto último será explicado másen detalle en la sección 3.4.6.
3.4.4. Kernel
La versión de kernel utilizada fue la 4.14.0-xilinx, provista por Xilinx en su repo-sitorio de GitHub [10]. Para compilarlo fue necesario clonar el repositorio a unaPC con Linux y ejecutar los comandos que se explican a continuación desde eldirectorio raíz. Antes de la compilación fue necesario configurar la variable deentorno “CROSS_COMPILE” como se explicó en la sección 3.4.2.
El primer paso fue generar el archivo “.config” donde se define la configura-ción del kernel. Xilinx ofrece una configuración básica necesaria para los SoCs
3.4. Sistema Operativo 35
FIGURA 3.11: Descripción de los módulos PL en el device tree.
FIGURA 3.12: Argumentos definidos en el device tree para la cargadel sistema operativo.
36 Capítulo 3. Diseño e Implementación
de la familia Zynq, que puede ejecutarse con el comando “make ARCH=arm xi-linx_zynq_defconfig”. Aunque no fue necesario, es posible modificar esta confi-guración, puede hacerse antes de la compilación utilizando el comando “makeARCH=arm menuconfig”.
Una vez generado el archivo de configuración, se ejecutó el comando “makeARCH=arm UIMAGE_LOADADDR=0x8000 uImage”. De esta manera se creó elarchivo “uImage” que contiene la imagen del kernel que se cargó en el sistema.
3.4.5. Sistema de archivos
La placa Zedboard admite dos tipos de estrategias distintas para el sistema dearchivos, más conocido como root file system. La opción por defecto es utilizar unramdisk, este consiste en un sistema de archivos pequeño (del orden de las decenasde MB) que incluye las funcionalidades más básicas y corre sobre la memoriaRAM, lo que permite un acceso veloz. La gran desventaja del ramdisk es que no espersistente, esto quiere decir que los cambios realizados no se conservan luego dereiniciar el dispositivo. Por otro lado, existe la posibilidad de montar un sistemade archivos en una partición de la tarjeta SD distinta a la utilizada por el bootloader.De esta manera, se obtiene un almacenamiento persistente y que no se encuentralimitado al tamaño de la memoria RAM de la placa.
Para este trabajo se optó por esta última opción debido a la necesidad de conser-var la información almacenada luego del reinicio del sistema. Se utilizó la versiónde Ubuntu 14.04 proporcionada por ARM [11], esta fue montada sobre una parti-ción de 7,5 GB de memoria y con formato ext4.
Las modificaciones realizadas en la configuración de U-Boot y del device tree, lepermiten al bootloader reconocer la ubicación del file system y montarlo sin pro-blemas.
3.4.6. Montaje de los componentes en la tarjeta SD
Antes de montar todos los archivos generados en la tarjeta de memoria SD, fuenecesario generar el archivo imagen del bootloader, llamado “BOOT.bin”. La ima-gen se generó a partir del FSBL, del bitstream y del archivo uboot.elf. SDK poseeuna herramienta denominada Create Boot Image, que facilita esta tarea.
Se utilizó una tarjeta de memoria de 8 GB con dos particiones, la primera de 500MB con formato FAT32 y la segunda de 7,5 GB con formato ext4. La segundapartición se utilizó para montar el root file system, como se mencionó en la sección3.4.5. Mientras que en la primera partición se colocaron los siguientes archivos:
La imagen “BOOT.bin” generada.
El ejecutable de la primera etapa del bootloader.
El archivo bitstream.
El ejecutable de la segunda etapa del bootloader.
La imagen del kernel.
El archivo generado “devicetree.dtb”.
De esta forma, al encender la Zedboard con la tarjeta SD insertada, comienza lasecuencia de “booteo”: el FSBL configura el hardware, el U-Boot copia el devicetree
3.4. Sistema Operativo 37
y el kernel sobre la memoria RAM, y les da acceso al sistema de archivos ubicadoen la tarjeta de memoria.
3.4.7. Drivers para la lógica programable
Fue necesario el desarrollo de dos drivers distintos, uno que permite leer y escri-bir a las interfaces AXI-Full y AXI-Lite de cada bloque, y otro que controla lasoperaciones de DMA. Ambos son explicados a continuación.
Drivers para los módulos de comunicación
Para iniciar una operación con los módulos de comunicación es necesario accedera su interfaz AXI_Ctrl y escribir en sus registros internos la secuencia indicada enla sección 3.2. Esto es posible gracias a que cada interfaz AXI posee una direcciónde memoria asociada (ver figura 3.9). Al escribir, o leer, en esa dirección se iniciala comunicación entre el PS y la PL, a través de los puertos GP-AXI.
Acceder a estos registros de memoria utilizando código baremetal es trivial, yaque todo el mapa de memoria física se encuentra disponible para la aplicación.Entonces alcanza simplemente con escribir o leer sobre la dirección física de unpuerto AXI para iniciar una transacción.
En cambio, Linux utiliza un sistema de memoria virtual que le impide a las apli-caciones a nivel de usuario acceder a la memoria física directamente. Por lo tanto,para poder controlar los bloques de la PL existen dos caminos posibles: realizarun driver a nivel de kernel, o acceder a las direcciones de los bloques a nivel deusuario a través del dispositivo “/dev/mem”. Esta última opción, conocida co-mo “pseudo-driver, no suele ser recomendable en sistemas complejos o expuestosa usuarios inexpertos, ya que un simple error en la dirección de una operaciónpuede traer consecuencias destructivas para el sistema.
Sin embargo, en esta primera versión del trabajo se eligió utilizar “pseudo-drivers”para acceder a los buses de control de la lógica programable, debido a la simple-za de su implementación. Esta decisión fue tomada teniendo en cuenta que elsistema será utilizado únicamente por personal capacitado.
En los algoritmos 3.5 y 3.6 se muestra el pseudocódigo desarrollado para realizaroperaciones de escritura y lectura con los módulos de la PL.
1 void i 2 c _ w r i t e ( . . . )2 {3 // Se abre e l d i s p o s i t i v o /dev/mem y se obt iene su d e s c r i p t o r4 fd = open (/dev/mem, . . . ) ;5 // Se mapea l a d i r e c c i o n f i s i c a del d i s p o s i t i v o a una d i r e c c i o n
v i r t u a l6 i 2 c _ v i r t u a l _ a d d r e s s = mmap ( . . . , fd , I2C_PHYSIC_ADDR) ;7 // Se e s c r i b e en R#1 l a d i r e c c i o n dest ino del DUT8 i 2 c _ v i r t u a l _ a d d r e s s [ I2C_REG_1_ADDR] = DUT_REG_ADDR;9 // En R#0 se configuran velocidad y t i p o de operacion
10 i 2 c _ v i r t u a l _ a d d r e s s [ I2C_REG_0_ADDR] = (ENABLE | WRITE | SPEED) ;11 // En R#2 se e s c r i b a e l dato a enviar , e s to i n i c i a l a t r a n s a c c i o n12 i 2 c _ v i r t u a l _ a d d r e s s [ I2C_REG_2_ADDR] = DATA;13 // Se l i b e r a n l o s recursos del s is tema14 munmap( i 2 c _ v i r t u a l _ a d d r e s s ) ;15 c l o s e ( fd ) ;16 }
ALGORITMO 3.5: Pseudocódigo de la operación de escritura.
38 Capítulo 3. Diseño e Implementación
1 i n t * read ( . . . )2 {3 . . .4 // Se abre e l d i s p o s i t i v o /dev/mem y se obt iene su d e s c r i p t o r5 fd = open (/dev/mem, . . . ) ;6 // Se mapea l a d i r e c c i o n f i s i c a del d i s p o s i t i v o a una d i r e c c i o n
v i r t u a l7 v i r t u a l _ a d d r e s s = mmap ( . . . , fd , PHYSIC_ADDR) ;8 // Se e s c r i b e en R#1 l a d i r e c c i o n dest ino del DUT9 v i r t u a l _ a d d r e s s [REG_1_ADDR] = DUT_REG_ADDR;
10 // En R#0 se configuran velocidad y t i p o de operacion11 v i r t u a l _ a d d r e s s [REG_0_ADDR] = (ENABLE | READ | SPEED) ;12 // En R#2 se e s c r i b a e l dato a enviar , e s to i n i c i a l a t r a n s a c c i o n13 v i r t u a l _ a d d r e s s [REG_2_ADDR] = DATA;14 // Se i n i c i a l a t r a n s f e r e n c i a por DMA15 dma_read ( rx_buf fer , length ) ;16 // Se l i b e r a n l o s recursos del s is tema17 munmap( v i r t u a l _ a d d r e s s ) ;18 c l o s e ( fd ) ;19 // Se devuelve e l puntero a l o s datos r e c i b i d o s20 re turn ( r x _ b u f f e r ) ;21 }
ALGORITMO 3.6: Pseudocódigo de la operación de lectura.
Drivers para los DMA
Para el manejo de DMA se diseñó un driver a nivel de kernel, encargado de inter-actuar con el dispositivo, y una aplicación a nivel de usuario, que permite iniciarlas transacciones y acceder a los datos obtenidos.
El driver realizado utiliza funciones de la “DMA-API” de Linux [12] y está ba-sado en un desarrollo hecho por Xilinx, que se encuentra documentado en [13].Algunas características del driver a nivel de kernel son:
Está diseñado solo para operaciones de lectura, no se puede enviar datosdesde el PS al dispositivo DMA.
Utiliza la función dma_malloc_coherent() para reservar memoria no “cachea-da” y luego poder compartirla con la aplicación de espacio de usuario.
Posee una interfaz que permite a la aplicación en espacio de usuario iniciartransacciones y acceder a la memoria compartida.
Crea un nodo dentro del directorio “/dev” llamado “dma_proxy_rx”.
El algortimo 3.7 muestra el pseudocódigo de la aplicación. Esta accede al drivera través del nodo /dev/dma_proxy_rx y mapea el buffer de memoria reservado porel kernel al espacio de usuario. Las transacciones se inician utilizando la funciónioctl(), que permanece bloqueada hasta que todos los paquetes son recibidos.
3.5. Hardware 39
1 void dma_read ( i n t * rx_buf fer , i n t s i z e )2 {3 . . .4 // Se abre e l nodo /dev/dma_proxy_rx y se obt iene su d e s c r i p t o r5 dma_rx_fd = open(/dev/mem, . . . ) ;6
7 // Se crea una e s t r u c t u r a que permite i n t e r a c t u a r con e l kernel8 s t r u c t _ i n t e r f a c e = mmap ( . . . , dma_rx_fd , . . . ) ;9
10 // Configura l a longitud de l a operacion11 s t r u c t _ i n t e r f a c e −>length = s i z e ;12
13 // I n i c i a l i z a e l b u f f e r de recepcion de l a e s t r u c t u r a14 f o r ( i = 0 ; i < s i z e ; i ++)15 s t r u c t _ i n t e r f a c e −>b u f f e r [ i ] = 0 ;16
17 // I n i c i a l a operacion y se bloquea hasta que termina18 i o c t l ( dma_rx_fd , . . . ) ;19
20 // Se copian l o s datos a l b u f f e r de s a l i d a21 f o r ( i = 0 ; i < s i z e ; i ++)22 r x _ b u f f e r [ i ] = s t r u c t _ i n t e r f a c e −>b u f f e r [ i ] ;23
24 // Se l i b e r a n l o s recursos del s is tema25 munmap( s t r u c t _ i n t e r f a c e ) ;26 c l o s e ( dma_rx_fd ) ;27 }
ALGORITMO 3.7: Aplicación en espacio de usuario paraoperaciones con DMA.
3.5. Hardware
Si bien la mayor parte del hardware utilizado se encuentra implementado en laplaca de desarrollo Zedboard, fue necesario el diseño de un PCB externo, prin-cipalmente para asegurar una adecuada interfaz de conexión entre sus puertosy los del DUT. El circuito impreso desarrollado se muestra en la figura 3.13. Susfunciones son las siguientes:
Controlar la tensión de alimentación de los DUTs por medio de un DAC.
Brindar aislamiento entre la Zedboard y el DUT para reducir la transmisiónde ruido.
Traducir el nivel de tensión de las señales de comunicación.
Proveer los buffers de entrada y de salida para la comunicación Manchester.
Asegurar la compatibilidad en la conexión con las placas utilizadas para losensayos, mencionadas en la sección 1.1.3.
Para la alimentación del PCB desarrollado se utiliza una fuente externa de 12 V.Mediante una serie de reguladores lineales y fuentes conmutadas se obtienen losvalores de tensión -5 V, 5 V y 32 V necesarios para los distintos componentes delcircuito. La Zedboard es alimentada desde el PCB con los mismos 12 V prove-nientes de la fuente externa.
Para asegurar la compatibilidad con las placas de los ensayos, se utilizó el mismoconector de salida que en el sistema ASEK, un conector Molex de 50 pines, y se
40 Capítulo 3. Diseño e Implementación
(A) Modelo 3D del PCB desarrollado. (B) Fotografía del PCB desarrollado.
FIGURA 3.13: Circuito impreso desarrollado: modelo 3D versusfoto real.
conservó la función de cada pin. La única excepción fue el pin 49, que pasó deser un pin de E/S de propósito general a ser empleado para el canal serie de lacomunicación Manchester.
3.5.1. Control de la tensión de los DUTs
El sistema desarrollado alimenta a los CI bajo prueba. Su tensión de alimentación(VCC) puede variar entre 3,3 V y 12 V. Por otro lado, la mayoría de los CI desa-rrollados en Allegro tienen un circuito interno que les permite detectar señales desobre-tensión o baja tensión. En base a esta detección se realizan diversas funcio-nes, como llevar al chip a un estado seguro o indicar el inicio de la comunicaciónpor Manchester.
Por estos motivos fue necesario el desarrollo de un circuito conversor digital-analógico que permite regular la tensión de salida entre 0 V y 32 V. Para lograrlose utilizó un DAC LTC2600 de la empresa Linear Technologies, que es comanda-do desde la Zedboard por el protocolo SPI. El DAC es alimentado con una tensiónde 5 V, por lo tanto para alcanzar los 32 V a la salida, se agregó un amplificadoroperacional alimentado con -V= -5 V y +V=+32 V. Por último, a la salida del am-plificador se añadió un buffer que le permite manejar una corriente de hasta 150mA. La figura 3.14 muestra el esquemático del circuito descripto.
3.5.2. Interfaces para los protocolos de comunicación
Para las interfaces SPI e I2C se agregaron circuitos aisladores entre los puertosde la placa Zedboard y los pines de conexión con el DUT. La aislación galvánica,
3.5. Hardware 41
FIGURA 3.14: Circuito para la alimentación de los DUTs.
por un lado, protege al DUT de riesgos eléctricos; además, separa las masas delos circuitos para evitar lazos y reducir el ingreso de ruido; por último, adapta laseñal a los distintos niveles de tensión de un lado y del otro del circuito.
Para la interfaz SPI se utilizó el aislador ADUM1401, que permite trabajar entre2,7 V y 5,5 V y hasta 90 Mbps. La figura 3.15 muestra el circuito implementado.
FIGURA 3.15: Circuito aislador utilizado para la comunicaciónSPI.
Para la interfaz I2C se utilizó el aislador ADUM1250. Está especialmente dise-ñado para comunicación bidireccional con este protocolo: presenta puertos open-drain, soporta una frecuencia de operación de hasta 1 MHz y trabaja entre 3 Vy 5,5 V. El circuito desarrollado se muestra en la figura 3.16. Por otro lado, tam-bién fueron añadidas las resistencias de pull-up necesarias sobre los canales SDAy SCL.
La interfaz Manchester resultó un poco más compleja. Este protocolo por lo gene-ral no posee un pin dedicado en los CI de Allegro, en estos casos la comunicaciónse realiza a través del pin de salida de los chips o a través del pin de VCC. Por lotanto la tensión a la que trabaja el protocolo debe ser configurada por medio deun DAC, como se hizo con la tensión de alimentación.
El diagrama de la figura 3.17 muestra el circuito diseñado de manera simplificada.Las señales sdata_in, sdata_out y sdata_out_en provienen del módulo Manchesteren la PL de la Zedboard. Cuando sdata_out_en está en alto, permite que sdata_outconmute la tensión proveniente del DAC, lo cual genera una señal Manchester
42 Capítulo 3. Diseño e Implementación
FIGURA 3.16: Interfaz utilizada para la comunicación I2C.
entre 0 V y DAC_out. Cuando sdata_out_en está en bajo, la llave sw1 se abre y sw2se cierra. De esta manera, la señal proveniente del DUT ingresa al comparador.Este compara la señal recibida contra un nivel de tensión configurable, lo quepermite la detección de flancos de la señal.
sdata_out
DAC_out
sdata_out_en
sdata_in Comp
Threshold
MHT_inoutADG452
sw1
sw2
FIGURA 3.17: Diagrama de la interfaz para el protocolo Manches-ter.
43
Capítulo 4
Ensayos y Resultados
En este capítulo se muestran las pruebas unitarias realizadas sobre los bloques delógica programable, y se presentan las pruebas de integración entre estos bloquesy el sistema de procesamiento. Luego se menciona un caso de aplicación parael que ha sido utilizado el sistema en la empresa y se realiza un análisis de losresultados.
4.1. Validación de la lógica programable
Para la validación de la lógica programable se desarrollaron bancos de pruebaen lenguaje Verilog para cada módulo que luego fueron simulados utilizando elsoftware Vivado. Primero se verificó el funcionamiento de los bloques centralesde cada protocolo de comunicación y después se realizó la verificación de estosbloques en conjunto con las interfaces AXI4 asociadas.
4.1.1. Simulación de los módulos de comunicación
Los bancos de pruebas desarrollados fueron distintos para cada módulo, pero loscasos de prueba analizados fueron los mismos:
Caso #1: Escritura simple
Caso #2: Lectura simple
Caso #3: Escritura múltiple
Caso #4: Lectura múltiple
Caso #5: Escritura simple con error de ACK forzado (sólo para I2C)
Caso #6: Lectura simple con error de CRC forzado (sólo para SPI y Man-chester)
La verificación de la trama generada para cada protocolo se realizó de mane-ra visual, observando las formas de onda simuladas. En la figura 4.1 se puedenapreciar los resultados.
44 Capítulo 4. Ensayos y Resultados
(A) Formas de ondas simuladas para el protocolo SPI.
(B) Formas de ondas simuladas para el protocolo SPI-ASILD.
(C) Formas de ondas simuladas para el protocolo I2C.
(D) Formas de ondas simuladas para el protocolo Manchester.
FIGURA 4.1: Formas de onda simuladas para cada protocolo.
4.1. Validación de la lógica programable 45
Por otro lado, para verificar el correcto funcionamiento de la recepción de losdatos, se simuló la respuesta del dispositivo esclavo durante las operaciones delectura. La verificación de los datos recibidos fue realizada de manera automá-tica en el código del banco de pruebas, utilizando expresiones similares a la delalgoritmo 4.1.
1 // Se espera a que l a operacion termine ( busy =0)2@( negedge t_busy ) # (SYS_CLK_FREQ * 2 )3 // Se compara e l dato r e c i b i d o con e l esperado4 i f ( t_ rx_data == 16hF1F1 )5 $display ( " Tes tcase #2 − OK: Right RX data " ) ;6 e l s e7 $display ( " Tes tcase #2 − FAIL : Wrong RX data " ) ;8 // Se v e r i f i c a que no se haya producido un e r r o r de CRC ( solo SPI y
manch )9 i f ( t _ c r c _ e r r == 1b0 )
10 $display ( " Tes tcase #2 − OK: not CRC e r r o r " ) ;11 e l s e12 $display ( " Tes tcase #2 − FAIL : CRC e r r o r " ) ;
ALGORITMO 4.1: Código para la verificación de los datosrecibidos.
Por último, la detección de los errores forzados se verificó también de maneraautomática a través del banco de pruebas. El algoritmo 4.2 muestra una expresióndel estilo utilizado para este fin.
1 // Se espera a que l a operacion termine ( busy =0)2@( negedge t_rx_busy ) # (SYS_CLK_FREQ * 2 )3 // S i e l e r r o r fue detectado l a prueba pasa4 i f ( t _ c r c _ e r r == 1b1 )5 $display ( " Tes tcase #2 − OK: CRC ERROR a s s e r t e d " ) ;6 e l s e7 $display ( " Tes tcase #2 − FAIL : CRC ERROR not a s s e r t e d " ) ;
ALGORITMO 4.2: Código para la verificación errores forzados.
4.1.2. Simulación de las interfaces AXI
Es muy importante verificar el funcionamiento de las interfaces AXI antes de in-tegrarlas al PS. De lo contrario se vuelve muy complicado encontrar fallas en unbus a nivel de software.
La figura 4.2 muestra un diagrama de las pruebas realizadas para la verificaciónde los módulos. Se creó un banco de prueba en lenguaje Verilog que simula loscanales de la interfaz AXI provenientes del PS y los inyecta como estímulo a laentrada del bloque AXI_Ctrl. Observando las formas de onda resultantes de lasimulación, se pudo comprobar que los comandos son recibidos de manera ade-cuada a través de la interfaz AXI-Full, y que se generan las respuestas esperadas.
Se comprobó que, luego de enviar los comandos necesarios a la interfaz AXI_Ctrl,se genera la operación con el DUT a través de las señales propias del protocolo.Por otro lado, también se verificó que luego de una operación de lectura, los da-tos recibidos desde el DUT se transmiten correctamente a través de la interfazAXI-Stream. En la figura 4.3 se muestra, a modo de ejemplo, el resultado de lasimulación de la interfaz AXI_Ctrl para el protocolo SPI. Por su parte, la figura4.4, muestra una operación de lectura de cuatro paquetes con el mismo protoco-lo. Luego de que finaliza cada trama de SPI, el dato recibido se copia a la señal
46 Capítulo 4. Ensayos y Resultados
Módulo bajo prueba
Canal dedirección
Canal dedatos
Simulaciónde escritura
Canal dedirección
Canal dedatos
Simulaciónde lectura
Inte
rfaz
AXI_
Ctrl
(AXI
-Ful
l)
Módulocentral delprotocolo
Inte
rfaz
AXIS
_Dat
a (A
XI-S
tream
)
AXI-Streamal DMA
Señalesal DUT
Estímulosinyectados
Salidasmonitoreads
FIGURA 4.2: Diagrama del banco de pruebas desarrollado paraverificar las interfaces AXI.
TDATA y TVALID se pone en ‘1’, y le indica al bus AXI-Stream que inicie la tran-sacción hacia el DMA. Luego de la recepción del último paquete, la señal TLASTse pone en ‘1’ junto con TVALID.
FIGURA 4.3: Resultado de la simulación de la interfaz AXI_Ctrlpara el protocolo SPI: 1) Se escribe en R#1 la dirección destino. 2)Se carga en R#0 la configuración. 3) En R#2 se escribe el dato a
enviar. 4) Comienza la operación, SPI pasa a modo busy.
4.2. Pruebas de integración
Las pruebas de integración se realizaron en dos momentos distintos del proyecto.Las primeras se llevaron adelante luego de finalizar la implementación del PS yfueron desarrolladas en código baremetal. Luego, se realizó otra serie de pruebascon el sistema operativo instalado y utilizando el hardware desarrollado.
En ambos casos, el objetivo de los ensayos fue verificar la comunicación entreel sistema y un CI de la empresa Allegro Microsystems. Para la primera etapa,las pruebas se realizaron únicamente con el protocolo SPI-ASILD para poder dar
4.2. Pruebas de integración 47
FIGURA 4.4: Resultado de la simulación de la interfaz AXIS_Datapara el protocolo SPI.
cumplimiento a los plazos previstos. Se eligió este protocolo debido a la necesi-dad apremiante de la empresa de realizar una medición en un CI específico. Eldesarrollo de esta prueba se describe en la sección 4.3.
Las pruebas desarrolladas fueron las siguientes:
1. Loopback: consistió en escribir y leer el mismo registro para verificar que elvalor enviado y el recibido coincidieran. Esta prueba fue repetida a distintasvelocidades de transmisión.
2. Escritura en ráfaga: se realizaron múltiples operaciones de escritura conse-cutivas a fin de analizar la velocidad de transmisión y el determinismo delsistema.
3. Lectura en ráfaga: se realizaron múltiples operaciones de lectura consecu-tivas a fin de analizar la velocidad de transmisión y el determinismo delsistema.
4.2.1. Resultados de las pruebas en baremetal
Las pruebas en baremetal resultaron muy satisfactorias. Por un lado, mediante laprueba de loopback, se comprobó que el protocolo SPI-ASILD funciona sin proble-mas hasta 10 MHz. Por otro lado, mediante las de escritura y lectura en ráfaga severificó que, en ambos casos, el tiempo entre paquetes es siempre el mismo, comopuede observarse en las figuras 4.5 y 4.6. Es decir que, utilizando código bareme-tal, el sistema demostró ser funcional, determinístico y alcanzó la velocidad detransmisión requerida.
FIGURA 4.5: Resultado de la prueba baremetal de escritura múltiplepara SPI-ASILD a 2 MHz.
48 Capítulo 4. Ensayos y Resultados
FIGURA 4.6: Resultado de la prueba baremetal de lectura múltiplepara SPI-ASILD a 2 MHz.
4.2.2. Resultados de las pruebas en Linux
Las pruebas de loopback y escritura en ráfaga realizadas en el entorno Linux arro-jaron buenos resultados, pero la de lectura en ráfaga dejó a la vista ciertos aspec-tos a mejorar en el futuro. En la figura 4.7 se muestran las formas de onda delas señales producidas por una operación de escritura en ráfaga para el protocoloSPI-ASILD, trabajando a 2 MHz. Se puede observar que el tiempo entre paqueteses muy pequeño y además, constante. Esto asegura una escritura rápida y deter-minística. Por otro lado, la figura 4.8 muestra las formas de onda obtenidas parala operación de lectura. En este caso se observan dos problemas distintos, el tiem-po entre paquetes es mayor que para la escritura y además es estocástico. Estose debe a la latencia que incorpora el driver de DMA desarrollado. Linux no esun sistema operativo de tiempo real, por lo que es razonable que esto suceda. Detodos modos, existen maneras de solucionar este problema, y aunque no fueronanalizadas durante el transcurso de este trabajo, serán investigadas en el futuro.
FIGURA 4.7: Resultado de la prueba de escritura múltiple en Linuxpara SPI-ASILD a 2 MHz.
FIGURA 4.8: Resultado de la prueba de lectura múltiple en Linuxpara SPI-ASILD a 2 MHz.
4.3. Caso de aplicación
Durante el desarrollo del proyecto, surgió desde la empresa la necesidad de rea-lizar una medición sobre un circuito integrado que se encontraba en proceso deevaluación.
4.3. Caso de aplicación 49
51
Capítulo 5
Conclusiones
En esta sección se detallan los principales aportes del trabajo realizado, los cono-cimientos aplicados y los próximos pasos que se llevarán a cabo para lograr eldesarrollo final del sistema.
5.1. Conclusiones generales
Como resultado de este trabajo se desarrolló el prototipo de un sistema de prue-bas para circuitos integrados, que permite comunicarse de manera rápida y efi-ciente con los dispositivos bajo prueba. De esta manera, resuelve las falencias desu predecesor y brinda una plataforma versátil, que se adapta a los distintos pro-tocolos y tensiones de trabajo de los CI de la empresa.
Aunque no fue posible cumplir con los plazos programados al inicio del proyecto,se logró desarrollar con éxito la gran mayoría de los requerimientos. La excepciónfue el relacionado con el manejo de los instrumentos de medición, que resultó seruna tarea más compleja de lo esperado. Sin embargo, los avances realizados eneste tema servirán para su futura implementación. Los requerimientos opcionalesse abordarán también en una instancia futura.
Es importante destacar que siendo este un trabajo final de carrera y no un trabajoúnicamente profesional, cumplió con su principal objetivo, ampliar y profundi-zar los conocimientos del autor. Durante la realización del proyecto se aplicaronconocimientos aprendidos en las asignaturas de la Especialización en SistemasEmbebidos. Se destacan principalmente las siguientes:
Arquitectura de microcontroladores: permitió entender la arquitectura ARMy fue fundamental para implementar el sistema de procesamiento del SoC.
Circuitos lógicos programables: gran parte del proyecto fue desarrollado enlenguaje de descripción de hardware, por lo que los conocimientos apren-didos en esta materia fueron muy importantes.
Microarquitecturas y softcores: esta materia fue imprescindible para el desa-rrollo del trabajo, se aplicaron y profundizaron los conocimientos sobre ar-quitectura de hardcores, interfaces AXI y lógica programable.
Protocolos de comunicación en sistemas embebidos: se aplicaron los cono-cimientos aprendidos sobre los protocolos SPI e I2C.
Sistemas operativos de propósito general: permitió comprender más en pro-fundidad el entorno Linux, lo que fue de gran ayuda en el desarrollo de lasaplicaciones y drivers.
52 Capítulo 5. Conclusiones
5.2. Trabajo futuro
Se listan a continuación las principales tareas pendientes a fin de transformar elprototipo desarrollado en un sistema que cubra por completo las necesidades dela empresa:
Incorporar el control de los instrumentos de medición a través del protocoloGPIB: permitirá realizar mediciones analógicas en forma veloz y automáti-ca, y potenciará enormemente la funcionalidad del sistema.
Mejorar el driver de DMA en Linux para lograr operaciones de lectura deter-minísticas: si bien este no fue un requerimiento inicial del proyecto, quedóclara su importancia durante el desarrollo de las pruebas.
Analizar la factibilidad de crear un PCB que incluya el SoC y los periféricosnecesarios, a fin de independizarse de la Zedboard.
Agregar un módulo de conexión WiFi para permitir el acceso a la red dellaboratorio de forma inalámbrica.
53
Bibliografía
[1] Avnet. Zedboard overview. http://zedboard.org/product/zedboard.(Visitado 19-03-2020).
[2] Xilinx. Zynq-7000 SoC Technical Reference Manual.https://www.xilinx.com/support/documentation/user_guides/ug585-Zynq-7000-TRM.pdf. Jul. de 2018. (Visitado 19-03-2020).
[3] Xilinx. Xilinx website. https://www.xilinx.com/. (Visitado 19-03-2020).[4] ARM. AMBA AXI and ACE Protocol Specification. https://static.docs.arm.
com/ihi0022/e/IHI0022E_amba_axi_and_ace_protocol_spec.pdf. Feb. de2013. (Visitado 20-03-2020).
[5] Xilinx. AXI Reference Guide. https://www.xilinx.com/support/documentation/ip_documentation/ug761_axi_reference_guide.pdf.Mar. de 2011. (Visitado 20-03-2020).
[6] Cadence. Functional Safety Methodologies for Automotive Applications.https://www.cadence.com/content/dam/cadence-www/global/en_US/documents/solutions/automotive-functional-safety-wp.pdf. Ago. de 2019. (Visitado 20-03-2020).
[7] Ing. Matías Paramidani. Plan de Proyecto del Trabajo Final de Carrera deEspecialización de Sistemas Embebidos. Sistema para pruebas de alta velocidad ybajo ruido en circuitos integrados. https://docs.google.com/document/d/12KdeXkAROjJoCSdKgzmUe5nTOuX6QrJOxsDeWw6BWmk/edit?usp=sharing. Jun. de 2019. (Visitado 21-03-2020).
[8] Xilinx. AXI DMA v7.1. https://www.xilinx.com/support/documentation/ip_documentation/axi_dma/v7_1/pg021_axi_dma.pdf.Jun. de 2019. (Visitado 22-03-2020).
[9] Xilinx. u-boot-xilinx GitHub Repository.https://github.com/Xilinx/u-boot-xlnx. (Visitado 24-03-2020).
[10] Xilinx. linux-xilinx GitHub Repository.https://github.com/Xilinx/linux-xlnx. (Visitado 24-03-2020).
[11] ARM. Ubuntu 14.04 for ARM. http://s3.armhf.com/dist/basefs/ubuntu-trusty-14.04-armhf.com-20140603.tar.xz. (Visitado 24-03-2020).
[12] Inc. Linux Kernel Organization. DMA-API.https://www.kernel.org/doc/Documentation/DMA-API.txt. (Visitado27-03-2020).
[13] Xilinx. Linux DMA From User Space. https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842418/Linux+DMA+From+User+Space.(Visitado 27-03-2020).