Diseño e implementación de USB 3.0 super speed para FPGAlaboratorios.fi.uba.ar › lse › tesis › LSE-FIUBA-Trabajo-Final... · 2019-02-16 · III Resumen En este trabajo se

UNIVERSIDAD DE BUENOS AIRES

FACULTAD DE INGENIERÍA

MAESTRÍA EN SISTEMAS EMBEBIDOS

MEMORIA DEL TRABAJO FINAL

Diseño e implementación de USB 3.0super speed para FPGA

Autor:Esp. Ing. Nicolás Dassieu Blanchet

Director:Mg. Ing. Diego Javier Brengi (INTI, UNLaM, FIUBA)

Codirector:Ing. Salvador Tropea (INTI, UTN-FRBA)

Jurados:Mg. Ing. Pablo Ridolfi (UTN-FRBA, FIUBA)

Mg. Ing. Facundo Larosa (UTN-FRH, FIUBA)Dr. Ing. Pablo Gomez (FIUBA)

Este trabajo fue realizado en las Ciudad Autónoma de Buenos Aires, entre enerode 2018 y julio de 2018.

III

Resumen

En este trabajo se presenta el diseño e implementación de una biblioteca enVHDL para FPGA capaz de comunicarse por USB 3.0 con una PC, a una

velocidad de subida de datos de al menos 1280 Mbps. Tiene como objetivoaumentar las prestaciones de un producto de desarrollo nacional que

actualmente está limitado por su comunicación USB 2.0. Este proyecto esautocontenido y por ende todo el desarrollo realizado puede ser mostrado. Sinembargo por razones de confidencialidad se omiten del mismo el nombre de la

empresa, las personas que trabajan en la misma y ciertos detalles respecto alsistema que se busca mejorar.

La realización de este trabajo está basada en gitlab aplicándolo no solo comocontrol de versión, sino también como sistema de documentación del proyecto,gestión de las tareas y seguimiento de avance. Se utilizó un diseño modular, con

pruebas unitarias, de integración y de validación. Para el registro de losrequerimientos, los ensayos y su trazabilidad se utilizó el programa TestLink. Se

utilizaron conocimientos de programación en VHDL, C, JAVA y Matlab,máquinas de estados, políticas de arbitraje tipo Round-Robin, compilación de

bibliotecas utilizando GCC y se diseñó un sistema multithread para el softwarede prueba.

V

Agradecimientos

En primer lugar deseo expresar mi agradecimiento al director de este trabajo,el Mg. Ing. Diego Javier Brengi y al codirector, el Ing. Salvador Tropea por susconsejos, sus aportes y por el tiempo dedicado a este trabajo.

Deseo agradecer también al Dr. Ing Ariel Lutenberg por sus numerosos aportesen la revisión de esta memoria.

Por último, deseo agradecer al Mg. Ing. Pablo Ridolfi, al Mg. Ing. Facundo Larosay al Dr. Ing. Pablo Gomez por aceptar ser jurados de este trabajo concediendo almismo parte de su tiempo para analizarlo y corregirlo.

VII

Índice general

Resumen III

1. Introducción General 11.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2. Objetivos y alcance . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2. Introducción Específica 52.1. Requerimientos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2. Diagrama general del sistema . . . . . . . . . . . . . . . . . . . . . . 52.3. Descripción de las tecnologías involucradas . . . . . . . . . . . . . . 7

2.3.1. Descripción del bus de comunicación del FT601 . . . . . . . 72.3.2. Descripción del JNI . . . . . . . . . . . . . . . . . . . . . . . . 102.3.3. El garbage collector de Java . . . . . . . . . . . . . . . . . . . 13

3. Diseño e Implementación 153.1. Metodología de trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.1.1. Gestión del proyecto en Gitlab . . . . . . . . . . . . . . . . . 153.1.2. Documentación del diseño embebida en el proyecto . . . . . 183.1.3. Pruebas unitarias . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.2. Hardware prototipo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.2.1. Diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.2.2. Prueba de validación . . . . . . . . . . . . . . . . . . . . . . . 23

3.3. Firmware de comunicación . . . . . . . . . . . . . . . . . . . . . . . 263.3.1. Bloque communication . . . . . . . . . . . . . . . . . . . . . 263.3.2. Bloque usbArbitrer . . . . . . . . . . . . . . . . . . . . . . . . 283.3.3. Bloque usbWrite . . . . . . . . . . . . . . . . . . . . . . . . . 333.3.4. Bloque usbRead . . . . . . . . . . . . . . . . . . . . . . . . . . 393.3.5. Bloque usbFIFO . . . . . . . . . . . . . . . . . . . . . . . . . . 45

3.4. Firmware de ensayos . . . . . . . . . . . . . . . . . . . . . . . . . . . 483.4.1. Protocolo de comunicación . . . . . . . . . . . . . . . . . . . 483.4.2. Diseño del firmware de ensayos . . . . . . . . . . . . . . . . 51

3.5. Biblioteca de comunicación en Java . . . . . . . . . . . . . . . . . . . 523.6. Software de ensayo en Java . . . . . . . . . . . . . . . . . . . . . . . 553.7. Portabilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

4. Ensayos y resultados 594.1. Configuración del FT601 . . . . . . . . . . . . . . . . . . . . . . . . . 594.2. Pruebas de velocidad . . . . . . . . . . . . . . . . . . . . . . . . . . . 604.3. Prueba de largo de buffer . . . . . . . . . . . . . . . . . . . . . . . . 61

5. Conclusiones 675.1. Trabajo realizado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 675.2. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

VIII

A. Información adicional del Hardware Prototipo 69A.1. Esquemáticos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69A.2. Lista de materiales . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70A.3. Armado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70A.4. Conexión entre el UMF601A-B y el DK-DEV-3C120N . . . . . . . . 71

Bibliografía 73

IX

Índice de figuras

1.1. Diagrama en bloques del equipo a mejorar. . . . . . . . . . . . . . . 21.2. Diagrama en bloques del equipo mejorado. . . . . . . . . . . . . . . 2

2.1. Diagrama general del sistema. . . . . . . . . . . . . . . . . . . . . . . 62.2. Escritura de datos en el FT601, la FPGA termina la transacción . . . 82.3. Escritura de datos en el FT601, el FT601 termina la transacción . . . 82.4. Lectura de datos del FT601, la FPGA termina la transacción . . . . . 92.5. Lectura de datos del FT601, el FT601 termina la transacción . . . . . 92.6. JNI equivalencia de tipos de datos primitivos . . . . . . . . . . . . . 112.7. JNI equivalencia de Objetos . . . . . . . . . . . . . . . . . . . . . . . 11

3.1. Modelo de ramas elegido para los repositorios git1. . . . . . . . . . 163.2. Demostración del uso del modelo de ramas en el proyecto2. . . . . 173.3. Ejemplo de tareas de Gitlab3. . . . . . . . . . . . . . . . . . . . . . . 173.4. Milestones en Gitlab . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.5. Documentación mediante wikis de Gitlab . . . . . . . . . . . . . . . 193.6. Ejemplo de diseño de un caso de uso de un bloque VHDL. . . . . . 203.7. Ejemplo de salida simulada. . . . . . . . . . . . . . . . . . . . . . . . 213.8. Convertidor de nivel en serie con la señal de clock del FT601. . . . . 223.9. Foto del hardware del proyecto . . . . . . . . . . . . . . . . . . . . . 223.10. Diagrama en bloques de Communication.vhd. . . . . . . . . . . . . 263.11. Diagrama de estados usbArbitrer.vhd. . . . . . . . . . . . . . . . . . 313.12. Canal solicitando el uso del bus del FT601. . . . . . . . . . . . . . . 323.13. Round-Robin entre dos canales para el uso del bus del FT601. . . . . 323.14. Round-Robin entre dos canales para el uso del bus del FT601. . . . . 333.15. UsbWirte, transacción que comienza por FIFO no vacía y termina

por FIFO vacía. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353.16. UsbWirte, transacción que comienza por FT601 no lleno y termina

por FT601 lleno. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.17. UsbWirte, transacción que comienza luego del terminar por FT601

lleno y termina por busGranted=0. . . . . . . . . . . . . . . . . . . . 363.18. Diagrama de estados usbWrite.vhd. . . . . . . . . . . . . . . . . . . 373.19. UsbRead, transacción que comienza por FIFO no llena y termina

por FIFO llena. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413.20. UsbRead, transacción que comienza por FT601 no lleno y termina

por FT601 lleno. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413.21. UsbRead, transacción que comienza por busGranted=1 y termina

por busGranted=0. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423.22. Diagrama de estados usbRead.vhd. . . . . . . . . . . . . . . . . . . . 433.23. Escritura en la FIFO. . . . . . . . . . . . . . . . . . . . . . . . . . . . 473.24. Lectura de la FIFO. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483.25. Diagrama en bloques firmware de ensayos. . . . . . . . . . . . . . . 513.26. Diagrama en bloques software de ensayos. . . . . . . . . . . . . . . 55

X

4.1. Configuración del FT601 para pruebas de 1 canal. . . . . . . . . . . 594.2. Ancho de banda vs largo de paquete. . . . . . . . . . . . . . . . . . . 614.3. Largo de buffers vs largo de paquete para un canal. . . . . . . . . . 624.4. Largo de buffers vs largo de paquete para dos canales. . . . . . . . 624.5. Largo de buffers vs largo de paquete para cuatro canales. . . . . . . 634.6. Tiempo de buffers vs largo de paquete para un canal. . . . . . . . . 644.7. Tiempo de buffers vs largo de paquete para dos canales. . . . . . . 654.8. Tiempo de buffers vs largo de paquete para cuatro canales. . . . . . 65

A.1. Esquemático del Hardware prototipo . . . . . . . . . . . . . . . . . 69A.2. Instrucciones de armado del hardware . . . . . . . . . . . . . . . . . 70A.3. Vista 3D del hardware . . . . . . . . . . . . . . . . . . . . . . . . . . 71

XI

Índice de Tablas

2.1. Señales del FT601 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.1. Asignaciones adicionales del firmware de validación del hardware 233.2. Resultados prueba de validación . . . . . . . . . . . . . . . . . . . . 253.3. Parámetros del bloque communication.vhd . . . . . . . . . . . . . . 273.4. Ancho de banda máximo vs parámetros de configuración . . . . . . 283.5. Señales del bloque Communication.vhd . . . . . . . . . . . . . . . . 283.6. Parámetros del bloque usbArbitrer . . . . . . . . . . . . . . . . . . . 293.7. Señales del bloque usbArbitrer . . . . . . . . . . . . . . . . . . . . . 303.8. Estados y salidas de usbArbitrer.vhd . . . . . . . . . . . . . . . . . . 313.9. Señales internas usbArbitrer.vhd . . . . . . . . . . . . . . . . . . . . 313.10. Señales del bloque usbWrite . . . . . . . . . . . . . . . . . . . . . . . 343.11. Estados y salidas de usbWrite.vhd, parte 1 de 3 . . . . . . . . . . . . 373.12. Estados y salidas de usbWrite.vhd, parte 2 de 3 . . . . . . . . . . . . 383.13. Estados y salidas de usbWrite.vhd, parte 3 de 3 . . . . . . . . . . . . 383.14. Señales internas usbWrite.vhd . . . . . . . . . . . . . . . . . . . . . . 383.15. Señales del bloque usbRead, parte 1 de 2 . . . . . . . . . . . . . . . . 393.16. Señales del bloque usbRead, parte 2 de 2 . . . . . . . . . . . . . . . . 403.17. Estados y salidas de usbRead.vhd, parte 1 de 3 . . . . . . . . . . . . 433.18. Estados y salidas de usbRead.vhd, parte 2 de 3 . . . . . . . . . . . . 443.19. Estados y salidas de usbRead.vhd, parte 3 de 3 . . . . . . . . . . . . 443.20. Señales internas usbRead.vhd . . . . . . . . . . . . . . . . . . . . . . 443.21. Palabra de las FIFOs . . . . . . . . . . . . . . . . . . . . . . . . . . . 453.22. Señales del bloque usbFIFO . . . . . . . . . . . . . . . . . . . . . . . 463.23. Señales del bloque usbFIFO, parte 1 de 2 . . . . . . . . . . . . . . . . 463.24. Señales del bloque usbFIFO, parte 2 de 2 . . . . . . . . . . . . . . . . 473.25. Paquetes del protocolo de comunicación . . . . . . . . . . . . . . . . 483.26. Computo del checksum . . . . . . . . . . . . . . . . . . . . . . . . . 493.27. Tipos de paquetes del protocolo . . . . . . . . . . . . . . . . . . . . . 493.28. Configuración de las pruebas . . . . . . . . . . . . . . . . . . . . . . 50

4.1. Parámetros de configuración del FT601 . . . . . . . . . . . . . . . . 60

5.1. Cantidad de recursos utilizados por la biblioteca . . . . . . . . . . . 68

A.1. Lista de materiales del hardware prototipo . . . . . . . . . . . . . . 70A.2. Conexión entre el UMF601A-B y el DK-DEV-3C120N . . . . . . . . 71A.3. Conexión entre el UMF601A-B y el DK-DEV-3C120N Cont. . . . . . 72

1

Capítulo 1

Introducción General

Este capítulo introduce al lector al tema abordado por este trabajo, su propósito ysu alcance.

1.1. Introducción

La empresa para la que trabaja el autor de este trabajo se encuentra actualmentefabricando un equipo que utiliza una comunicación USB 2.0 para enviar datos auna computadora a una velocidad de 320 Mbps. Para poder mejorar este equipoy darle en el mediano plazo nuevas funcionalidades que mantengan o aumen-ten la competitividad del equipo en el mercado, se prevé que va a ser necesarioaumentar este ancho de banda al menos 4 veces, llegando a un mínimo de 1280Mbps.

Al igual que se hizo en su momento con la comunicación USB 2.0 lo que se buscóen este trabajo fue realizar un prototipo que pusiera a prueba la comunicaciónUSB 3.0 para determinar que se puede llegar al ancho de banda requerido con unhardware, firmware y software desarrollados por la empresa.

Cuando se habla de un ancho de banda mínimo de 1280 Mbps se hace referenciaal ancho de banda para un flujo de datos continuo, no de ráfaga. Es decir, cuandose active el equipo este comenzará a enviar datos hacia la computadora a 1280Mbps en forma continua por el lapso típico de operación de 3 a 5 minutos sininterrupciones.

La Figura 1.1 ilustra el diagrama en bloques del equipo que se quiere mejorar. Enla misma se puede ver que el sistema posee una FPGA conectada a una compu-tadora con sistema operativo Windows utilizando un FT232H1 de FTDI. El equiporequiere un alto ancho de banda para enviar datos desde la FPGA hacia la PC. Encambio, en la dirección contraria, que es utilizada para configurar el equipo, lavelocidad puede ser baja.

1http://www.ftdichip.com/Products/ICs/FT232H.htm

http://www.ftdichip.com/Products/ICs/FT232H.htm

2 Capítulo 1. Introducción General

FIGURA 1.1: Diagrama en bloques del equipo a mejorar.

En la Figura 1.2 se muestra el diagrama en bloques de como quedaría el sistematras esta modificación. Como se puede ver es muy similar al diagrama anteriorpero en este caso se cambia el chip utilizado para la comunicación por el FT601Q2

de FTDI. El mismo tiene un concepto de funcionamiento similar al FT232H, peropara USB 3.0. El bus de comunicación con la FPGA es distinto dado que tiene máspines en paralelo y mayor velocidad de clock para poder alcanzar las velocidadesde Super Speed. También se puede ver en este diagrama en bloques que se agregacomo opcional en este proyecto la posibilidad de utilizar este sistema tambiénen Linux. En el sitio de FTDI los drivers están disponibles tanto Windows comopara Linux y dado que el back-end está programado en Java debería ser posiblerealizar las mismas pruebas en Linux.

FIGURA 1.2: Diagrama en bloques del equipo mejorado.

Todas las implementaciones discutidas en este trabajo serán aplicadas en siste-mas operativos de propósito general y no en sistemas operativos de tiempo real.Es decir, no se puede garantizar que el ancho de banda se cumpla el 100 % deltiempo. Lo que se buscó es que en condiciones normales del sistema operativoy en una computadora con características similares a la que se utilizará con elproducto, el ancho de banda continuo promedio sea 1280 Mbps.

1.2. Objetivos y alcance

El objetivo de este proyecto consistió en la realización de un prototipo de comu-nicación USB 3.0 entre una FPGA y una computadora que cumplió con todos losrequerimientos que serán presentados en la Sección 2.1. Su validación exitosa per-mite en un futuro incorporarlo al equipo actual mejorando la competitividad delmismo.

Para este proyecto se diseñó e implementó una biblioteca de firmware3 en VHDLcapaz de manejar las señales del chip encargado de la comunicación USB 3.0, colo-car los datos recibidos desde la PC en una cola FIFO (First In First Out: el primeroen entrar es el primero en salir) de recepción y enviar a la PC los datos colocados

2http://www.ftdichip.com/Products/ICs/FT600.html3En este trabajo se referirá al código VHDL compilado corriendo en la FPGA como Firmware

http://www.ftdichip.com/Products/ICs/FT600.html

1.2. Objetivos y alcance 3

en una FIFO de salida. La implementación de está biblioteca fue modular y cadamódulo fue probado en forma unitaria.

Se programó también un software en Java y un firmware VHDL para implemen-tar las pruebas de validación propuestas para el sistema. El protocolo utilizado enlas pruebas del equipo fue diseñado únicamente con el objetivo de validar la bi-blioteca desarrollada. Si bien puede ser utilizado por los futuros usuarios de estabiblioteca, no ha sido pensado en forma genérica y sería recomendable adaptarloo mejorarlo para su futura utilización.

Se dejó documentado todo el hardware utilizado y su conexionado para su futu-ra utilización, ya sea para incorporarlo en los PCBs del equipo actual como parapoder repetir las pruebas realizadas. Para este proyecto no se diseñaron ni fabri-caron PCBs sino que el hardware fue construido mediante la interconexión de kitsde desarrollo.

5

Capítulo 2

Introducción Específica

Este capítulo provee una introducción más detallada de todo el trabajo realizado.Se presenta al lector los requerimientos de aceptación fijados sobre el proyecto,un diagrama en bloques de todo el trabajo y por último una explicación de lastecnologías adicionales involucradas en el desarrollo.

2.1. Requerimientos

1. Requerimientos de validación.

1.1 La velocidad promedio de datos debe superar los 1280 Mbps en el lap-so de 5 minutos seguidos.

1.2 La tasa de Bytes erróneos debe ser 0 en el lapso de 5 minutos.

2. Requerimientos funcionales.

2.1 Obtener la mayor tasa de transferencia que se puede lograr con esteprototipo.

2.2 Generar una prueba que permita determinar el tamaño mínimo de losbuffers internos para las distintas tasas de transferencia.

3. Requerimientos de metodología de trabajo.

3.1 Utilizar GIT para el control de cambios.

3.2 Realizar un diseño de firmware modular.

3.3 Realizar test unitarios de cada módulo.

2.2. Diagrama general del sistema

En la Figura 2.1 se puede apreciar el diagrama en bloques completo de todo elproyecto. Como se puede ver, el hardware consta de dos kits de desarrollo, elDK-DEV-3C120N1 y el UMFT601A-B2. El primero posee una FPGA CYCLONEIII EP3C1203 de Altera que consta de un firmware cuyo diseño y desarrollo es

1https://www.altera.com/products/boards_and_kits/dev-kits/altera/kit-cyc3.html2http://www.ftdichip.com/Products/Modules/SuperSpeedModules.htm3https://www.altera.com/products/fpga/cyclone-series/cyclone-iii/features.html

https://www.altera.com/products/boards_and_kits/dev-kits/altera/kit-cyc3.html

http://www.ftdichip.com/Products/Modules/SuperSpeedModules.htm

https://www.altera.com/products/fpga/cyclone-series/cyclone-iii/features.html

6 Capítulo 2. Introducción Específica

explicado en las Secciones 3.3 y 3.4. El segundo posee un chip FT601, cuya inter-face física de comunicación con la FPGA es explicada en la Subsección 2.3.1. Ladescripción detallada del hardware se encuentra en la Sección 3.2.

FIGURA 2.1: Diagrama general del sistema.

A nivel del software en la Figura 2.1 se puede ver que la comunicación USB 3.0 esmanejada por un driver provisto por el fabricante. Dicho driver es una bibliotecade C y para poder utilizarla en Java es necesaria la adaptación mediante un wrap-per. Qué es un wrapper, porqué debe utilizarse y que herramientas provee Javapara implementarlo son preguntas que son respondidas en la Subsección 2.3.2.Los detalles particulares de la implementación del wrapper son abordados en laSección 3.5.

2.3. Descripción de las tecnologías involucradas 7

2.3. Descripción de las tecnologías involucradas

2.3.1. Descripción del bus de comunicación del FT601

Como puede verse en [7], para comunicarse con la FPGA el FT601 tiene un busparalelo que puede configurarse de dos modos, el 245 Synchronous FIFO y elMulti-Channel FIFO. El primero de ellos es un modo compatible con otros chipsmás viejos de FTDI. El segundo es un protocolo nuevo introducido por por estechip y que tiene la ventaja de permitir el uso de múltiples canales de comunica-ción. Para este trabajo se eligió utilizar el segundo modo dada la flexibilidad quepuede permitir a los usuarios de la biblioteca la existencia de varios canales. LaTabla 2.1 muestra la función de cada una de las señales de control del FT601 en elmodo Muti-Channel FIFO.

TABLA 2.1: Señales del FT601 para el modo Multi-Channel FIFO

Señal Tipo Descripción

CLK Out Clock del bus de comunicaciónWRn In Pedido de transacciónRXFn Out Indica lectura o escritura valida en las FIFOsDATA[31:0] InOut Datos de la comunicación o estado de las FIFOsBE[3:0] InOut Bytes de DATA válidos o número de canalTXEn Out Indica que en DATA está el estado de las FIFOsOEn In No utilizada en modo Muti-Channel FIFORDn In No utilizada en modo Muti-Channel FIFOSIWUn In No utilizada en modo Muti-Channel FIFO

En este modo de operación el FT601 es manejado por la FPGA mediante transac-ciones. Dichas transacciones pueden ser de lectura o de escritura y la cantidad debytes a escribir o leer no es conocida a priori.

El comienzo de estas transacciones es comandado por la FPGA poniendo en ’0’la señal WRn. El final en cambio puede ser comandado tanto por la FPGA comopor el FT601. Si la FPGA no tiene más datos para escribir, o no puede leer másdatos del FT601, pone la señal WRn en ’1’ indicando el final de la transacción. Siel FT601 no tiene más datos para enviar, o no puede recibir más datos de la FPGA,pone la señal RXFn en ’1’ para finalizar la transacción.

Mientras la señal TXEn está en ’0’, el FT601 coloca en DATA[15] a DATA[12] el es-tado de las FIFOs de recepción de los canales 4 a 1 respectivamente y en DATA[11]a DATA[8] el estado de las FIFOs de transmisión de los canales 4 a 1 respectiva-mente. Por ejemplo si DATA[15] = ’0’, el canal 4 tiene datos para enviar a la FPGA,si DATA[9] = ’0’, el canal 2 puede recibir datos para enviar a la PC.

La Figura 2.2 muestra una transacción de escritura de 14 bytes en el FT601, dondela FPGA termina la transacción. Como se puede ver en la misma, mientras la señalTXEn está en ’0’, el FT601 pone ’0xFE’ en DATA[15:8] indicando que hay lugar enel canal 1 para enviar datos a la PC.

Para comenzar la transacción la FPGA pone en ’0’ la señal WRn, indica con ’0x1’en BE[3:0] que se va a escribir el FT601 y coloca en DATA[7:0] el número de canal


que se va a escribir. Dos ciclos de clock después el FT601 indica que está listo pararecibir los datos bajando la señal RXFn.

Mientras RXFn y WRn estén en ’0’ los bytes válidos de DATA[31:0] serán escritosen la FIFO del FTDI para ser enviados a la PC. En cada ciclo de clock la FPGAindica con la señal BE[x] si el byte x de DATA es válido.

En este caso particular en el cuarto ciclo de transferencia de datos, la FPGA sequeda sin datos a enviar, coloca solo 2 bytes válidos, BE[3:0] = ’0x3’, y en el si-guiente ciclo de clock pone la señal WRn en ’1’ indicando final de transacción. Porúltimo el FT601 pone en ’1’ la señal RXFn aceptando el final de la transacción.

FIGURA 2.2: Escritura de datos en el FT601, la FPGA termina latransacción[7].

La Figura 2.3 muestra una transacción de escritura de 16 bytes en el FT601, dondeel FT601 termina la transacción. La diferencia con la Figura 2.2 ocurre cuando enel quinto ciclo de escritura, el FT601 pone la señal RXFn en ’1’ indicando que notiene más lugar en su FIFO para guardar los datos que recibe de la FPGA. Losdatos colocados en DATA cuando RXFn se puso en ’1’ no fueron leídos por elFT601 y deben ser reenviados cuando sea posible. Un ciclo después de que laseñal RXFn se pone en ’1’ la FPGA debe poner en ’1’ la señal WRn aceptando elfinal de la transacción.

FIGURA 2.3: Escritura de datos en el FT601, el FT601 termina latransacción[7].

Las transferencias de lectura de datos son similares a las de escritura. La Figu-ra 2.4 muestra una transacción de lectura de 12 bytes del FT601, donde la FPGAtermina la transacción. Las principales diferencias con la Figura 2.2 son que enprimer lugar cuando TXEn está en ’0’ el FT601 pone ’0xEF’ en DATA[15:8] indi-cando que la FIFO de recepción del canal 1 tiene datos para enviar a la FPGA.

Luego al comenzar la transacción bajando la señal WRn, la FPGA coloca en BE[3:0] el valor ’0x0’ indicando que se van a leer datos, solo por un ciclo de clock,y luego se debe esperar dos ciclos de clock hasta que el FT601 baje la señal RXFn


indicando que en DATA hay datos válidos. Es importante remarcar que duranteestos últimos dos ciclos de clock la FPGA debe poner las señales BE y DATA comoentrada. Por último durante la lectura de datos, es ahora el FT601 quien coloca losdatos en DATA[31:0] y BE[3:0]. Nuevamente BE[x] indica si el byte x de DATA esválido y debe ser almacenado.

Por último, luego del tercer ciclo de clock la FPGA sube la señal WRn indican-do que no puede recibir más datos del FT601. Los datos que estaban en DATAcuando la FPGA sube la señal WRn no deben ser guardados, el FT601 será elencargado de volverlos a colocar en DATA cuando sea oportuno.

FIGURA 2.4: Lectura de datos del FT601, la FPGA termina la tran-sacción[7].

La Figura 2.5 muestra una transacción de 10 bytes del FT601, donde el FT601termina la transacción. A diferencia de la Figura 2.2, en este caso durante el tercerciclo de lectura de datos el FT601 coloca en BE[3:0] el valor ’0x3’ indicando quesolo DATA[15:0] tiene datos válidos. En el ciclo siguiente el FT601 se queda sindatos a colocar y sube la señal RXFn para terminar la transacción. La FPGA debedescartar los datos DATA que ocurrieron cuando RXFn estaba en ’1’ y en el ciclosiguiente debe subir la señal WRn para aceptar el fin de la transacción.

FIGURA 2.5: Lectura de datos del FT601, el FT601 termina la tran-sacción[7].


2.3.2. Descripción del JNI

El fabricante de FT601 provee el driver D3XX4 escrito en C para poder utilizar estedispositivo en distintos sistemas operativos. Lamentablemente Java no puede uti-lizar bibliotecas de C directamente, para poder utilizarlo es necesario implemen-tar un wrapper. Un wrapper puede ser explicado como un traductor de lenguajes.Es decir, entiende ambos lenguajes y es el encargado de convertir los datos de unlenguaje al otro. En particular para implementar un wrapper de un Algoritmo enC, Java provee lo que define como JNI5 (Java Native Interface). En los siguientespárrafos se mostrará un ejemplo sencillo del JNI y algunos detalles que fueronútiles en la resolución de este proyecto.

Supongamos que se dispone de una biblioteca ’myClib’ cuyo archivo de encabe-zados es ’myLib.h’. Se quiere llamar desde Java a una función de esta bibliotecade C que escribe datos en un arreglo de bytes, cuyo prototipo es 2.1.

1 i n t readData ( byte∗ data , i n t length ) ;

ALGORITMO 2.1: Protipo función de C a llamar desde Java

En primer lugar se debe crear un archivo Java ’myClib.java’ que cargue el wrapperde C que y contenga un método definido como se puede ver en el Algoritmo 2.2.El bloque de las líneas 2 a 4 es el encargado de cargar el wrapper escrito en Cutilizando el JNI. La línea 4 es la encargada de decirle al Java que el métodoreadData no está escrito en Java y debe cargarlo de una biblioteca nativa.

1 package myClib ;2 publ ic c l a s s MyClib {3 s t a t i c {4 System . loadLibrary ( " myClibWrapper " ) ;5 }6 publ ic nat ive i n t readData ( byte [ ] bytes , i n t length ) ;7 }

ALGORITMO 2.2: Codigo fuente de Java del wrapper

Luego se debe crear un archivo ’myClibWrapper.h’ que contiene el prototipo dela función readData pero con los tipos de datos que son compatibles con Java. ElAlgoritmo 2.3 muestra un ejemplo de dicho archivo.

1 # include < j n i . h>2 JNIEXPORT j i n t JNICALL Java_myClib_MyClib_readData ( JNIEnv ∗ , j o b j e c t ,3 jbyteArray , j i n t ) ;

ALGORITMO 2.3: Encabezado en C del wrapper

Es importante respetar los siguientes temas de esta sintaxis. En primer lugar elJNIEXPORT y el JNICALL deben estar siempre como primer y tercer palabra an-tes del nombre de la función. La segunda palabra antes del nombre de la funciónes el tipo de dato que devuelve la función. En este caso en el archivo MyClib.javase define que el método readData devuelve int, para la JNI los tipos de datos intde Java deben ser utilizados como jint en C. La Figura 2.6 muestra la equivalenciaentre los tipos de datos primitivos de Java en C.

4http://www.ftdichip.com/Drivers/D3XX.htm5https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/jniTOC.html6https://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/types.html

http://www.ftdichip.com/Drivers/D3XX.htm

https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/jniTOC.html

https://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/types.html


FIGURA 2.6: JNI equivalencia de tipos de datos primitivos6.

El nombre de la función se compone de la siguiente forma: Java_[ Nombre delpaquete reemplazando los puntos por ‘_’ donde se define el método nativo]_[Nombre de la clase de Java donde de define el método nativo]_[ Nombre delmétodo nativo].

Los primeros dos parámetros deben ser incluidos siempre. El primero se lo deno-mina puntero de interface y es utilizado entre otras cosas para obtener datos delos parámetros y del objeto que llama al método nativo. El segundo, si la funciónes estática, es la clase que tiene este método y si la función no es estática, es lainstancia del objeto.

El tercer parámetro es el arreglo de bytes de Java a cargar con los datos, en estecaso el byte[] de Java se convierte jbyteArray. La Figura 2.7 muestra cuales son losequivalentes en C de los distintos tipos de objetos de Java. El último parámetroes la cantidad de bytes a copiar, como se vio en la Figura 2.6, el int de Java esequivalente al jint de C.

FIGURA 2.7: JNI equivalencia de Objetos7.

Por último se debe crear el archivo en C ’myClibWrapper.c’ con el Algoritmo 2.4:

7https://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/types.html

https://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/types.html


1 # include " myClibWrapper . h"2 JNIEXPORT j i n t JNICALL Java_myClib_MyClib_readData ( JNIEnv ∗env ,3 j o b j e c t obj , jbyteArray arr , j i n t len ) {4 j i n t r e t ;5 j b y t e ∗buf ;6 // Obtiene e l largo del array de bytes de Java7 i n t a len = (∗ env )−>GetArrayLength ( env , a r r ) ;8 // S i e l a r r e l g o de Java es mas corto , clampeamos e l largo a copiar9 i f ( a len > len ) {

10 alen = len ;11 }12 // Obtiene e l a r r e g l o de bytes del o b j e t o en Java13 buf = (∗ env )−>GetByteArrayElements ( env , arr , 0 ) ;14 // Llama a l a funcion que se queria l lamar or ig inalmente .15 r e t = readData ( buf , a len ) ;16 // Copia e l resu l tado a l arrego de bytes de Java17 (∗ env )−>ReleaseByteArrayElements ( env , arr , buf , 0 ) ;18 re turn r e t ;19 }

ALGORITMO 2.4: Fuente en C del wrapper

Lo más importante a destacar en este algoritmo ocurre en las líneas 7, 13, 15 y 17.En la línea 7 se obtiene a partir de la variable env, y arr el largo de arreglo de bytesde Java. En la línea 13 se obtienen los datos del arreglo de bytes, en general Javarealiza una copia de estos datos en lugar de darnos un puntero a los mismos. En lalínea 15 se llama finalmente a la función de C que se quería llamar originalmente.En la línea 17 se informa a Java que se terminó de modificar el arreglo de Bytes.En general Java realiza una copia de estos datos en el arreglo de bytes de Java.

Esta implementación de llenado de arreglos es la más convencional, sin embargoel hecho de estar alocando y copiando los datos no es óptimo en cuanto a tiem-pos. Para aplicaciones críticas JNI provee una función que devuelve realmente unpuntero a los datos. El Algoritmo 2.5 ilustra una implementación utilizando estafunción.

1 # include " myClibWrapper . h"2 JNIEXPORT j i n t JNICALL Java_myClib_MyClib_readData ( JNIEnv ∗env , j o b j e c t

obj ,3 jbyteArray arr , j i n t len ) {4 j i n t r e t ;5 j b y t e ∗buf ;6 // Obtiene e l largo del array de bytes de Java7 i n t a len = (∗ env )−>GetArrayLength ( env , a r r ) ;8 // S i e l a r r e g l o de Java es mas corto , truncamos e l largo a copiar9 i f ( a len > len ) {

10 alen = len ;11 }12 // Obtiene e l a r r e g l o de bytes del o b j e t o en Java13 buf = (∗ env )−>G e t P r i m i t i v e A r r a y C r i t i c a l ( env , arr , 0 ) ;14 // Llama a l a funcion que se queria l lamar or ig inalmente .15 r e t = readData ( buf , a len ) ;16 // Copia e l resu l tado a l arrego de bytes de Java17 (∗ env )−>R e l e a s e P r i m i t i v e A r r a y C r i t i c a l ( env , arr , buf , 0 ) ;18 re turn r e t ;19 }

ALGORITMO 2.5: Fuente en C del wrapper utilizandoPrimitiveArrayCritical


El algoritmo es muy similar al anterior, el único cambio ocurre en las líneas 13 y17. Si bien el cambio parece menor las consecuencias pueden ser muy significa-tivas en cuanto a tiempos de procesamiento y muy catastróficas si se utiliza estosin tener el cuidado adecuado. Se debe tener en cuenta que en este caso la varia-ble ’buf’ contiene un puntero a los datos del arreglo de bytes de java. Para poderentregar este puntero Java detiene ciertas funciones críticas desde el llamado aGetPrimitiveArrayCritical hasta que se llame a la función ReleasePrimitiveArray-Critical, es por eso que se recomienda que el tiempo entre la llamada a estas dosfunciones sea lo más corto posible. Los llamados a estas funciones deben estarsiempre apareados, un llamado a GetPrimitiveArrayCritical sin su respectivo lla-mado a ReleasePrimitiveArrayCritical puede resultar en bloqueo de la JVM (JavaVirtual Machine).

2.3.3. El garbage collector de Java

Otro tema que debió ser tenido en cuenta durante la realización de este trabajoes el garbage collector de Java. A diferencia de leguajes como C, en Java no esnecesario liberar la memoria de los objetos que ya no se utilizan. Siguiendo ciertaspolíticas, Java ejecuta esporádicamente su GC (Garbage Collector). Durante sullamada, todos los threads de Java son detenidos y el GC recorre todos los objetosy libera de la memoria todos aquellos objetos que nadie más está utilizando.

En la mayoría de las aplicaciones el tiempo de ejecución del GC es corto y raravez el usuario se da cuenta de su existencia. Sin embargo en este trabajo se recibenmás de 1280 Mbps, es decir que se genera 1GB de datos cada 6 segundos. Por endemientras se dejó que el GC se encargara de manejar la liberación de 1GB de datoscada 6 segundos no se pudieron lograr los resultados esperados.

Para lidiar con este problema se suele utilizar en Java lo que se podría denominarun reciclado de objetos implementado por el usuario. Suponiendo un escenariodonde se sabe que por la biblioteca de comunicación llegan una gran cantidad depaquetes por segundo pero que todos tienen el mismo largo, por ejemplo 10MB.En lugar de crear un objeto nuevo cada vez que se recibe un paquete, lo quese hace es lo siguiente. Cuando el último eslabón de procesamiento termina deutilizar el objeto lo coloca en una cola de reciclaje. El proceso que crea los objetosantes de crear un objeto nuevo consulta la cola de objetos a reciclar, si no haynada en dicha cola crea un objeto nuevo, si en cambio hay un objeto a reciclar,lo recicla copiando los datos nuevos sobre este objeto en lugar de crear un objetonuevo. Una vez en estado estacionario el proceso productor no necesita crear másobjetos dado que cada vez que coloca un objeto en la cola de salida, el procesoconsumidor coloca un objeto en la cola de reciclaje. Una implementación de estetipo de procedimiento puede verse en la Sección 3.6.

15

Capítulo 3

Diseño e Implementación

En este capítulo se detalla el diseño e implementación del proyecto. Se comienzamostrando la metodología de diseño y desarrollo aplicada. Luego se explica eldiseño e implementación del hardware, de la biblioteca de comunicación y porúltimo del firmware y software de validación.

3.1. Metodología de trabajo

3.1.1. Gestión del proyecto en Gitlab

Tanto para el control de versiones como para la gestión del proyecto se eligióutilizar la herramienta Gitlab1. La razón para elegir Gitlab por sobre sus com-petidores se basó en que esta es la herramienta elegida por la empresa en la quetrabaja el autor del presente trabajo para administrar sus proyectos. Por ende todolo aprendido para este proyecto podrá ser utilizado para el trabajo y viceversa.

Gitlab brinda al proyecto en primer lugar un sistema de control de versión GIT2.Como estrategia de ramas se utilizó el modelo propuesto por Vincent Driessenque se puede ver en la Figura 3.1. Este modelo propone la creación de dos ramasprincipales llamadas develop y master. Toda nueva funcionalidad debe agregar-se en una rama que sale de la rama develop, al terminar dicha funcionalidad serealiza un merge de dicha rama en develop y se borra la rama de la nueva fun-cionalidad.

Cuando en un determinado momento la rama develop tiene todos los cambiosprevisto para la próxima versión del producto, se crea una rama release Y.XX apartir de develop. A partir de ese momento la rama release Y.XX no incorporamás funcionalidades, dado que no se realizará ningún merge de develop en estarama. El objetivo de esta nueva rama pasa a ser únicamente la puesta a punto detodas las funcionalidades agregadas en develop hasta el momento de creación deesta rama.

Cuando la rama realease Y.XX está lista se realiza un merge de esta rama en Mas-ter, generando finalmente la release Y.XX. Y luego se realiza un merge de Release

1http://www.gitlab.com2https://git-scm.com/3https://nvie.com/posts/a-successful-git-branching-model/

http://www.gitlab.com

https://git-scm.com/

https://nvie.com/posts/a-successful-git-branching-model/

16 Capítulo 3. Diseño e Implementación

FIGURA 3.1: Modelo de ramas elegido para los repositorios git3.

Y.XX en develop, incorporando a develop todas las corrección de bug que se hi-cieron en esta rama. Por último se borra la rama release Y.XX. De esta forma larama Master solo posee versiones estable del proyecto.

Si en algún momento se detecta un bug importante en una release, lo que se hacees crear un rama hotfix Y.(XX+1) que sale de la rama Master, se corrige el bug y serealiza un merge de la corrección en la rama master creando la release Y.(XX+1).Por último se realiza un merge de la rama hotfix Y.(XX+1) en develop para corre-gir el bug también en develop y se borra la rama hotfix. Esto permite corregir losbug de la versión de producción sin agregar la incerteza de incorporar cambiosque tal vez no estaban del todo probados. La Figura 3.2 muestra el uso de estetipo de modelo de ramas en este proyecto. La misma muestra la integración detres nuevas funcionalidades en la rama develop.

4https://gitlab.com/ndassieu/MSE_TPFINAL_FW/network/develop

https://gitlab.com/ndassieu/MSE_TPFINAL_FW/network/develop

3.1. Metodología de trabajo 17

FIGURA 3.2: Demostración del uso del modelo de ramas en el pro-yecto4.

El Gitlab tiene incorporada la posibilidad de crear tareas. Estas tareas a su veztienen incorporada la posibilidad de anotar el tiempo estimado y el tiempo quellevó realizarlas. A su vez cada tarea permite crear una rama donde se realizarásu implementación. La Figura 3.3 muestra una tarea de Gitlab del proyecto, enla zona izquierda se puede ver el título y la descripción de la misma. En la zonaderecha se puede ver su tiempo estimado y el tiempo que llevó realizarla. Porúltimo en la zona inferior se puede ver que tiene un Merge Request asociado y queeste solucionó la tarea en cuestión.

FIGURA 3.3: Ejemplo de tareas de Gitlab5.

Otra funcionalidad muy útil que provee el Gitlab son los denominados Milestones.Estos permiten administrar las tareas que se quieren realizar para una determi-nada fecha. Combinado con una correcta estimación de los tiempos de las tareaspermite evaluar si se va a llegar o no cumplir con las fechas de entrega. La Figura3.4 muestra el milestone de la release 1.00 de este proyecto donde se muestra un

5https://gitlab.com/ndassieu/MSE_TPFINAL_FW/issues/9

https://gitlab.com/ndassieu/MSE_TPFINAL_FW/issues/9


gráfico de avance de las tareas en función del tiempo. Y por debajo del gráficose muestran las tareas por hacer, las que se están haciendo y las que ya fueronrealizadas para este milestone.

FIGURA 3.4: Milestones en Gitlab

3.1.2. Documentación del diseño embebida en el proyecto

Dónde almacenar la documentación de un proyecto siempre es algo problemáti-co. En general los documentos quedan en alguna computadora, mientras el pro-yecto es mantenido mediante el sistema de control de versión. Mantener una do-cumentación mediante archivos binarios de Word o similar en el repositorio sueleser problemático dado que los mismos no pueden ser integrados con facilidad siocurre un conflicto durante un merge.

3.1. Metodología de trabajo 19

Gitlab provee una alternativa que ha sido puesta a prueba en este proyecto. Estaes utilizar las wikis de Gitlab como lugar donde realizar la documentación. Estaswikis se escriben en un lenguaje llamado Markdown que permite la realizaciónde Tablas, embeber imágenes y vídeos y adjuntar todo tipo de archivos binariosque pueden ser descargados posteriormente. Se pueden colocar también links atareas del proyecto, a commits específicos, a otras wikis y a sitios web en general.

Por último todas estas wikis tiene su propio sistema de control de versión, y porende en cualquier momento se pueden ver los cambios realizados sobre cualquie-ra de las páginas. Todo esto genera un sistema muy flexible de documentación. LaFigura 3.5 muestra una pagina de la wiki de Gitlab con parte de la documentaciónde uno de los módulos de firmware desarrollados.

FIGURA 3.5: Documentación mediante wikis de Gitlab

3.1.3. Pruebas unitarias

Cada módulo de la biblioteca fue realizado comenzando por su diseño documen-tado en Gitlab. En dicho diseño no solo se plantearon las máquinas de estado, olas lógicas del bloque, sino que también se diagramaron ciertos casos de uso conlas entradas y salidas esperadas.

De esta forma antes de comenzar a codificar el módulo, ya se tenía claro lo quetenía que hacer y como ponerlo a prueba. La Figura 3.6 muestra un ejemplo deldiagrama de salidas esperadas de uno de los bloques implementados para estetrabajo.


FIGURA 3.6: Ejemplo de diseño de un caso de uso de un bloqueVHDL.

Terminada la fase de diseño de cada bloque se procedió a la implementación enVHDL del bloque y de su respectiva prueba unitaria. Para la implementaciónde la prueba unitaria se utilizaron ’asserts’ para generar errores de simulacióncuando un valor no era el esperado. El Algoritmo 3.1 es un ejemplo de como segeneraron los errores cuando un valor no era el esperado.

1 a s s e r t busRequest = busRequestExpeted2 repor t3 " Unexpected r e s u l t : " & " busRequest = " & s t d _ l o g i c ’ image ( busRequest )4 & " ; " & " expeted = " & s t d _ l o g i c ’ image ( busRequestExpeted )5 s e v e r i t y e r r o r ;

ALGORITMO 3.1: Generación de errores de simulación en VHDL

Como se puede ver en la Figura 3.7 el mismo caso de uso es luego simuladoutilizando el modelsim y el resultado es idéntico al de la Figura 3.6.

3.2. Hardware prototipo 21

FIGURA 3.7: Ejemplo de salida simulada.

3.2. Hardware prototipo

3.2.1. Diseño

El FT601 tiene disponible dos kits de desarrollo oficiales6, estos son el UMFT601A-B y UMFT601X-B. La principal diferencia entre ellos es el tipo de conec-tor para conectarse al dispositivo que lo controlará. En particular el el primerode ellos posee un conector HSMC (High Speed Mezzanine Card)7 que suele serutilizado por los kits de desarrollo de Altera.

En proyectos anteriores se utilizó el kit de desarrollo de Altera DK-DEV-3C120N8

que posee este tipo de conector. Mediante una revisión de los manuales [1] y[10] se constató que el pinout del conector HSMC A del DK-DEV-3C120N eracompatible con CN4 del UMFT601A-B y se optó entonces por la utilización deestos dos kits de desarrollo. En el apéndice A se pueden ver los esquemáticos, elBOM y como ensamblar estos kits de desarrollo. En particular la Subsección A.4se puede ver como quedan conectadas todas las señales desde el FT601A hasta laFPGA CYCLONE III.

6http://www.ftdichip.com/Products/Modules/SuperSpeedModules.htm7https://www.altera.com/en_US/pdfs/literature/ds/hsmc_spec.pdf8https://www.altera.com/products/boards_and_kits/dev-kits/altera/kit-cyc3.html

http://www.ftdichip.com/Products/Modules/SuperSpeedModules.htm

https://www.altera.com/en_US/pdfs/literature/ds/hsmc_spec.pdf

https://www.altera.com/products/boards_and_kits/dev-kits/altera/kit-cyc3.html


Si bien el pinout de los conectores es compatible, mirando los esquemáticos [2] dela DKDEV3C120N, en el camino de señal del clock que suministra el UMFT601ABtiene un buffer convertidor de nivel FXLP349 de ON Semiconductor. La Figura3.8 es una captura de estos esquemáticos donde se puede apreciar como está co-nectado el FXLP34 para convertir el nivel de señal HSMA_CONN_CLK_IN0 quees justamente la señal que se conecta al clock del UMFT601AB. Lamentablementeeste convertidor de nivel tiene un delay de entre 2ns y 7.4ns a 25 ◦C, lo que escasi un ciclo entero del clock de 100 MHz que suministra el UMFT601AB. Estoocasionó ciertos problemas que serán explicados en la Sección 3.2.2.

FIGURA 3.8: Convertidor de nivel en serie con la señal de clock delFT601.

La Figura 3.9 muestra como queda el hardware tras ser ensamblado.

FIGURA 3.9: Foto del hardware del proyecto

En las subsecciones A.1, A.2 y A.3 del Apéndice A se pueden consultar respec-tivamente los esquemáticos, la lista de materiales y las instrucciones de armadodel hardware prototipo.

9http://www.onsemi.com/PowerSolutions/product.do?id=FXLP34

http://www.onsemi.com/PowerSolutions/product.do?id=FXLP34


3.2.2. Prueba de validación

Para validar el hardware se utilizó dos programas y un firmware de prueba pro-vistos por FTDI10 que se presentan a continuación.

Como se puede ver en [4] el firware FIFO Bus Master for FT60 provisto fue dise-ñado para ser utilizado con una FPGA cyclone V de Altera y para un kit de desa-rrollo Altera cyclone V GX Starter Kit. Para adaptarlo al altera DK-DEV-3C120N fuenecesario regenerar el bloque de sp_ram_16k36.v y cambiar la asignación de pi-nes utilizando la información de las Tablas A.2 y A.3. El resto de las señales delfirmware fueron asignadas como se muestra en la Tabla 3.1.

TABLA 3.1: Asignaciones adicionales del firmware de validacióndel hardware

Señal FW Pin FPGA DK-DEV-3C120N

ERDIS AG23 USER_DIPSW2HRST_N T21 S5, CPU_RESETMLTCN AC14 USER_DIPSW0STREN AD18 USER_DIPSW1R_OOB AB15 USER_DIPSW6W_OOB AF25 USER_DIPSW7

STRER[3] AD19 USER_LED3STRER[2] AF18 USER_LED2STRER[1] AE20 USER_LED1STRER[0] AD15 USER_LED0

DEBUG_SIG[0] AE15 USER_LED4DEBUG_SIG[1] AC17 USER_LED5DEBUG_SIG[2] AG19 USER_LED6DEBUG_SIG[3] AE15 USER_LED4

FTDI provee dos programas FT600 Data Loopback Application y FT600 Data Strea-mer Application para utilizar con el firmware FIFO Bus Master for FT60. Sus ma-nuales de uso pueden verse en [5] y [6] respectivamente.

El software FT600 Data Loopback Application provee una prueba de eco, es decirenvía un paquete conocido y el firmware devuelve el mismo paquete. Para podercorrerlo se requieren hacer los siguientes pasos:

1. Configurar la placa UMFT601A.

1.1 JP1 =>Abierto

1.2 JP2 =>Posición 2-3


1.4 JP4 y JP5 =>Posición H

2. Configurar la placa DK-DEV-3C120N.

2.1 SW0 =>En ’1’

10http://www.ftdichip.com/Support/SoftwareExamples/FT60X.htm

http://www.ftdichip.com/Support/SoftwareExamples/FT60X.htm


2.2 SW1 =>En ’0’

2.3 SW2 =>En ’1’

2.4 SW6 =>En ’0’

2.5 SW7 =>En ’0’

3. Configurar el FT601.

3.1 Abrir el programa “FT600ChipConfigurationProg.exe”.

3.2 Presionar el boton “Read Configuraction”

3.3 Configurar los siguientes ítems:

1) FIFO Clock 66 MHz

2) FIFO Mode 600 Mode

3) Channel Config 4

4) Destildar Ignore Session Underrun

3.4 Presionar Write Configuration

4. Programar la FPGA con el firmware de prueba de HW: “mst_fifo_top.sof”

5. Abrir el programa "FT600DataLoopbackDemoApp.exe"

6. Presionar el boton "Start All"

Cuando se realizó esta prueba con el FIFO Clock en 100 MHz se obtuvo un re-sultado de error indicando que los datos leídos no eran válidos. En cambio conel clock de 66 MHz los datos eran válidos. Esto se debe al conversor de nivel, queque tiene el kit de desarrollo DK-DEV-3C120N en el clock que, se como se vio enla Subsección 3.2.1 tiene casi un ciclo de clock de delay. Afortundamente confi-gurando el clock en 66 MHz el delay no es suficientemente alto como para hacerfallar la comunicación.

El software FT600 Data Streamer Application tiene como objetivo mostrar qué an-cho de banda logra el FT601 con el firmware provisto por FTDI. Para correrlo esnecesario realizar los siguientes pasos:

1. Configurar la placa UMFT601A.

1.1 JP1 =>Abierto



1.4 JP4 y JP5 =>Posición H

2. Configurar la placa DK-DEV-3C120N.

2.1 SW0 =>En ’1’

2.2 SW1 =>En ’1’

2.3 SW2 =>En ’1’

2.4 SW6 =>En ’0’

2.5 SW7 =>En ’0’


3. Configurar el FT601.

3.1 Abrir el programa “FT600ChipConfigurationProg.exe”.

3.2 Presionar el boton “Read Configuraction”.

3.3 Configurar los siguientes items:

1) FIFO Clock 66 MHz

2) FIFO Mode 600 Mode

3) Channel Config 1

4) Destildar Ignore Session Underrun

3.4 Presionar Write Configuration

4. Programar la FPGA con el firmware de prueba de HW: “mst_fifo_top.sof”

5. Abrir el programa “FT600DataStreamerDemoApp.exe”

6. Para probar la velocidad de escritura se debe

6.1 Tocar el botón “Start” para Write End Point

6.2 Tocar el botón “End” para Write End Point

6.3 Anotar la taza de transferencia de escritura

7. Para probar la velocidad de lecturra se debe

7.1 Tocar el botón “Start” para Read End Point

7.2 Tocar el botón “End” para Read End Point

7.3 Anotar la taza de transferencia de lectura

8. Repetir cambiando la configuración del punto Channel Config 1 por Chan-nel Config 2 y Channel Config 4

La siguiente Tabla 3.2 muestra los resultados obtenidos

TABLA 3.2: Resultados prueba de validación

Canales Tipo Velocidad Velocidad[MBps] [Mbps]

4 escritura 200 16004 lectura 138 11042 escritura 240 19202 lectura 194 15521 escritura 251 20081 lectura 235 1880

Como se puede ver el hardware es apto para poder realizar este trabajo. Salvo enel caso de la lectura de 4 canales será posible alcanzar los 1280 Mbps ancho debanda.


3.3. Firmware de comunicación

En esta sección se describe la biblioteca de firmware desarrollada. En la Subsec-ción 3.3.1 se muestra el nivel superior de la biblioteca, en las siguientes Subsec-ciones se muestra la implementación de cada módulo de la biblioteca.

3.3.1. Bloque communication

En la Figura 3.10 se pueden ver los cinco módulos que instancia este bloque y suinterconexión. Este es el nivel superior de la biblioteca, no contiene lógica dadoque es únicamente un bloque de interconexión de todos los módulos que la com-ponen. El detalle de dichos módulos será visto en las Subsecciones siguientes.

FIGURA 3.10: Diagrama en bloques de Communication.vhd.

Como se vio en la Subsección 2.3.1 la comunicación mediante el FT601 constade 1, 2 o 4 pares de canales, cada par teniendo un canal de recepción y uno detransmisión.

Cada canal de transmisión consta de una FIFO donde el usuario de la bibliotecacoloca los datos a transferir hacia la PC. De la misma forma cada canal de recep-ción consta de una FIFO de la cual el usuario de la biblioteca puede leer los datosrecibidos de la PC. En la Subsección 3.3.5 se explica el diseño de estas FIFOs.

Los datos escritos en la FIFO de transmisión son leídos y escritos en el FT601 parasu transmisión a la PC por el bloque usbWrite, que será explicado en la Subsección3.3.3. El bloque usbRead, que será explicado en la Subsección 3.3.4, lee del FT601los datos enviados por la PC y los coloca en la FIFO de recepción.

Dado que puede haber 1, 2 o 4 pares de canales, de estos últimos cuatro bloquespueden instanciarse 1, 2 o 4 veces dependiendo de los parámetros de configura-ción de la biblioteca.

3.3. Firmware de comunicación 27

Por último, sólo un canal por vez puede utilizar el bus del FT601. El bloque us-bArbitrer, que será explicado en la Subsección 3.3.2 es el encargado de arbitrarlopara que todos los canales puedan compartirlo.

La Tabla 3.3 muestra los parámetros de configuración del bloque. Dado que elFT601 puede configurarse para operar con 1, 2 o cuatro 4 canales, está bibliotecaprovee la misma configuración mediante el parametro CHANNELS para poderasí ahorrar recursos de la FPGA. Como se verá más adelante en la Subsección3.3.2, el bloque de arbitraje permite configurar la cantidad ciclos de clock paraejecutar su política de Round-Robin e ir otorgando el control del bus a los distin-tos canales. Ese parámetro es ROUND_ROBIN_COUNT que es traído hasta estenivel para que el usuario de la biblioteca elija el mejor valor para su aplicación.

TABLA 3.3: Parámetros del bloque communication.vhd

Parámetro Descripción

CHANNELS Genera 2CHANNELS canales de recepción y2CHANNELS canales de transmisión.

Rango [0:2]ROUND_ROBIN_COUNTS Tiempo máximo que un canal puede hacer

uso del bus sin ser interrumpido por el arbitropara ejecutar la política de Round-Robin

Se debe tener en cuenta que estos valores son críticos y pueden degradar altamen-te el ancho de banda máximo de la biblioteca que es gobernado por la Ecuación3.1. El denominador de esta ecuación representa el periodo completo de repeti-ción de una secuencia de envío/recepción de datos, interrupción de la transac-ción causada por arbitro de bus, consulta de todos los demás canales para versi requieren utilizar el bus, resumen de la transacción interrumpida. La prime-ra parte del numerador, ROUND_ROBIN_COUNTS-2, es el tiempo que máximoque un canal puede estar enviando datos en forma continua sin ser interrumpidopor el arbitro de bus.

BW =(ROUND_ROBIN_COUNTS − 2) ∗ 32bits ∗ Fclk(FT601)

ROUND_ROBIN_COUNTS + 4 + 2CHANNELS(3.1)

La Tabla 3.4 ejemplifica cómo cambia el ancho de banda máxima teórico en fun-ción de la cantidad de canales y el valor de Round-Robin configurado para un clockdel FT601 de 100 MHz para el caso de un único canal transmitiendo o recibiendodatos. Como se puede apreciar en dicha Tabla si se mantiene el valor de ROUND_ROBIN_COUNTS por encima de la 1000 muestras la perdida de ancho de bandaes inferior al 1 % independientemente de la cantidad de canales.


TABLA 3.4: Ancho de banda máximo vs parámetros de configura-ción

CHANNELS ROUND_ROBIN_ BW EficienciaCOUNTS [Mbps] [ %]

0 10 1706 53,30 1000 3177 99,31 10 1600 50,01 1000 3174 99,22 10 1422 44,42 1000 3168 99,0

Por último la Tabla 3.5 muestra todas las entradas y salidas de este bloque.

TABLA 3.5: Señales del bloque Communication.vhd

Señal tipo Descripción

Señales para controlar el FT601usbClk IN clock del FT601usbWrn OUT WR_N del FT601usbRXFn IN RXF_N del FT601usbD[31:0] INOUT DATA[31:0] del FT601usbBE[3:0] INOUT BE[31:0] del FT601usbTXEn IN TXE_N del FT601usbOEn OUT OE_N del FT601usbRDEn OUT RD_N del FT601usbSIWUn OUT SIWU_N del FT601

Señales para las FIFOs de transmisiónwrclk[K:0]1 IN Clock de escritura en la FIFOwrreq[K:0]1 IN Informa con ’1’ que se debe escribir

un dato en la FIFOwrfull[K:0]1 OUT Indica con ’1’ que la FIFO está llenadata[K:0][33:0]1 IN Datos a escribir en la FIFO

Señales para las FIFOs de recepciónrdclk[K:0]1 IN clock de lectura de datos de la FIFOrdreq[K:0]1 IN Informa a la fifo que se leyo el byte actual

y que se debe cargar el próximordempty[K:0]1 OUT Indica con ’1’ que la FIFO está vacíaq[K:0][33:0]1 OUT Datos a leer de la FIFO

1 Siendo K = 2CHANNELS-1.

3.3.2. Bloque usbArbitrer

Este bloque es el encargado de administrar cual de todos los canales de recepcióny transmisión usará el bus del FT601. Implementa una política Round-Robin entrelos canales que estén pidiendo el uso del bus. Si un canal ocupa el bus por másdel tiempo TIMEOUT en ciclos de clock, configurable por el usuario, este bloquelo interrumpirá para ver si hay algún otro canal que requiera atención. Cada vez


que un canal que está utilizando el bus lo libera, el contador de tiempo de usose resetea. Esto se realiza para maximizar la tasa de transferencia de datos, si yaocurrió una liberación del canal y no se entregó el bus a otro canal, significa quese puede esperar el tiempo TIMEOUT nuevamente.

La Tabla 3.6 muestra los parámetros de este bloque. A diferencia del bloque decomunicación, la cantidad de canales a arbitrar CHANNELS es el total de canalessumando recepción y transmisión. Es decir si CHANNELS igual a cero en com-munication.vhd, en este bloque CHANNELS será igual dos. El otro parámetro,TIMEOUT, es el mismo que ROUND_ROBINS_COUNTS del bloque de comuni-cación.

TABLA 3.6: Parámetros del bloque usbArbitrer

Parámetro Descripción

CHANNELS Entero con el número de canales a arbitrar.TIMEOUT Tiempo máximo que un canal puede hacer

uso del bus sin ser interrumpido por el arbitropara ejecutar la política de Round-Robin

La Tabla 3.7 muestra todas las señales de entrada y salida de este bloque. Estas sedividen en tres secciones. La primera de ellas, "Señales del FT601 a arbitrar", sonlas señales que se conectan directamente al bus del FT601. La segunda, "Señalesde control de los canales", son las encargadas de indicarle a cada uno de los ca-nales cual de ellos está activo, y recibir de los canales si estos están requiriendoel uso del bus. La tercera, "Señales de los canales a arbitrar", son las señales quedeben ser arbitradas para que todos los canales puedan hacer uso del bus.


TABLA 3.7: Señales del bloque usbArbitrer


Señales del FT601 a arbitrarusbClk IN clock del FT601usbWrn OUT WR_N del FT601usbRXFn IN RXF_N del FT601usbD[31:0] INOUT DATA[31:0] del FT601usbBE[3:0] INOUT BE[31:0] del FT601usbTXEn IN TXE_N del FT601

Señales de control de los canaleschBusRequest[K:0]1 IN Bus request de cada canalchBusInUse[K:0]1 IN Bus en uso de cada canalchBusGranted[K:0]1 OUT Bus granted para cada canal

Señales de los canales a arbitrarchUsbWRn[K:0]1 IN WR_N de cada canalchUsbRXFn[K:0]1 OUT RXF_N de cada canalchUsbDoe[K:0]1 IN Salida de Deo[3:0] de cada canalchUsbDout[K:0][31:0]1 IN Salida de DATA[31:0] de cada canalchUsbDin[K:0][31:0]1 OUT Entrada de DATA[31:0] de cada canalchUsbBEoe[K:0]1 IN Salida de BEeo de cada canalchUsbBEout[K:0][3:0]1 IN Salida de BE[3:0] de cada canalchUsbBEin[K:0][3:0]1 OUT Entrada de BE[3:0] de cada canalchUsbTXEn[K:0][3:0]1 OUT TXE_N de cada canal

1 Siendo K = CHANNELS-1.

Cada uno de los canales cuenta con un set de tres señales de control. La primera,chBusRequest que es utilizada por el canal para indicarle con ’1’ al arbitro de busque quiere utilizar el bus con el FT601. La segunda chBusGranted es utilizada porel arbitro de bus para indicarle al canal que se le ha otorgado el bus. Y la ultimachBusInUse es utilizada por el canal para indicarle al arbitro que está utilizandoel canal.

Por otro lado cada canal también cuenta con un set de nueve señales para el ma-nejo del bus del FT601. Las señales chUsbDin, chUsbBEin, chUsbRXFn y chUsb-TXEn son las correspondientes señales usbD, usbBE, usbRXFn y usbTXEn delbus del FT601 para ser leídas por los canales. En cambio las señales chUsbWRn,chUsbDoe, chUsbDout, chUsbBEoe y chUsbBEout son las señales que cada canaldesea escribir en el bus del FT601 y deben ser multiplexadas correctamente.

En particular las señales chUsbBEout y chUsbDout, dado que escriben en las se-ñales del bus usbBE y usbD que son bidireccionales, constan de las señales adi-cionales chUsbBEoe y chUsbDoe para indicar cuando las señales usbBE y usbDrespectivamente deben ser salidas y con el valor de chUsbBEout y chUsbDoutrespectivamente.

Este bloque se divide en dos partes, la primera de ellas es una máquina de estadosque maneja qué canal está activo y computa el tiempo transcurrido en un mismocanal. La segunda es un bloque lógico de muxtiplexeo y distribución de señales.

La Figura 3.11 muestra el diagrama de estados del arbitro de bus. La Tabla 3.8explica que es cada estado y la Tabla 3.9 detalla las señales internas del bloque.


FIGURA 3.11: Diagrama de estados usbArbitrer.vhd.

TABLA 3.8: Estados y salidas de usbArbitrer.vhd

Estado Descripción chBusGranted[K:0]

Released Nadie está utilizando el bus, durante ’0’este estado se busca qué señal de

chBusRequest se encuentra activa.Granting Se levanta la señal granted del canal ’1’<<

seleccionado y se espera durante un ciclo grantedChannelde clock el acknowledge del canal.

Granted El bus ha sido entregado, esperando ’1’<<timeout o fin de uso. grantedChannel

Releasing Se quita el granted, esperando que ’0’el canal termine su transacción en caso

de no haberlo hecho aún

TABLA 3.9: Señales internas usbArbitrer.vhd

Señal Descripción

nextChannel En el estado released: se incrementa en forma unitaria,si supera CHANNELS se pone en ’0’.

En todos los demás estados guarda su último valor.grantedChannel En el estado released: si chBusRequest[nextChannel]=1,

copia el valor de nextChannel.Para los demás estados guarda su último valor.

elapsedTime En el estado released se pone en 0.En el estado granted incrementa su valor en forma unitaria.


La Figura 3.12 muestra un caso de uso de dos canales donde el canal 0 sube laseñal busRequest[0] solicitando el bus. Una cierta cantidad de ciclos de clock des-pués, el arbitro de bus le otorga el control del bus subiendo la señal busGran-ted[0]. En el siguiente ciclo de clock el periférico debe subir la señal busInUse[0]indicando que tomó posesión del bus. Cinco ciclos de clock después, el periféricoinforma al arbitro que terminó de utilizar el bus bajando las señales busReques[0]y busInUse[0]. El arbitro de bus le quita el control de bus en el ciclo siguiente declock bajando la señal busGranted[0].

FIGURA 3.12: Canal solicitando el uso del bus del FT601.

En la Figura 3.13 podemos ver el caso donde dos canales se encuentran utilizandoel bus el 100 % del tiempo y el arbitro del bus debe aplicar la política de Round-Robin para compartirlo. Como se puede ver ambos periféricos tienen sus señalesbusRequest en ’1’ todo el tiempo. En arbitro entrega en primer lugar el control debus al canal 0 subiendo la señal busGranted[0]. Luego de TIMEOUT ciclos de relojel arbitro baja la señal busGranted[0] indicandole al periférico que debe dejar deutilizar el bus. El canal 0 se toma N ciclos de clock para terminar su transacción conel FT601 correctamente y luego baja la señal busInUse[0] indicando al Arbitro queya ha liberado el bus. Habiendo retomado control del bus, el arbitro sube ahora laseñal busGranted[1] entregándole el control del bus al canal 1, y vuelve a contarTIMEOUT ciclos de clock. Transcurrida esta cantidad de ciclos de clock, baja lasseñal busGranted[1] y así va alternando entre dos o más canales.

FIGURA 3.13: Round-Robin entre dos canales para el uso del busdel FT601.

Por último la Figura 3.14 muestra como funciona el bloque lógico de multiplexeoy distribución de señales.


FIGURA 3.14: Round-Robin entre dos canales para el uso del busdel FT601.

3.3.3. Bloque usbWrite

Este bloque se encarga de leer los datos de la FIFO de transmisión y escribirlosen el FT601. Dado que el bus es compartido por otros bloques similares y losbloques de recepción, este bloque debe respetar las señales del arbitro del bus quele indican cuando debe tomar control de bus. Las señales de salida que controlanel FT601 de este bloque son muxeadas posteriormente por el arbitro de bus.

Como se verá en la Subsección 3.3.5, este bloque espera que la FIFO esté configu-rada en el modo show ahead, cualquier otra configuración de la FIFO resultará enun mal funcionamiento de este bloque. La FIFO a su vez tiene palabras 34 bits,los 32 bits menos significativos contienen 4 bytes de datos a enviar a la PC, los2 bits más significativos indican con 0b00, 0b01, 0b10, 0b11 si se quiere enviar 1byte (bits[7:0]), 2 bytes (bits[13:0]), 3 bytes (bits[23:0]) o 4 bytes (bits[32:0]) a la PCrespectivamente. En los casos donde se envíe menos de 4 bytes los datos en losbits que no son enviados son ignorados.

Este bloque tiene un único parámetro entero llamado CH cuyo rango va de 1 a 4e indica cuál es el número de canal de transmisión que está manejando.

La Tabla 3.10 muestra la lista de señales que maneja este bloque. Estas señalesestán divididas en tres grupos. El primero de ellos “Señales para escribir los datosen el FT60” contiene las señales que, cuándo el arbitro le otorgue el bus a estebloque, controlaran el bus del FT601. El segundo grupo,“Señales del arbitro delbus”, contiene las señales de control de arbitro de bus, ver Subsección 3.3.2. Elúltimo grupo “Señales para leer los datos de la FIFO” contiene las señales paraleer la FIFO de transmisión.

Las figuras 3.15, 3.16 y 3.17, ilustran distintos casos de comienzos y finales detransferencias para enviar datos de las FIFOs de transmisión al FT601. Las trans-ferencias comienzan cuando se cumplen las siguientes tres condiciones:


TABLA 3.10: Señales del bloque usbWrite


Señales para escribir los datos en el FT601usbClk IN Clock del FT601usbWRn OUT WR_N del FT601 cuando este bloque la controlausbRXFn IN RXF_N del FT601.usbDoe[3:0] OUT Controla el buffer tri-state de salida de DATA[31:0]

Si usbDoe[N]=1, DATA[N*8-1:(N-1)*8] es unasalida con el contenido de usbDout[N*8-1:(N-1)*8]

Si usbDoe[N]=0, DATA[N*8-1:(N-1)*8] es una entradausbDout[31:0] OUT Valor de DATA[31:0] dependiendo de usbDoeusbDin[7:0] IN Valor de la señal DATA[15:8] del FT601.usbBEoe Controla el buffer tri-state de salida de BE

Si UsbBEoe=1, BE[3:0] es una salida con elcontenido de usbBEout[3:0]

Si UsbBEoe=0, BE[3:0] es una entrada.usbBEout[3:0] OUT Valor de BE[31:0] dependiendo de usbBEoeusbTXEn IN TXE_N del FT601.

Señales del arbitro del busbusRequest OUT Indica con ’1’ que quiere usar el busbusInUse OUT Indica con ’1’ que está utilizando el busbusGranted IN Indica con ’1’ que el bus ha sido otorgado.

Señales para leer los datos de la FIFOfifoRdreq OUT Informa a la FIFO que se leyó el byte actual y que se

debe cargar el próximo.fifoRdempty IN Indica que no hay más datos que leer en la FIFOfifoQ[33:0] IN Datos a enviar a la PC, bits [31:0] serán colocados en

usbDout[31:0], los bits [33:32] serán colocados enBEout[3:0] siguiendo la siguiente lógica

fifoQ[33:32]=0b00 =>BEout[3:0]=0x1fifoQ[33:32]=0b01 =>BEout[3:0]=0x3fifoQ[33:32]=0b10 =>BEout[3:0]=0x7fifoQ[33:32]=0b11 =>BEout[3:0]=0xF

1. El FT601 tiene lugar para recibirlas d[15:8] durante mientras TXE_N está en0.

2. La FIFO tiene datos para enviar al FT601 (fifoRdempty=’0’) o quedó un datopor enviar.

3. El bus ha sido otorgado a este bloque, señal busGranted = 1.

Las transferencias terminan cuando se cumple al menos una de las siguientes trescondiciones:

1. El FT601 no tiene más lugar para guardar datos.

2. La FIFO no tiene más datos para enviar al FT601 (fifoRdempty=1).

3. El arbitro quiere recuperar el bus, señal busGranted = 0.


Puede ocurrir más de una situación de fin de transferencia simultáneamente, estodebe ser contemplado en la máquina de estados. En el caso particular donde latransferencia se termina por que el FT601 no tiene más lugar, Figura 3.16, se debetener particular cuidado porque quedará un dato quitado de la FIFO que debeguardarse para ser enviado en cuanto se libere el FT601. El proceso para enviarlopuede verse en la Figura 3.17 donde el dato D3 quitado de la FIFO en la Figura3.16 debe ser guardado y enviado como primer dato en la transacción siguiente.

FIGURA 3.15: UsbWirte, transacción que comienza por FIFO novacía y termina por FIFO vacía.


FIGURA 3.16: UsbWirte, transacción que comienza por FT601 nolleno y termina por FT601 lleno.

FIGURA 3.17: UsbWirte, transacción que comienza luego del ter-minar por FT601 lleno y termina por busGranted=0.


La Figura 3.18 ilustra la máquina de estados implementada para este bloque. LaTabla 3.11 explica qué es cada estado y la Tabla 3.14 detalla las señales internasdel bloque.

FIGURA 3.18: Diagrama de estados usbWrite.vhd.

TABLA 3.11: Estados y salidas de usbWrite.vhd, parte 1 de 3

Estado Descripción usbWRn usbDoe[3:0]

Idle No hay datos para enviar o lugar 1 h0para recibirlos

Waiting Hay datos, esperando la entrega 1 h0del bus por el arbitro.

Start Comienzo de transferencia 0 h1RdStart Comienzo de lectura FIFO 0 h1putLast Coloca el byte pendiente si quedó 0 h1

un byte sacado de la FIFO que nofue transferido al FT601

Sending Enviando datos al FT601 0 hF si usbRXn=’0’h0 si usbRXn=’1’

Stop Comienza secuencia de final de 1 h0transmisión

Hold Espera que el bus del FT601 1 h0quede en idle

FTfull Stop por FT601 full 1 h0



Estado usbDout[31:8] usbDout[7:0] usbBEoe usbBEout[3:0]

Idle X X 0 XWaiting X X 0 X

Start X CH 1 h1RdStart X CH 1 h1putLast X CH 1 h1Sending LastQ[31:8] LastQ[7:0] 1& decodeBE[3:0]

(!usbRXn)Stop X X 0 XHold X X 0 XFTfull X X 0 X


Estado fifoRdreq busRequets busInUse

Idle 0 !usbDin[CH-1]& 0usbTXEn=0 &!fifoRdempty

Waiting 0 1 0Start 0 1 1

RdStart 1 1 1putLast 0 1 1Sending !usbRXn& 1 1

(busGranted)Stop 0 1 1Hold 0 0 0FTfull 0 0 0

TABLA 3.14: Señales internas usbWrite.vhd

Señal Descripción

pendingData Indica con ’1’ que quedó una palabra leída de la FIFO queno se escribió en el FT601.

Se pone en 1 si Estado==Stop.Se pone en 0 si Estado==sending.

lastFifoQ[33:0] Último valor leído de la fifo.Si fifoRdreq=1 se actualiza lastFifoQ con el valor de fifoQ.

Si fifoRdReq está en 0 mantiene el último valor leído.decodeBE[3:0] Decodifica el valor a colocar en BE

lastFifoQ[33:32]=0b00 =>decodeBE[3:0]=0h1.lastFifoQ[33:32]=0b01 =>decodeBE[3:0]=0h3.lastFifoQ[33:32]=0b10 =>decodeBE[3:0]=0h7.lastFifoQ[33:32]=0b11 =>decodeBE[3:0]=0hF.


3.3.4. Bloque usbRead

Este bloque se encargada de leer los datos del FT601 y escribirlos en la FIFO derecepción de datos de la FPGA. Dado que el bus es compartido por otros bloquessimilares y los bloques de transmisión, este bloque debe respetar las señales delarbitro que le indican cuando debe tomar control de bus. Las señales de salida deeste bloque que controlan el FT601 son muxeadas posteriormente por el arbitro.

La FIFO donde se guardan los datos sacados del FT601 tiene palabras de 34 bits,los 32 bits menos significativos contienen 4 bytes de datos recibidos de la PC, los2 bits más significativos indican con 0b00, 0b01, 0b10, 0b11 si el 1 byte (bits[7:0]),2 bytes (bits[13:0]), 3 bytes (bits[23:0]) o 4 bytes (bits[32:0]) son datos válidos. Enlos casos donde se recibe menos de 4 bytes los datos en los bits que no son válidosdeben ser ignorados.

Este bloque tiene un único parámetro entero llamado CH cuyo rango va de 1 a 4e indica cual es el número de canal de transmisión que está manejando.

Las Tablas 3.15 y 3.16 muestran la lista de señales que maneja este bloque. Estasseñales están divididas en tres grupos. El primero de ellos “Señales para recibirlos datos del FT601” son las señales que cuando el arbitro le otorgue el bus aeste bloque, controlaran el bus del FT601. El segundo grupo, “Señales del arbitrodel bus”, contiene las señales de control de arbitro de bus, ver Subsección 3.3.2.El último grupo“Señales para escribir los datos en la FIFO” contiene las señalespara escribir en la FIFO de recepción.

TABLA 3.15: Señales del bloque usbRead, parte 1 de 2


Señales para escribir los datos en el FT601usbClk IN Clock del FT601usbWRn OUT WR_N del FT601 cuando este bloque la controla.usbRXFn IN RXF_N del FT601.usbDoe[3:0] OUT Controla el buffer tri-state de salida de DATA[31:0]

Si usbDoe[N]=1, DATA[N*8-1:(N-1)*8] es unasalida con el contenido de usbDout[N*8-1:(N-1)*8]

Si usbDoe[N]=0, DATA[N*8-1:(N-1)*8] es una entradausbDout[31:0] OUT Valor de DATA[31:0] dependiendo de usbDoeusbDin[31:0] IN Valor de la señal DATA[15:8] del FT601.usbBEoe Controla el buffer tri-state de salida de BE

Si UsbBEoe=1, BE[3:0] es una salida con elcontenido de usbBEout[3:0]

Si UsbBEoe=0, BE[3:0] es una entrada.usbBEout[3:0] OUT Valor de BE[31:0] dependiendo de usbBEoeusbBEin[3:0] IN BE[3:0] del FT601.usbTXEn IN TXE_N del FT601.


TABLA 3.16: Señales del bloque usbRead, parte 2 de 2


Señales del arbitro del busbusRequest OUT Indica con ’1’ que quiere usar el busbusInUse OUT Indica con ’1’ que está utilizando el busbusGranted IN Indica con ’1’ que el bus ha sido otorgado.

Señales para leer los datos de la FIFOfifoWrreq OUT Informa a la fifo que se debe escribir el

contenido de fifoD[33:0].fifoWrfull IN Indica que no hay más lugar en la FIFOfifoD[33:0] IN Datos recibidos de la PC, bits [31:0] corresponden

a usbDin[31:0], los bits [33:32] corresponden ausbBEin[3:0] siguiendo la siguiente lógica

usbBEin[3:0]=0x1 =>fifoQ[33:32]=0b00usbBEin[3:0]=0x3 =>fifoQ[33:32]=0b01usbBEin[3:0]=0x7 =>fifoQ[33:32]=0b10usbBEin[3:0]=0xF =>fifoQ[33:32]=0b11

Las figuras 3.19, 3.20 y 3.21, ilustran distintos casos de comienzos y finales detransferencias para enviar datos de las FIFOs de transmisión al FT601. Las trans-ferencias comienzan cuando se cumplen las siguientes tres condiciones:

1. El FT601 tiene lugar datos para enviar a la FPGA D[CH+11]=’0’ mientrasTXE_N está en 0.

2. La FIFO tiene lugar para recibir los datos, señal fifoWrfull = ’0’.

3. El bus ha sido otorgado a este bloque, señal busGranted = 1.

Las transferencias terminan cuando se cumple al menos una de las siguientes trescondiciones:

1. El FT601 no tiene más datos para enviar a la FPGA.

2. La FIFO no tiene más lugar para guardar los datos, señal fifoWrfull = ’1’.

3. El arbitro quiere recuperar el bus, señal busGranted = 0.

Puede ocurrir más de una situación de fin de transferencia simultáneamente, estodebe ser contemplado en la máquina de estados.


FIGURA 3.19: UsbRead, transacción que comienza por FIFO nollena y termina por FIFO llena.

FIGURA 3.20: UsbRead, transacción que comienza por FT601 nolleno y termina por FT601 lleno.


FIGURA 3.21: UsbRead, transacción que comienza por busGran-ted=1 y termina por busGranted=0.


La Figura 3.22 ilustra la máquina de estados implementada para el bloque us-bRead.vhd. La Tabla 3.17 explica que es cada estado y la Tabla 3.20 detalla lasseñales internas del bloque.

FIGURA 3.22: Diagrama de estados usbRead.vhd.

TABLA 3.17: Estados y salidas de usbRead.vhd, parte 1 de 3

Estado Descripción usbWRn usbDoe[3:0]

Idle No hay datos para recibir o 1 h0lugar para recibirlos.

Waitbus Hay datos, esperando la 1 h0entrega del bus por el arbitro.

Start Comienzo de transferencia 0 h1Wait1 Esperando que el FT601 comience 0 h0

a mandar los datos 1 de 2Wait2 Esperando que el FT601 comience 0 h0

a mandar los datos 2 de 2Receiving Recibiendo los datos del FT601 usbWrfull or h0

!busGrantedStop Comienza secuencia de final de 1 h0

la recepción



Estado usbDout[31:8] usbDout[7:0] usbBEoe usbBEout[3:0]

Idle X X 0 XWaitbus X X 0 X

Start X CH 1 h0Wait1 X X 0 XWait2 X X 0 X

Receiving X X 0 XStop X X 0 X


Estado fifoWrreq fifoD[33:32] fifo[31:0] busRequest

Idle 0 X X !usbDin[CH-3]X X &usbTXEn=0&X X !fifoWrfull

Waitbus 0 X X 1Start 0 X X 1Wait1 0 X X 1Wait2 0 X X 1

Receiving !usbRXn& encodeBE[1:0] usbDin[31:0] 1(busGranted)&

!fifoWrfullStop 0 X X 0

TABLA 3.20: Señales internas usbRead.vhd

Señal Descripción

encodeBE[1:0] Decodifica del usbBEin[3:0] el valor a colocar enfifoD[33:32] de la siguiente forma:

usbBEin[3:0]=0h1 =>encodeBE[1:0]=0b00.usbBEin[3:0]=0h3 =>encodeBE[33:32]=0b01.usbBEin[3:0]=0h7 =>encodeBE[33:32]=0b10.usbBEin[3:0]=0hF =>encodeBE[33:32]=0b11.


3.3.5. Bloque usbFIFO

Este bloque cumple dos funciones, la primera de ellas, es la de desacoplar el clockdel FT601 del clock del usuario de la biblioteca. La segunda es proveer un primerbuffer para absorber al menos una parte de los bloqueos o interrupciones del busde comunicación.

Debido a que los clocks de escritura o lectura pueden ser asincrónicos, se debetener particular cuidado en la configuración de esta FIFO. Este bloque fue creadopor el MegaFunction Wizzard de Altera, configurado según las recomendacionesde la hoja de datos de la FIFO [9]. Se debe tener en cuenta que, como se vio en laSubsección 3.3.3, el bloque Usbwrite.vhd requiere que la FIFO esté configuradaen modo show ahead.

La palabra que se almacena o lee de la FIFO tiene 34 bits que deben interpretarsecomo es indicado en la Tabla 3.21. Esto se debe a que la comunicación trabaja enbytes pero las transacciones entre el FT601 y la FPGA son de a 32 bits, es decir 4bytes. Por ende en ciertos casos se puede dar que se reciba o envíe menos de 4bytes.

TABLA 3.21: Palabra de las FIFOs

bits(33:32) bits(31:0)

0b00 Los bits (7:0) contiene datos válidos.Los bits (31:8) deben ser ignorados.



0b11 Los bits (31:0) contiene datos válidos.

La Tabla 3.22 muestra la lista de señales que maneja este bloque. Estas señalesestan divididas en dos grupos.

El primero de ellos “Señales para escribir en la FIFO” contiene el conjunto lasseñales para escribir en la FIFO. En el caso de las FIFOs de transmisión estas sonlas señales accesibles por el usuario de la biblioteca para escribir los datos a enviara la PC. Mientas que en las FIFOs de recepción, estas señales son manejadas porel bloque usbRead.vhd para colocar lo datos recibidos de la PC.

El segundo grupo, “Señales para leer de la FIFO”, contiene las señales para leerde la FIFO. En el caso de las FIFOs de recepción, estas son las señales accesiblespor el usuario de la biblioteca para leer los datos recibidos de la PC. Mientas queen las FIFOs de transmisión estas señales son manejadas por el bloque usbWritepara leer los datos a enviar a la PC.


TABLA 3.22: Señales del bloque usbFIFO


Señales para escribir en la FIFOwrclk IN Clock de escritura en la FIFO.wrreq IN Informa con ’1’ que se debe escribir un dato en la FIFO.wrfull OUT Indica con ’1’ que la FIFO está llena.data[33:0] IN Datos a escribir en la FIFOn.

Señales para leer de la FIFOrdclk IN Clock de lectura de datos de la FIFO.rdreq IN Informa a la fifo que se leyo el byte actual y que se

debe cargar el próximo.rdempty OUT Indica con ’1’ que la FIFO está vacía.q[33:0] OUT Datos a leer de la FIFOn.

Las Tablas 3.23 y 3.24 muestran todos los parámetros ingresados en el MegaWiz-zard Plug-In Manager del Quartus II para configurar las FIFOs. Se debe tenerparticular cuidado al migrar estos parámetros si se desea migrar esta FIFO a otraFPGA.

TABLA 3.23: Señales del bloque usbFIFO, parte 1 de 2

Parámetro Valor Configurado

Device Family Cyclone III.Solapa Witdh, Clks, Synchronizations

FIFO width 34 bits.FIFO depth 256 palabras. Este es el máximo valor que se

puede colocar para utilizar solo un bloque dememoria de 9216 bits de la FPGA.

Common Clock No. Queremos utilizar esta FIFO como unseparador de dominios de clock.

Solapa DCFIFO 1Optimization Best metaestability.Sync Stages 4. Recomendado en [9]

Solapa DCFIFO 2Read Side Tildar empty, destildar full y usedw[].Write Side Tildar full, destildar empty y usedw[].

Asynchronous Clear Tildar.Synchronize ’aclr’ Tildar.


TABLA 3.24: Señales del bloque usbFIFO, parte 2 de 2

Parámetro Valor Configurado

Solapa Rdreq Option, Blk TypeShow-Ahead Tildar.synchronousFIFO mode

What should the Tildar Auto.memory type beSet the maximun Auto.

blockSolapa Rdreq Option, Blk Type

Disable overflow Destildar. Programación defensiva.checking

Disable underflow Destildar. Programación defensiva.checking

Implement FIFO Destildar.storage with

logic cells only

Las figuras 3.23 y 3.24 muestran casos típicos de escritura y lectura respectiva-mente de las FIFOs.

FIGURA 3.23: Escritura en la FIFO.


FIGURA 3.24: Lectura de la FIFO.

3.4. Firmware de ensayos

Para poner a prueba la biblioteca desarrollada, se diseño e implementó un firm-ware de prueba configurable desde la PC. Para dicho firmware se desarrolló unprotocolo de comunicación que será presentado en la Subsección 3.4.1. En la Sub-sección 3.4.2 se podrá ver un diagrama en bloques del firmware de prueba y unadescripción de sus principales bloques.

3.4.1. Protocolo de comunicación

Para poder configurar los distintos tipos de ensayos a aplicar en la biblioteca desa-rrollada fue necesario definir un protocolo de comunicación.

Para que este protocolo utilice lo mejor posible el ancho de banda disponible,dado que bus de comunicación del FT601 con la FPGA es de 32bits, se optó porpaquetes que fueran múltiplos de 4 bytes. La Tabla 3.25 muestra como se definie-ron los paquetes del protocolo.

TABLA 3.25: Paquetes del protocolo de comunicación

Bytes 0:1 2:5 6:7 8:(7+(N+1)*4)

Descripción Header N Checksum D0 to DN

Cada paquete está compuesto por cuartro partes:

1. Header [2 Bytes]: Describe el tipo de paquete. Ver Tabla 3.27.

2. N [4 bytes]: Largo más 1 de los datos del paquete en palabras de 4 bytes.

3. Checksum: Suma negada de los bytes 0 a 5 del paquete. Ver Tabla 3.26.

4. D0 to DN: N+1 datos de 4 bytes cuyo contendido depende del tipo de pa-quete.

La Tabla 3.26 muestra ejemplos de checksum computados.

3.4. Firmware de ensayos 49

TABLA 3.26: Computo del checksum

Header N Checksum

0x0001 0x00001000 0x11000xFFFF 0xFFFFFFFF 0xFA050x0000 0x00000000 0xFFFF

La Tabla 3.27 muestra la lista de paquetes definidos por el protocolo.

TABLA 3.27: Tipos de paquetes del protocolo

Descripción Dirección Header Largo D0 to DN

LoopBackPC PC=>FPGA 0x0001 N N+1 datos a devolver ala PC

LoopBackFPGA FPGA=>PC 0x8001 N N+1 datos devueltos dela FPGA

RampPC PC=>FPGA 0x0002 N N+1 datos con un rampade valores enviados

desde la PCRampFPGA FPGA=>PC 0x8002 N N+1 datos con un rampa

de valores enviadosdesde la FPGA

BufferSize FPGA=>PC 0x8003 N N+1 datos con lacantidad de palabraspendientes de enviar

TestCfg PC=>FPGA 0x0002 3 Configuración del modoprueba. Ver Tabla 3.28

Los primeros dos paquetes de la Tabla 3.27 son utilizados para las pruebas deeco. Su función es probar que la comunicación está funcionando sin medir velo-cidades de transferencia. Cuando la biblioteca de software envía a la FPGA unpaquete LoopBackPC con N+1 datos, la FPGA debe responden con un paqueteLoopBackFPGA con los mismos N+1 datos que la PC envío en el paquete Loop-BackPC anterior.

El paquete RampFPGA es utilizado para medir la velocidad de subida de datosdesde la FPGA hacia la PC y la tasa de bytes erróneos. El paquete BufferSize sirvepara medir el largo de buffers requerido por la aplicación. Estos dos paquetes re-quieren una serie de configuraciones que se realizan enviando el paquete TestCfg.

La Tabla 3.28 muestra qué configura cada una de las 4 palabras de datos del pa-quete TestCfg.


TABLA 3.28: Configuración de las pruebas

Palabra Descripción

D0 Largo de los paquetes RampFPGA y RampSize a enviar ala PC

D1 Para los paquetes RampFPGA es el incremento entre cadamuestra de la rampa

D2 Divisor de frecuencia de clock según la fórmula.(32-Div)*Fclock/32. Rango Div [0:31].

D3 Flags para arranque y parada del test, y selección entreRampFPGA y BufferSize

Si bit 8 = ’1’ se deben comenzar a enviar 1 o más paquetesSi bit 1 = ’1’ se envían paquetes RampFPGA.Si bit 1 = ’0’ se envían paquetes BufferSize.

Si bit 0 = ’1’ con cada transición de bit 8 de 0 a 1envía un único paquete.

Si bit 0 = ’0’ cuando bit 8 = ’1’ se envían paquetesconstantemente.

En resumen este paquete nos permite con:

1. D0: configurar cuantas palabras tendrá cada paquete.

2. D1: configurar cuál será el incremento entre cada muestra de RampFPGA.

3. D2: configurar un divisor que se aplicará al clock suministrado al firmwarede prueba. Este divisor busca simular velocidades de transferencia distintasde la velocidad máxima. Si por ejemplo se quiere utilizar esta biblioteca enun sistema que muestrea 32bits cada 40 MHz, se puede utilizar este divisorpara obtener un troughput de 1280 MBps relativamente independiente delvalor del clock de la biblioteca.

4. D3: elegir entre paquetes de RampFPGA o BufferPFGA. Configurar si seenvía un único paquete o un flujo de paquetes. Comienza y detiene el envíode estos paquetes.

Dado que los paquetes RampFPGA y BufferFPGA son generados en forma con-tinua, permiten medir las velocidades de transferencia de subida de la FPGA ala PC. Los paquetes de RampFPGA contienen información conocida y por endepermiten medir tasa de errores de bytes en la comunicación.

Por otro lado los paquete bufferSize simulan un buffer virtual en la FPGA de ta-maño máximo 65535 palabras y cada palabra de datos de este paquete informacuantas palabras se encontrarían en ese buffer virtual. De esta forma se puedeobtener una estadística de cual sería el tamaño de buffer requerido, para la ve-locidad de transferencia y largo de paquete elegidos, para evitar la perdida depaquetes.

Al momento de escribir esta memoria el comportamiento de los paquetes Ramp-PC no había sido incorporado al firmware. La idea de estos paquetes es que al serrecibidos por la FPGA la misma controle todos sus bytes y si los valores no sonlos esperados lo indique algún tipo de error. La idea de estos paquetes es podermedir las velocidades de transferencia de la PC hacia la FPGA y su tasa de error.

3.4. Firmware de ensayos 51

3.4.2. Diseño del firmware de ensayos

En la Figura 3.25 se puede ver el diagrama en bloques del firmware de ensayosdesarrollado. Como se puede ver, al igual que la biblioteca de comunicación, sepuede configurar la cantidad de canales. Cada par de canales de transmisión re-cepción son controlados por un bloque TestFT601. Este a su vez está compuestopor los bloques deserializer, packetController, periphMux, controlRegister, trans-mitController y receiveController.

FIGURA 3.25: Diagrama en bloques firmware de ensayos.

Le bloque deserializer se encarga de poner en fase los datos que salen de la FIFOde recepción. El protocolo de comunicación tiene palabras de 4 bytes, pero comose vio en la Subsección 3.3.4, el bus del FT601 no necesariamente colocará siempre4 bytes en cada transacción. Es necesario entonces armar paquetes de 4 bytes parasu interpretación posterior, este bloque realiza dicha tarea.

El bloque packetController toma los datos que salen del desarializer y va inter-pretando los paquetes para determinar a qué bloque debe direccionarlos. Cadatipo de paquete es direccionado a un periférico determinado por el Header delpaquete. Los bloques transmitController, receiveController y configRegister sonestos perifericos y se direccionan a ellos los paquetes LoopBackPC, RampPC yRestCfg respectivamente.

Dado que para direccionar los datos hacia un determinado periférico, estos de-ben controlar algunas señales que son entradas del packetController, es necesariocolocar un multiplexor que evite colisiones. El bloque periphMux es el encargadode administrar las señales en entrada del bloque packetController que pueden sermanejadas por los periféricos.

El bloque ConfigRegister guarda los datos recibidos del paquete TestCfg y se lossuministra a los bloques receiveController y transmitController para que confi-guren su modo de operación y su estado.


El bloque transmitController genera los paquetes que son enviados a la PC. Tienetres modos de operación, loopback, rampa y buffer. El primero de ellos, es dis-parado cuando llega un paquete de LoopBackPC, y lo que realiza este bloque escolocar un Header, largo de paquete y checksum correctos para un paquete Loop-BackFPGA y luego envía todos los datos recibidos del paquete LoopBackPC.

El modo rampa, utiliza la configuración del ConfigRegister para generar y enviarun paquete RampFGPA que contiene una rampa que comienza en 0 y cada mues-tra siguiente tiene el valor de la anterior más el valor de incremento de rampa.

El modo buffer genera y envia un paquete BufferFPGA que contiene la cantidadde muestras almacenadas en un buffer virtual para que se pueda estimar el ta-maño de los buffers necesarios. Este buffer virtual se implementa de la siguienteforma. Se tiene un contador de palabras en el buffer que se pone en cero cuando elsistema está detenido. Cuando se activa el flujo de datos mediante el configRegis-ter, se aplica el divisor para determinar si es tiempo o no de agregar una muestraen la FIFO de transmisión hacia la PC. Si es tiempo de enviar una muestra, y laFIFO está llena, se incrementa el contador de palabras en el buffer. Si en cambio estiempo de enviar una muestra, y la FIFO tiene lugar para almacenarlo, se colocael valor de este contador en la FIFO. Si no es tiempo de enviar una muestra, peroel contador muestras en el buffer es distinto de cero, se decrementa este contadory se escribe su valor en la FIFO de transmisión. De esta forma se simula un bufferque mientras no hay muestras nuevas intenta ir enviando las muestras almacena-das en el buffer, y además se simula también un sistema con periodo de muestreoconstante.

El bloque receiveController no ha sido implementado aún pero será configuradomediante el ConfigRegister y podrá chequear si los datos del paquete RampPCson correctos y computar una estadística de bytes inválidos. El diagrama en blo-ques muestra donde está prevista su incorporación.

3.5. Biblioteca de comunicación en Java

Como se explicó en la Subsección 2.3.2 para poder utilizar el driver que proveeel fabricante del FT601 en Java es necesario utilizar un wrapper. La realización deeste wrapper se basó en la biblioteca JD2xx realizada Pablo Bleyer Koci. En estasección se va a mostrar aquellos detalles de la implementación de este wrapperque fueron necesarios para poder alcanzar la velocidad de transferencia deseaday no fueron únicamente una adaptación de la biblioteca original JD2xx.

Como se puede ver en [3] La biblioteca D3xx para controlar la comunicación USBcon el FT601 provee dos mecanismos para leer los datos en la PC.

El primero de ellos es llamando a la función a la función FT_readPipe con elúltimo parámetro en NULL. Cuanto esto ocurre, la tarea que llama a esta funciónse bloquea hasta que se reciban la cantidad de bytes pedidos o que ocurra eltimeout configurado.

El segundo mecanismo consiste en llamar a la función FT_readPipe con el últimoparámetro con una estructura llamada OVERLAPPED. Esto genera que la fun-ción read salga inmediatamamente pero deja inicializado el proceso de recepción

3.5. Biblioteca de comunicación en Java 53

de los datos pedidos. Llamando a la función FT_GetOverlappedResult con la es-tructura OVERLAPPED que se llamo a FT_readPipe se bloquea la tarea que llamaa esta función hasta que se lean todos los bytes pedidos o ocurra timeout.

Dado que el FT601 trabaja con un sistema ping pong para recibir los datos delchip, hasta que no se llama a la función FT_readPipe no se envía el ping y porende no comienza la transmisión. Es por eso que existe la opción del llamadoa FT_readPipe con la estructura OVERLAPPED. Esto permite llamar N veces ala función readPipe, con N estructuras OVERLAPPED distintas. Esto genera quese envíen N pings pidiendo datos. Luego se espera a que la primer estructuraOVERLAPPED termine llamando a la función FT_GetOverlappedResult, se sacanlos datos y se vuelve a llamar a FT_readPipe con la primer estructura. De estaforma siempre hay N pings pendientes y se optimiza fuertemente el tiempo delatencia.

Fue necesario incorporar el segundo mecanismo para poder obtener el tiempode respuesta deseado. Además para acelerar la lectura de los datos también fuenecesario utilizar las funciones GetPrimitiveArrayCritical y ReleasePrimitiveA-rrayCritical mencionadas en la Subsección 2.3.2.

Para trabajar con los resultados solapados, era necesario devolver al Java la es-tructura OVERLAPPED o algo similar. Para utilizar las funciones GetPrimitiveA-rrayCritical y ReleasePrimitiveArrayCritical era necesario que los datos sean es-critos en un arreglo de C y luego copiados a java al final de la recepción. Paracumplir con estos requerimientos se crearon las estructuras internas del wrapperque se pueden ver en el Algoritmo 3.2.

1 typedef s t r u c t {2 j b y t e ∗data ;3 j l o n g s i z e ;4 } p i p e B u f f e r _ t ;5

6 typedef s t r u c t _JD3XX_OVERLAPPED {7 OVERLAPPED overlapped ;8 p i p e B u f f e r _ t pipeBuffer ;9 } JD3XX_OVERLAPPED, ∗LPJD3XX_OVERLAPPED ;

ALGORITMO 3.2: Estructura overlapped del wrapper

Esta estructura tiene una estructura OVERLAPPED como la que requiere readPi-pe para poder trabajar con resultados solapados y tiene también un buffer dondese almacenarán los datos durante todo el tiempo de recepción. Esta estructura seinicializa cuando se llama desde Java a al método initializeOverlapped cuyo algo-ritmo puede verse en 3.3. Como se puede ver, el wrapper crea una estructura comola definida en 3.2 y la inicializa llamando a la función FT_InicializeOverlappedprovista por el driver de FTDI. Para poder crear y utilizar N estructuras de es-tas simultáneamente, se devuelve a Java un jlong con el puntero a la estructuracreada.

1 JNIEXPORT j l o n g JNICALL2 Java_ jd3xx_JD3XX_ini t ia l izeOver lapped ( JNIEnv ∗env , j o b j e c t ob j ) {3 FT_STATUS s t ;4 j i n t hnd = get_handle ( env , ob j ) ;5 LPJD3XX_OVERLAPPED jd3xxOverlapped ;6 jd3xxOverlapped = jd3xxCreateOverlapped ( ) ;7 i f ( jd3xxOverlapped == NULL)8 i o _ e x c e p t i o n _ s t a t u s ( env , FT_OTHER_ERROR) ;9 i f ( ! FT_SUCCESS ( s t = FT_In i t ia l izeOver lapped ( (FT_HANDLE) ( i n t p t r _ t ) hnd ,


10 &(jd3xxOverlapped−>overlapped ) ) ) )11 i o _ e x c e p t i o n _ s t a t u s ( env , s t ) ;12 re turn ( j l o n g ) jd3xxOverlapped ;13 }

ALGORITMO 3.3: Creacion de la estructura overlapped del wrapper

Luego para usar la estructura creada e inicializada para realizar una recepción dedatos el usuario de Java deberá enviar el jlong devuelto por la función initiali-zeOverlapped. En el Algoritmo 3.4 se pude ver como el jlong overlapped resultrecibido de Java es casteado a LPJD3XX_OVERLAPPED y luego utilizado en elllamado a la función FT_readPipe. Es importatne remarcar también aqui que enel llamado a FT_readPipe se pasa, como buffer para guardar los datos recibidos,el puntero jd3xxOverlapped->pipeBuffer.data que es un buffer local y no el deJava donde deben almacenarse finalmente los datos recibidos.

1 JNIEXPORT void JNICALL2 Java_jd3xx_JD3XX_startReadPipe ( JNIEnv ∗env , j o b j e c t obj , j b y t e pipeID ,

j i n t len , j l o n g overlapped ) {3 FT_STATUS s t ;4 v o l a t i l e DWORD r e t ;5 j i n t hnd = get_handle ( env , ob j ) ;6 LPJD3XX_OVERLAPPED jd3xxOverlapped = (LPJD3XX_OVERLAPPED) overlapped ;7 i f ( jd3xxOverlapped==NULL) {8 j c l a s s exc =(∗env )−>FindClass ( env , " java/lang/NullPointerExcept ion " ) ;9 i f ( exc != 0) {

10 (∗ env )−>ThrowNew( env , exc , NULL) ;11 }12 (∗ env )−>DeleteLocalRef ( env , exc ) ;13 re turn ;14 }15 prepareBuf fers ( jd3xxOverlapped , len ) ;16 s t = FT_ReadPipe ( (FT_HANDLE) ( i n t p t r _ t ) hnd , pipeID ,17 (LPVOID) ( jd3xxOverlapped−>pipeBuffer . data ) , len , (LPDWORD)&ret ,18 (LPOVERLAPPED) &(jd3xxOverlapped−>overlapped ) ) ;19 i f ( ( s t !=FT_IO_PENDING) && ( ! FT_SUCCESS ( s t ) ) ) {20 i o _ e x c e p t i o n _ s t a t u s ( env , s t ) ;21 }22 }


Por último cuando el usuario desde Java llama a la función getOverlappedRe-sults, que también recibe el parámetro jlong overlapped para poder acceder a laestructura inicializada anteriormente, se copian finalmente los datos a Java desdeel buffer local utilizando las funciones GetPrimitiveArrayCritical y ReleasePrimi-tiveArrayCritical como se puede ver en el Algoritmo 3.5.

1 JNIEXPORT j i n t JNICALL2 Java_jd3xx_JD3XX_getOverlappedResults ( JNIEnv ∗env , j o b j e c t obj , j b y t e

pipeID , jbyteArray arr ,3 j i n t of f , j l o n g overlapped ) {4 FT_STATUS s t ;5 v o l a t i l e DWORD r e t ;6 j i n t hnd = get_handle ( env , ob j ) ;7 i n t a len = (∗ env )−>GetArrayLength ( env , a r r ) ;8 j b y t e ∗buf ;9 LPJD3XX_OVERLAPPED jd3xxOverlapped = (LPJD3XX_OVERLAPPED) overlapped ;

10

11 [ . . . ]12

3.6. Software de ensayo en Java 55

13 i f ( ! FT_SUCCESS ( s t = FT_GetOverlappedResult ( (FT_HANDLE) ( i n t p t r _ t ) hnd ,14 &(jd3xxOverlapped−>overlapped ) , (LPDWORD)&ret , TRUE) ) ) {15 i o _ e x c e p t i o n _ s t a t u s ( env , s t ) ;16 }17

18 // Copy data to Java19 buf = (∗ env )−>G e t P r i m i t i v e A r r a y C r i t i c a l ( env , arr , 0 ) ;20 memcpy( buf+of f , jd3xxOverlapped−>pipeBuffer . data , len ) ;21 (∗ env )−>R e l e a s e P r i m i t i v e A r r a y C r i t i c a l ( env , arr , buf , 0 ) ;22

23 re turn ( j i n t ) r e t ;24 }


Por último se debe llamar a la función releaseOverlapped para liberar toda lamemoria utilizada por los buffers locales.

3.6. Software de ensayo en Java

El diagrama en bloques del software de ensayos puede ser apreciado en la Figura3.26. Como se puede ver en la imagen el software consta de múltiples threads cuyoobjetivo es poder estimular los canales en forma independiente.

FIGURA 3.26: Diagrama en bloques software de ensayos.

El software tiene un thread principal y crea dos threads por cada canal, estos sonRxThread y CheckRxDataThread. El thread principal se comunica con cada unode los threads utilizando una serie de colas de mensajes donde les envía la con-figuración del prueba que se va a realizar, el comienzo y el fin de la misma. Porotro lado posee una única cola de recepción de mensajes donde todos los threadsle enviarán si ocurrió algún error y se debe detener la prueba.

El RxThread es el encargado de recibir los datos que llegan del FT601. Este threades crítico dado que si este thread se bloquea, aumentará el largo requerido para


los buffers de transmisión, y si este thread no es lo suficientemente rápido no sepodrá alcanzar el ancho de banda deseado.

El Algoritmo 3.6 muestra como implementa este thread el sistema de resultadossolapados explicado en la Sección 3.5. Como se puede ver, antes de comenzar elloop principal de adquisición de datos se realiza un primer ciclo for inicializan-do las N estructuras overlapped definidas y se dispara N lecturas de packetSizedatos. Luego en el loop principal, se espera hasta que el overlapped más antiguotermine de recibir los datos, luego los envía al thread CheckRxDataThread, porúltimo comienza una nueva lectura con el overlapped recientemente liberado.

1 f o r ( i =0 ; i <overlapped . length ; i ++) {2 overlapped [ i ] = jd3xx . i n i t i a l i z e O v e r l a p p e d ( ) ;3 jd3xx . s tar tReadPipe ( getRxPipeID ( channel ) , packetSize , overlapped [ i ] )

;4 }5 byte [ ] b u f f e r ;6 i n t countData ;7 i =0 ;8 while ( notDone ) {9 b u f f e r = createOrRecycle ( packetS ize ) ;

10 countData = jd3xx . getOverlappedResults ( getRxPipeID ( channel ) , buffer ,0 , overlapped [ i ] ) ;

11 i f ( countData != b u f f e r . length ) {12 throw new IOException ( " I n v a l i d Packet Length Received , expected " +13 b u f f e r . length + " rece ived " + countData ) ;14 } e l s e {15 sendData ( b u f f e r ) ;16 }17 jd3xx . s tar tReadPipe ( getRxPipeID ( channel ) , packetSize , overlapped [ i ] )

;18 i = ( i <overlapped . length −1)? i + 1 : 0 ;19 msg = inMessageQueue . p o l l ( ) ;20 i f ( ( msg!= n u l l ) && (msg . ge tClass ( ) . isAssignableFrom ( ThreadMessage .

Sleep . c l a s s ) ) ) {21 notDone = f a l s e ;22 }23 }

ALGORITMO 3.6: Loop principal de RxThread

Este thread dispone de dos colas para comunicarse con el thread CheckRxDataTh-read, la primera de ellas, inDataQueue es utilizada para reciclar los objetos que elthread CheckRxDataThread ya procesó. Esto implementa el reciclado de objetosmencionado en la Subsección 2.3.3. La segunda, outDataQueue, es utilizada paraenviar los objetos nuevos al thread CheckRxDataThread para que los chequee.

En el Algoritmo 3.6 la función createOrRecycle se encarga de entregarle a estethread un objeto reciclado o un objeto nuevo de la cola inDataQueue y la funciónsenData se encarga de enviar el nuevo paquete recibido al thread CheckRxDa-taThread. El Algoritmo 3.7 muestra el como se implementa las funciones crea-teOrRecycle y sendData. Como se puede ver la función de reciclaje solo crea unnuevo paquete si no hay paquetes para reciclar o si el paquete a reciclado no tieneel mismo largo que el paquete nuevo.

1 protec ted byte [ ] createOrRecycle ( i n t packetS ize ) {2 byte [ ] recyc led = inDataQueue . p o l l ( ) ;3 i f ( ( recyc led == n u l l ) || ( packetS ize != recyc led . length ) ) {4 recyc led = new byte [ packetS ize ] ;5 }

3.6. Software de ensayo en Java 57

6 re turn recyc led ;7 }8 protec ted void sendData ( byte [ ] toSend ) {9 i f ( outDataQueue != n u l l ) {

10 t r y {11 outDataQueue . put ( toSend ) ;12 } ca tch ( InterruptedExcept ion ex ) {13 Logger . getLogger ( AbstractThread . c l a s s . getName ( ) ) . log ( Level .

SEVERE , null , ex ) ;14 }15 }16 }

ALGORITMO 3.7: Funciones createAndRecycle y sendData

El thread CheckRxDataThread es el encargado de revisar los datos recibidos ycomputar las estadísticas sobre estos datos. Según el tipo de prueba que se estérealizando este bloque analiza los datos de distinta forma.

Si se trata de rampa, compara los bytes recibidos con la rampa esperada y si nocoinciden envía el mensaje de error al thread principal. Tras cada paquete recibidoincrementa un contador con la cantidad de bytes recibidos y suma a un contadorde tiempo el tiempo transcurrido desde la ultima recepción de un paquete. Alfinal el test, dividiendo estos dos contadores se obtiene la métrica de cantidad debytes por segundo recibidos.

Si en cambio se trata de una prueba de largo de buffers, como se vio en la Sección3.4, cada palabras del paquete recibido indica la cantidad de palabras en el buf-fer virtual. Lo que se hace este bloque con estos datos es generar un especie dehistograma con la cantidad de palabras en el buffer, para ello tiene un vector de65535 elementos y para cada palabra DN del paquete recibido se incrementa enuno la posición DN de este vector. Este arreglo será posteriormente procesado enMatlab para determinar el largo de los buffers. En conclusión la posición N delvector indica cuantas veces hubo N muestras en el buffer virtual.

Tras terminar cada prueba el thread principal consulta al CheckRxDataThread lasestadísticas computadas y las escribe en un archivo para su procesamiento poste-rior en matlab.

Si la prueba era una prueba de rampa, se genera un archivo cuyo nombre esramp[número de canal ]_[ largo del paquete en bytes ]B_[ velocidad teórica enMbps ]MBps_[ Duración del test en segundos ]s_Speed.csv. Su contenido es detres valores separados por comas con la cantidad de bytes recibidos en bytes, eltiempo total que llevó recibirlos en nanosegundos, y la cantidad total de paquetesrecibidos.

Si la prueba era una prueba de buffers, genera dos archivos. El primero de ellostiene el mismo formato que el de la prueba de rampa y su nombre es buffer[número de canal ]_[ largo del paquete en bytes ]B_[ velocidad teórica en Mbps]MBps_[ Duración del test en segundos ]s_Speed.csv. El segundo cuyo nombre esbuffer[ número de canal ]_[ largo del paquete en bytes]B_[ velocidad teórica enMbps]MBps_[ Duración del test en segundos]s_Buffer.csv tiene el valor final delvector con la cantidad muestras en el buffer virtual separado por comas.

El bloque TxThread encargado de poner a prueba la velocidad de bajada desdela PC hacia la FPGA no llegó a ser implementado en para la fecha de escritura de


esta memoria. Se deja documentado dónde debería estar este bloque cuando selo implemente en el futuro.

3.7. Portabilidad

Para poder utilizar este proyecto en un sistema operativo Linux es necesario re-compilar la biblioteca jd3xx para dicho sistema operativo. Se debe utilizar la bi-blioteca libftd3xx.so en lugar de la biblioteca FTD3XX.lib provista por FTDI11.

Como se vio en la Sección 2.2 para poder migrar este proyecto a otra FPGA de lamisma familia se deberá cambiar únicamente el archivo de asignación de pines.

En cambio si se desea migrar este proyecto a otra FPGA de otra familia, seránecesario regenerar el bloque usbFIFO.vhd. Se debe tener particular cuidado alregenerar este bloque dado que su configuración correcta es vital para el funcio-namiento de la biblioteca. Para los detalles específicos sobre como configurarlareferirse a la Subsección 3.3.5.

11http://www.ftdichip.com/Drivers/D3XX.htm

http://www.ftdichip.com/Drivers/D3XX.htm

59

Capítulo 4

Ensayos y resultados

En este capítulo se muestra como configurar el kit de desarrollo UMFT601A pararealizar las pruebas. Se Muestra también los resultados de las pruebas graficandolas velocidades máximas alcanzadas y los largos de buffer necesarios para 1, 2 y4 canales de transmisión recepción configurados.

4.1. Configuración del FT601

Para realizar las pruebas es necesario cambiar la configuración por defecto delFT601. La Figura 4.1 muestra como queda configurado el FT601 para las pruebasde 1 canal de transmisión/recepción. Para realizar esta configuración se utiliza elprograma FT60X Chip Configuration Programmer1 cuya guía de usuario se puedever en [8].

FIGURA 4.1: Configuración del FT601 para pruebas de 1 canal.

Los parámetros a cambiar se pueden apreciar en la Tabla 4.1.

1http://www.ftdichip.com/Support/Utilities.htm#FT60X_Configuration

http://www.ftdichip.com/Support/Utilities.htm#FT60X_Configuration

60 Capítulo 4. Ensayos y resultados

TABLA 4.1: Parámetros de configuración del FT601

Parámetro Valor Descripción

FIFO clock 66 MHz Como se vio en la Subsección 3.2.2 porun tema de hardware no se puede usar el

clock de 100 MHz.FIFO mode 600 Mode Como se vio en 2.3.1 usamos el modo

Multi-Channel FIFO que corresponde coneste parámetro en 600 mode.

Channel Config 1 Channel Configuración para las pruebas de 1 canal2 Channels Configuración para las pruebas de 2 canales4 Channels Configuración para las pruebas de 4 canales

Ignore Session Tildar Esta opción debe tildarse para poderUnderrun transferir tasas de transferencia menores

a la máxima sin que el chip corte elpaquete por buffer underrun.

On Multiple of Tildar Se ignora el underrun cuando se agreganFIFO bus-width datos a la FIFO de tamaño bus-width, es

bytes decir 4 bytes.

4.2. Pruebas de velocidad

En la Figura 4.2 se puede ver la velocidad máxima de transferencia alcanzadapara los distintos largos de paquete y para las distintas configuraciones de can-tidad de canales. Como se puede apreciar la velocidad máxima es relativamenteconstante para los distintos largos de paquete. Sin embargo, la configuración decantidad de canales de FT601 afecta fuertemente este ancho de banda. Para doscanales se obtiene un velocidad máxima de más de 1684 Mbps, esto es 64 Mbpsmenos que los 1748 Mbps que se obtienen para un solo canal. Para cuatro canalesel deterioro es mucho mayor, se obtiene sólo 1053 Mbps, es decir 731 Mbps menosque para un solo canal.

Normalizando el ancho de banda máximo al valor de un canal, cuando se confi-gura el FT601 en dos canales se pierde un 4 % del ancho de banda. Y cuando seconfigura el FT601 en cuatro canales se pierde un 40 % del ancho de banda.

4.3. Prueba de largo de buffer 61

FIGURA 4.2: Ancho de banda vs largo de paquete.

4.3. Prueba de largo de buffer

Las figuras 4.3, 4.4 y 4.5, muestran el largo de buffers necesario para que, en ellapso de cinco minutos seguidos de adquisición, los buffer no se llenen para lasdistintas velocidades de transferencia y los distintos tamaños de paquetes. En losgráficos, cada curva representa una velocidad de adquisición, la leyenda indicacual es dicha velocidad en Mbps.

En el caso particular de la Figura 4.5 no se computan las velocidades superio-res a los 1053 Mbps porque al ser mayores al ancho de banda máximo para estaconfiguración dan siempre buffer lleno.


FIGURA 4.3: Largo de buffers vs largo de paquete para un canal.

FIGURA 4.4: Largo de buffers vs largo de paquete para dos cana-les.


FIGURA 4.5: Largo de buffers vs largo de paquete para cuatro ca-nales.


Dividiendo el largo de los buffers por la velocidad de transferencia se puede ob-tener el largo de los buffers en tiempo. Es decir cual es el tiempo máximo queel bus del FT601 se bloquea no permitiendo el ingreso de nuevos bytes desde laFPGA. La figuras 4.6, 4.7 y 4.8 muestran este tiempo en microsegundos. Como sepuede ver en las figuras, para todas las configuraciones este tiempo es siempreinferior a 1,6 milisegundos.

FIGURA 4.6: Tiempo de buffers vs largo de paquete para un canal.


FIGURA 4.7: Tiempo de buffers vs largo de paquete para dos ca-nales.

FIGURA 4.8: Tiempo de buffers vs largo de paquete para cuatrocanales.

67

Capítulo 5

Conclusiones

5.1. Trabajo realizado

Los resultados presentados en el capítulo 4 permiten obtener las siguientes con-clusiones:

Para configuraciones del FT601 de uno y dos canales se obtuvieron veloci-dades de transferencia mayores a los 1280 Mbps.

Para la configuración del FT601 de cuatro canales no es posible alcanzar1280 Mbps por ende no puede utilizarse esta cantidad de canales si se deseaalcanzar este ancho de banda.

Se obtuvo una tasa de 0 bytes erróneos durante 15 pruebas, de 5 minu-tos seguidos cada una, realizadas para medir las máximas velocidades detransferencia.

Se obtuvieron las tasas máximas de transferencia del FT601 que fueron:

• más de 1748 Mbps, para un canal configurado en el FT601.

• más de 1684 Mbps, para dos canales configurado en el FT601.

• más de 1053 Mbps, para cuatro canales configurado en el FT601.

Se obtuvieron gráficos con los largos de los buffers necesarios para evitarun desborde para las distintas configuraciones de ancho de banda, largo depaquete y cantidad de canales configurados en el FT601.

Como se muestra en la Subsección 3.2.2 a causa del hardware prototipo ele-gido no se pudo configurar el FT601 con clock de bus a 100 Mhz y debió serconfigurado en 66 Mhz. Es muy probable que con otro hardware que per-mita configurar el clock a 100 MHz se puedan obtener mejores resultados.

La metodología de trabajo utilizada, explicada en la Sección 3.1 permite afirmarque se cumplieron todos los requerimientos sobre la metodología de trabajo.

En conclusión se pudo realizar y poner a prueba una biblioteca de firmware, paracomunicar por USB 3.0 una FPGA con una PC, que cumplió con todos los reque-rimientos enunciados en la Sección 2.1.

La Tabla 5.1 muestra el uso de recursos de la biblioteca desarrollada para las di-ferentes cantidades de canales. Como se puede ver el uso de recursos es extrema-damente bajo.

68 Capítulo 5. Conclusiones

TABLA 5.1: Cantidad de recursos utilizados por la biblioteca

Canales Celdas Lógicas Bits de memoria

1 418 (0.35 %) 17408 (0.44 %)2 759 (0.64 %) 34816 (0.87 %)4 1542 (1.3 %) 69632 (1.75 %)

5.2. Trabajo futuro

Para completar este trabajo sería conveniente evaluar los siguientes ítems que nollegaron a realizarse por cuestiones de tiempo:

Medir el ancho de banda de transmisión desde la PC hacia la FPGA.

Medir el ancho de banda de transferencia full duplex, es decir el mismocanal transmitiendo y recibiendo simultáneamente, y que impacto tiene enel tamaño de los buffers de transmisión.

Medir el ancho de banda de todos los canales transmitiendo y recibiendosimultáneamente, y que impacto tiene en el tamaño de los buffers de trans-misión y de recepción

Realizar las mismas pruebas en el sistema operativo Linux.

Realizar las mismas pruebas en un hardware que permita configurar elFT601 con un clock de 100 Mhz.

69

Apéndice A

Información adicional delHardware Prototipo

A.1. Esquemáticos

FIGURA A.1: Esquemático del Hardware prototipo

70 Apéndice A. Información adicional del Hardware Prototipo

A.2. Lista de materiales

TABLA A.1: Lista de materiales del hardware prototipo

Cantidad Designador Fabricante NP fabricante NP digi-key

1 M2 FTDI UMFT601A-B 768-1301-ND1 M1 Altera DK-DEV-3C120N 544-2444-ND

A.3. Armado

FIGURA A.2: Instrucciones de armado del hardware

A.4. Conexión entre el UMF601A-B y el DK-DEV-3C120N 71

FIGURA A.3: Vista 3D del hardware

A.4. Conexión entre el UMF601A-B y el DK-DEV-3C120N

TABLA A.2: Conexión entre el UMF601A-B y el DK-DEV-3C120N

Señal PIN HSMC HSMA PINFT601 FT601 UMFT601A DK-DEV-3C120N FPGA

D_CLK 68 40 40 AG1DATA0 40 41 41 AB6DATA16 60 42 42 AF2DATA1 41 43 43 AF3DATA17 61 44 44 AC5DATA2 42 47 47 R7DATA18 62 48 48 AB2DATA3 43 49 49 R6DATA19 63 50 50 AB1DATA4 44 53 53 V4DATA20 64 54 54 Y4DATA5 45 55 55 V3DATA21 65 56 56 Y3

72 Apéndice A. Información adicional del Hardware Prototipo

TABLA A.3: Conexión entre el UMF601A-B y el DK-DEV-3C120NCont.

Señal PIN HSMC HSMA PINFT601 FT601 UMFT601A DK-DEV-3C120N FPGA

DATA6 46 59 59 T4DATA22 66 60 60 U3DATA7 47 61 61 T3

DATA23 67 62 62 U4DATA8 50 65 65 R3

DATA24 69 66 66 W2DATA9 51 67 67 R4

DATA25 70 68 68 W1DATA10 52 71 71 M8DATA26 71 72 72 V2DATA11 53 73 73 M7DATA27 72 74 74 V1DATA12 54 77 77 P2DATA28 73 78 78 U2DATA13 55 79 79 P1DATA29 74 80 80 U1DATA14 56 83 83 M4DATA30 75 84 84 U6DATA15 57 85 85 M3DATA31 76 86 86 U5BE_N_0 4 101 101 L7TXE_N 8 102 102 N4BE_N_1 5 103 103 L6RXF_N 9 104 104 N3BE_N_2 7 107 107 K8SIWU_N 10 108 108 L4BE_N_3 8 109 109 L8WR_N 11 110 110 L3GPIO_1 18 113 113 K4RD_N 12 114 114 L2

GPIO_0 17 115 115 K3OE_N 13 116 116 L1

RESET_N 15 119 119 J4Wake_up_N 16 121 121 J3

73

Bibliografía

[1] Cyclone III Development Board Reference Manual. v 1.2. Altera. 2008.[2] Cyclone III Development Kit Host Board. 150-0310703-D1. rev D-1. Altera.

2007.[3] D3XX Programmers Guide. AN_379. 2016.11.01. FTDI. 2016.[4] FIFO Bus Master for FT60x. AN_421. v 1.3. FTDI. 2017.[5] FT600 Data Loopback Application User Guide. AN_375. v 1.0. FTDI. 2015.[6] FT600 Data Streamer Application User Guide. AN_387. v 1.0. FTDI. 2015.[7] FT600Q-FT601Q IC Datasheet. v 1.05. FTDI. 2017.[8] FT60X Configuration Programmer User Guide. AN_370. v 1.5. FTDI. 2017.[9] SCFIFO and DCFIFO IP Cores User Guide. UG-MFNALT_FIFO. 2017.11.06.

Altera. 2017.[10] UMFT60x FIFO TO USB 3.0 Bridge Evaluation Board. FT_001191. v 1.1.

FTDI. 2017.

Documents

Diseño e implementación de USB 3.0 super speed para FPGAlaboratorios.fi.uba.ar › lse › tesis › LSE-FIUBA-Trabajo-Final... · 2019-02-16 · III Resumen En este trabajo se