Esta página es la cuarta de una serie de cinco sobre cómo convertirse en diseñador profesional de FPGA. Esta vez repaso algunas habilidades que son menos importantes para empezar. Empiezo explicando el sentido de hacer esto en primer lugar.
¿Por qué mencionar algo que no es importante?
Puede parecer un poco raro escribir una página sobre habilidades y al mismo tiempo decir "bah, esto no es tan importante". Pero esta serie no va de que yo te diga lo que tienes que hacer. Más bien, intento explicar por qué cada tema es importante (o no tan importante). Así que tiene sentido hacer lo mismo también con los temas menos importantes.
Algunas habilidades prácticas son a menudo útiles, pero están sobrevaloradas. Son habilidades que puede que necesites adquirir en algún momento, pero también cabe la posibilidad de que nunca las necesites. El motivo de que un tema pueda estar sobrevalorado es que aparece a menudo en diseños de ejemplo para placas. No porque sea importante, sino porque es relativamente fácil hacer una demo bonita e impresionante con una técnica concreta.
Para que quede claro: todas las habilidades mencionadas a continuación son útiles. Lo que ocurre es que a menudo se adquieren según van haciendo falta para trabajar en un proyecto, junto con un montón de otros temas técnicos específicos de los requisitos de ese proyecto.
I2C y SPI
Puedes trabajar toda tu vida como diseñador de FPGA sin saber nada de estos dos. Pero, siendo realistas, hay muchas probabilidades de que te los encuentres bastante pronto en tu trabajo práctico.
I2C (IIC, Inter-Integrated Circuit), los protocolos muy similares a él, y SPI (Serial Peripheral Interface) son con diferencia los estándares más comunes para transmitir datos desde y hacia un componente electrónico en una PCB. Se basan en un esquema maestro / esclavo, en el que el maestro inicia una operación de lectura o escritura, y el esclavo posiblemente responde a ella. En la mayoría de los casos, el maestro es un procesador o un componente relativamente sofisticado, y el esclavo es un componente más sencillo con una función periférica en el diseño electrónico.
I2C y los protocolos derivados de él tienen una velocidad de datos muy baja (normalmente en torno a 100 kbit/s) y se usan principalmente para configurar los parámetros de un componente. Por ejemplo, si el componente es un convertidor A/D, I2C se puede usar para seleccionar qué referencia de tensión usará el componente y si su salida debe darse como un entero con signo o sin signo. La principal ventaja de este protocolo es que la conexión consta solo de dos cables: reloj (SCL) y datos (SDA). También hay una conexión a masa (GND), pero normalmente se hace a través de la masa común de la PCB y prácticamente nunca requiere un cable aparte.
En realidad, el protocolo es un bus, así que cada ciclo de intercambio de datos incluye una dirección de 7 bits. En consecuencia, se pueden conectar varios componentes a este par de cables en paralelo. En ese caso, cada componente tiene que tener una dirección distinta.
El estándar I2C fue patentado originalmente por Philips. Como era tan útil, se usan habitualmente muchas variantes sorprendentemente parecidas, por ejemplo SMBus, PMBus y DDC2. Estos estándares adoptan las ideas principales de I2C, pero tienen parámetros ligeramente distintos (en particular las velocidades de datos) y escenarios de uso principales distintos. Por ejemplo, todos los monitores de ordenador que se venden hoy en día llevan una pequeña memoria flash que contiene información sobre qué modos gráficos admiten. El cable entre la tarjeta gráfica del ordenador y el monitor tiene dos hilos conectados a esa memoria flash. Esto permite a la tarjeta gráfica leer los datos de esa memoria con el protocolo DDC2, que en la práctica es lo mismo que I2C.
Así que, si entiendes I2C, sabes cómo se comunican entre sí un montón de componentes distintos.
Pasemos ahora a SPI. Este protocolo suele requerir cuatro cables entre los componentes maestro y esclavo (SCLK, MOSI, MISO, SSn). A veces se usa para configurar un componente, igual que I2C y sus variantes. Sin embargo, el uso principal de SPI es transmitir datos a velocidades de datos más altas. No es raro que los componentes admitan una frecuencia de SCLK de 20–50 MHz, así que es un protocolo práctico para transmitir datos de aplicación. Por ejemplo, un convertidor A/D para dos canales de audio genera 48.000 Hz × 2 × 16 bits = 1,536 Mbit/s. Esta velocidad de datos es pan comido para SPI. Y, en efecto, hay varios chips de audio que usan SPI para transmitir muestras.
También merece la pena mencionar que la conexión entre la FPGA y la memoria flash desde la que lee su flujo de bits (bitstream) suele ser QSPI. Esta interfaz es igual que SPI normal, pero con cuatro cables de datos en lugar de uno, lo que hace que la transferencia de datos sea más rápida.
Así que, a la pregunta final: ¿deberías aprender I2C y SPI como parte de convertirte en diseñador de FPGA? Mi opinión es que no tienen nada que ver con el diseño de FPGA en sí mismos. Pero si trabajas en un equipo pequeño que desarrolla un producto electrónico, lo más probable es que necesites configurar alguno de los componentes con I2C. O que alguno de los componentes conectados a la FPGA use SPI para comunicarse. O quizá usar directamente desde tu propia lógica la memoria flash que contiene el flujo de bits (bitstream) de la FPGA.
Hay muchos casos de uso para estos dos protocolos, pero lo más importante es reconocerlos a ellos y a sus variantes cuando aparecen en las hojas de características. A menudo un componente usa uno de estos protocolos, pero no menciona su nombre explícitamente. Si conoces los principios que hay detrás de I2C, no puedes pasarlo por alto cuando la hoja de características describe una interfaz similar. Lo mismo ocurre con SPI.
Y si te sientas en una entrevista de trabajo y afirmas ser un diseñador de FPGA con experiencia, pero no sabes nada de estos dos protocolos, puede que no resulte tan impresionante.
Además, aquí tienes una sugerencia de proyecto para ganar algo de experiencia: es bastante fácil encontrar un sensor de temperatura barato u otro tipo de componente sencillo que use I2C o alguna de sus variantes. Compra un componente así, conéctalo a tu placa de FPGA con cables Dupont o algún otro método chapucero. Después escribe desde cero todo lo necesario para interactuar con él a través de I2C. Si tienes un osciloscopio, úsalo para monitorizar las señales. Este puede ser tu primer proyecto de bricolaje.
Diseño por bloques (block design)
La mayoría de las herramientas de diseño de FPGA ofrecen la posibilidad de conectar bloques de diseño lógico mediante una interfaz gráfica. En principio, usar esta interfaz equivale bastante a instanciar módulos en Verilog. Los cables dibujados gráficamente son como las conexiones de puertos en Verilog. Una herramienta de diseño por bloques suele ofrecer algunas capacidades más, por ejemplo insertar automáticamente pequeños fragmentos de lógica que garantizan que las conexiones hechas en la interfaz gráfica (GUI) hagan lo que el usuario pretendía.
El método de diseño por bloques da lo mejor de sí cuando todos o la mayoría de los bloques los suministra el fabricante de la FPGA (en forma de bloques IP (IP blocks)). En particular, cuando hay un procesador de por medio, el diseño por bloques suele ser la forma natural de conectarlo con bloques IP que implementan funciones periféricas: controladores de interrupciones, controladores DMA, árbitros de bus, etcétera. También hay periféricos más "clásicos", por ejemplo controladores Ethernet.
Aparte de los obvios bloques relacionados con el procesador, también hay una gran selección de bloques IP que implementan una amplia gama de funciones habitualmente implementadas en una FPGA. Van desde elementos de FPGA como los recursos de reloj y la lógica adyacente a los pines de E/S, pasando por unidades aritméticas sencillas, hasta filtros digitales y lógica aún más compleja. Parece que la idea era hacer posible crear un diseño de FPGA completo usando solo un diseño por bloques.
Dicho esto, nunca he oído hablar de nadie que construyera un proyecto de FPGA razonablemente útil solo con estos bloques IP ya hechos. Salvo un proyecto que consista únicamente en un procesador y sus periféricos, pero si solo quieres un procesador, ¿por qué usas una FPGA? Es mucho más caro y complicado.
Pero un diseño por bloques completo puede instanciarse en un módulo Verilog, y normalmente se hace, igual que cualquier otro módulo Verilog o IP. En consecuencia, el diseño por bloques suele ser parte de un proyecto mayor basado en Verilog. En este contexto, un diseño por bloques que contiene solo un procesador y sus periféricos tiene sentido: no es más que un módulo dentro de un proyecto mayor.
Entonces, ¿qué significa esto en cuanto a las habilidades que deberías, o quizá no deberías, aprender?
La habilidad más sencilla es crear diseños por bloques, añadir bloques y conectarlos. Hay montones de tutoriales que te dicen qué hay que pulsar y cuándo. Como estos tutoriales son tan fáciles de seguir y completar, ¿por qué no hacer uno o dos? Y si lo haces, no te molestes en entender cada paso y cada selección hecha a lo largo del proceso. La idea es hacerse una idea de cómo se hace un diseño por bloques. Profundiza en los detalles si y cuando eso resulte relevante.
La siguiente habilidad es incluir un diseño por bloques en un proyecto e instanciarlo en un módulo Verilog. Eso también es bastante sencillo, y hay muchos ejemplos de ello. No es distinto de usar cualquier IP en tu proyecto. Si sabes usar un IP de tipo FIFO en tu proyecto Verilog, también sabes hacer lo mismo con un diseño por bloques.
La habilidad más significativa es convertir algo que has escrito en Verilog en un bloque que pueda usarse en un diseño por bloques. Y, aún más significativo, hacer que ese bloque sea configurable con la propia interfaz gráfica de Vivado (o la suite de desarrollo que uses). No recomendaría aprender a hacer esto a menos que haya un propósito directo para ello. La mayoría de los diseñadores de FPGA nunca necesitan hacer nada de este tipo.
Entonces, ¿cuál es la conclusión? Como con cualquier herramienta gráfica, trastea un poco con ella y luego ve aprendiendo progresivamente todo lo que necesites para completar una tarea. En particular, no esperes hacerlo todo con un diseño por bloques, aunque el conjunto de bloques disponibles pueda llevarte a pensar erróneamente que ese es el camino a seguir.
Trabajar con procesadores dentro de la FPGA
Muchos proyectos, en particular productos electrónicos autónomos, llevan algo de software ejecutándose dentro y, por tanto, implican un procesador. Este procesador puede ser un bloque dentro de la FPGA o un componente físico aparte, fuera de ella. Los retos son completamente distintos en cada caso.
Empezaré con el escenario del procesador dentro de la FPGA. Puede ser un "procesador hard", como los de la familia Zynq de AMD, que llevan un procesador ARM integrado en el silicio. Un "procesador hard" es igual que cualquier otro elemento lógico dentro de la FPGA, comparable a las unidades aritméticas, los PLL y las memorias de bloques. Salvo que un bloque procesador es relativamente grande y tiene un montón de pines.
Si una FPGA no tiene un "procesador hard", todavía puede ejecutar software en un "procesador soft". Por ejemplo, los procesadores Microblaze de AMD y Nios de Altera. La diferencia es que el procesador se implementa con los elementos lógicos normales de la FPGA (el "tejido lógico" (logic fabric)). Este método es más lento, consume más energía y usa recursos lógicos, pero a menudo es suficientemente bueno y una opción rentable.
Tanto los "procesadores hard" como los "procesadores soft" son, en principio, como cualquier módulo Verilog que se conecta con la lógica de la FPGA igual que cualquier otro IP. Por lo tanto, es bastante natural considerarlos parte de la FPGA y, por ende, considerar al diseñador de FPGA responsable de ellos.
Configurar el procesador en el diseño lógico suele ser la tarea relativamente fácil, ya que hay muchos ejemplos y plantillas para ello. Pero rara vez acaba ahí. El procesador necesita tener ciertos periféricos, y estos deben estar disponibles para el software en direcciones conocidas dentro del espacio de memoria del procesador. Los periféricos a menudo tienen salidas de petición de interrupción que deben conectarse correctamente al procesador y configurarse adecuadamente.
El equipo de software suele esperar que otra persona se encargue del fragmento de software que se ejecuta cuando el procesador se enciende o recibe una señal de reset. Este software consta de rutinas que, entre otras cosas, escriben en los propios registros hardware del procesador para hacer que funcione según la configuración. Esto no es tan difícil como puede sonar, ya que las herramientas de desarrollo crean código C para incluirlo en el proyecto de software mayor con este propósito. Pero, ¿quién es responsable de generar estos archivos y de asegurar que estén sincronizados con el resto del diseño de FPGA? En un equipo de desarrollo pequeño, el diseñador de FPGA.
Y si eso no fuera suficiente, puede que se pida al diseñador de FPGA que cree periféricos para el procesador que implementen lógica específica del producto desarrollado. Escribir los controladores (drivers) para esa lógica en C suele ser más que bienvenido.
Así que, ¿es esto algo que haya que empezar a aprender como parte de convertirse en diseñador de FPGA? Si quieres trabajar en la intersección entre software y hardware, yo diría que posiblemente sí. Si ya eres programador de C y te gusta la programación de bajo nivel, esto puede ser para ti. Y en particular, si no te importa leer de vez en cuando el manual de usuario del procesador, que es muy grueso. Ahí es donde encuentras la respuesta a "¿cómo puedo tener dos unidades del periférico X y tres del periférico Y?".
¿Qué temas deberías aprender, entonces? Yo diría que adquieras una comprensión básica de cómo los procesadores ejecutan software, cómo acceden a la memoria, cómo funcionan las interrupciones y cómo arrancan los procesadores al encenderse. Mira el mapa de direcciones de un procesador, fíjate en cómo las regiones de memoria se dividen en distintos segmentos (RAM interna, RAM externa, registros internos, segmentos de acceso al bus externo, etcétera) y entiende cómo funciona todo eso.
También te sugiero entender los principios de los protocolos AMBA (AXI3, AXI4, AXI4 Lite, etcétera), en particular el handshake VALID / READY. Si alguna vez diseñas un periférico, lo más probable es que necesites implementar un esclavo AXI. E incluso si trabajas con un procesador que no usa AXI de forma nativa (por ejemplo, los procesadores de Altera), los principios serán los mismos.
Probablemente también seas responsable del software que se ejecuta al encender y al resetear el procesador. Por eso, familiarizarte con cómo se crea este software y cómo se relaciona con los propios registros hardware del procesador puede ayudarte. Y es más fácil si escribes tú las rutinas controladoras para acceder a los periféricos que pueda que tengas que diseñar. Por estas razones, no llegarás muy lejos sin ser bueno programando en C. Aunque uses la IA para que te escriba el código, necesitas entender exactamente qué hace ese código.
Pero, por encima de todo, ten en cuenta que no aprenderás mucho haciendo un largo proyecto de ejemplo en el que has configurado un procesador y has hecho clic, clic, clic y al final ha ocurrido algo muy impresionante en tu placa. Todo lo valioso que había que aprender ya se ha hecho por ti, y te has saltado las partes importantes mientras ibas haciendo clic hacia la línea final. Si hay algo valioso en un proyecto de ejemplo así, es lo que ocurre después de que termines: ¿qué has entendido del ejemplo? ¿Qué puedes cambiar en el proyecto? ¿Qué puedes probar tú mismo?
Trabajar con procesadores fuera de la FPGA
Muy a menudo, el procesador es un componente independiente o forma parte de una placa aparte en un proyecto que incluye una FPGA. No es raro tener un PC completo, ya sea un sobremesa normal o una placa base industrial basada en x86, como parte central de un producto. En estos entornos, es habitual considerar la FPGA como un periférico. Aunque el propósito de la FPGA varía de un proyecto a otro, el procesador (o el PC) suele considerarse el centro del proyecto, y la FPGA (y la electrónica que la rodea) una parte controlada y gestionada por el software.
Como el procesador es una parte física aparte, normalmente hay un equipo distinto encargado de todo lo relativo a él, incluido el software. Las tareas del diseñador de FPGA relacionadas con el procesador consisten principalmente en interconectarse con él. Si solo se espera que el procesador controle el comportamiento de la FPGA, es posible que la comunicación consista únicamente en comandos, posiblemente leyendo o escribiendo registros. En este caso, se suelen usar protocolos más sencillos, en particular I2C y SPI. Ya he tratado estos dos más arriba. También puede elegirse SPI para el intercambio de datos a velocidades de datos relativamente bajas.
Merece la pena mencionar que I2C y SPI se usan habitualmente solo con procesadores embebidos. Estos protocolos son menos comunes con periféricos específicos de un proyecto cuando hay una placa base de PC de por medio. Aunque SMBus se usa a menudo para controlar ventiladores y obtener lecturas de temperatura, es menos habitual usar protocolos de este tipo con tus propios periféricos.
Con procesadores embebidos (y DSP), también ocurre que la interfaz con la FPGA se realiza a través de una interfaz específica del procesador (o de una familia de procesadores de un fabricante concreto). Por ejemplo, puede que el procesador tenga muchos pines físicos conectados a la FPGA para acceder a ella con una interfaz de bus de direcciones / datos. Implementar la lógica que se interconecta con este bus requiere una comprensión precisa del protocolo (no siempre bien diseñado) definido por el fabricante del procesador. También hay requisitos de temporización que hay que cumplir. Sin embargo, no tiene sentido prepararse para una tarea de este tipo, ya que no es distinta de interconectarse con cualquier otro componente externo que tenga un protocolo de E/S complicado.
La interconexión con PCs y procesadores embebidos de gama alta se hace normalmente con la interfaz PCIe (PCI Express). Es un canal de comunicación robusto y bien soportado que permite una velocidad de datos de 200 MB/s (de datos útiles) en su configuración más sencilla, pero el cielo es el límite: salen nuevas versiones del protocolo PCIe a intervalos regulares, y la velocidad de datos aumenta con cada nueva versión. El límite real de velocidad de datos a menudo es lo que el propio procesador puede manejar.
El inconveniente de PCIe es que es un protocolo complicado, pensado principalmente para chips periféricos de ordenador. Se da por supuesto que, si estás implementando algo para PCIe, has asignado personal específico para desarrollar la lógica que se interconecta con el ordenador, y también un equipo de software para desarrollar el controlador (driver). Esta tarea se vuelve mucho más fácil si se usa Xillybus, ya que esta solución se encarga de la complicación en ambos lados.
Entonces, ¿qué habilidades deberías aprender para prepararte para un escenario con un procesador externo? Ante todo, puede ayudar mucho que seas bueno programando en C, para que puedas escribir las rutinas controladoras para acceder a la FPGA desde el procesador, o al menos ofrecer código de ejemplo. La IA puede escribirte este código, pero si no entiendes con precisión lo que hace el código, podrías acabar con un fallo en C que parezca venir de la FPGA.
Aparte de eso, no hay mucho que recomendaría aprender de antemano. Las habilidades técnicas necesarias dependen mucho de cómo se conecten el procesador y la FPGA, lo cual varía de un proyecto a otro.
Otros estándares de interfaz
Si repasas varias placas de desarrollo de FPGA disponibles, verás que algunos componentes y conectores concretos tienden a estar presentes más habitualmente que otros. Esto puede interpretarse como una indicación de qué tecnologías se usan a menudo en un proyecto de FPGA. Es cierto en parte, y repasaré algunas de ellas.
HDMI
Un conector HDMI está a menudo presente en las placas de FPGA. Su propósito suele ser permitir que la FPGA genere salida de vídeo para mostrarla en un monitor de ordenador. Los hilos del conector a menudo van directamente a la FPGA, ya que esta es capaz de generar las señales de alta velocidad necesarias con la ayuda del SERDES del bloque de E/S. En algunas placas hay un componente aparte ("codificador de vídeo") entre la FPGA y el conector HDMI.
La ubicuidad de este conector refleja efectivamente la realidad: muchos proyectos de FPGA implican algún tipo de procesado y salida de vídeo. Conectar la placa de FPGA a un monitor de ordenador y experimentar con esa configuración puede ayudar en el futuro. En particular, aprende lo básico de VGA, cómo se escanea la pantalla horizontal y verticalmente, y los distintos modos de visualización estándar que existen. Si el conector HDMI está conectado directamente a la FPGA, puedes intentar implementar la lógica que genera las señales, pero no estoy seguro de que merezca la pena el esfuerzo. No es un protocolo sencillo de aprender y, si no funciona, es difícil depurar un proyecto así: la velocidad de datos en los hilos es muy alta, y el monitor de ordenador no te dirá qué va mal cuando se niegue a responder a la salida de la FPGA. Hay bloques IP ya hechos para este propósito. Te sugiero usarlos y centrarte en cambio en generar datos de vídeo.
Y un pequeño consejo: probablemente quieras enviar píxeles RGB al monitor. En ese caso, sigue el protocolo DVI (que está relacionado con VGA), y no el HDMI. Las señales de DVI y HDMI son intercambiables. Pero HDMI es un protocolo más estricto, pensado para televisión de alta definición estándar, y tiene un conjunto reducido de modos de visualización. Los píxeles de los modos de visualización habitualmente usados se representan en formato YCbCr, lo cual es una dificultad innecesaria. Se usa el conector HDMI porque el conector DVI y su cable son grandes y aparatosos. Pero las señales hacia un monitor de ordenador casi siempre siguen el estándar DVI, no el HDMI.
Si pruebas un proyecto de salida de vídeo, pronto descubrirás que las propias BRAM de la FPGA a menudo no bastan para alojar un fotograma de imagen. Eso me lleva al siguiente tema.
Memorias DDR
La propia RAM de la FPGA es un recurso relativamente escaso. Cuando el proyecto requiere manejar megabytes y gigabytes, se necesita memoria externa. Esto ocurre a menudo en proyectos con vídeo, pero también en otras aplicaciones, como el coprocesado / aceleración hardware, la conmutación de red y más.
Con diferencia, las RAM externas más usadas son las DDR SDRAM, que son del mismo tipo que las usadas en los ordenadores. Por eso aparecen a menudo en las placas de desarrollo de FPGA, a veces como SODIMM y más a menudo soldadas directamente a la placa. Tienen un precio bajo y un ancho de banda excelente, pero están diseñadas pensando en ordenadores. En consecuencia, son eficientes en ancho de banda cuando las peticiones de acceso son ráfagas largas de rangos de direcciones contiguos. El hecho menos conocido sobre ellas es que tienen un rendimiento realmente pésimo cuando el patrón de acceso es menos disciplinado: aunque se llamen "Random Access Memory" (RAM), su rendimiento de ancho de banda cae drásticamente con otros patrones de acceso. Por ejemplo, si se requiere un elemento de datos cada vez, y cada vez desde una dirección no relacionada con la anterior, estas memorias se comportan extremadamente mal.
El protocolo de interfaz con las memorias DDR es muy complicado; sin embargo, rara vez hay necesidad de que los diseñadores de FPGA sepan mucho al respecto: todos los fabricantes de FPGA de renombre suministran un controlador de memoria DDR fiable y bastante eficiente como núcleo IP (IP core) gratuito para usar con sus FPGA. Por lo tanto, al diseñador de FPGA solo se le exige interconectarse con este IP, usando AXI4 o un protocolo similar.
¿Son las memorias DDR un tema que merezca la pena aprender? Yo diría que hay una razón relativamente buena para hacerlo, ya que se usan a menudo en proyectos de FPGA de diversos campos. Un proyecto que implique memorias DDR y que quizá genere salida de vídeo puede ser un buen ejercicio. También se recomienda leer la hoja de características de una memoria DDR para entender la estructura de matriz de la memoria y la necesidad de seleccionar filas antes de acceder a sus datos. También merece la pena mirar los requisitos de retardo entre distintas operaciones (CAS, RAS, refresco, etcétera) para comprender cómo pueden reducir la eficiencia del ancho de banda. Lo más importante que hay que saber sobre estas memorias es cuándo no deben usarse.
Jaula SFP+
Muchas placas de desarrollo, en particular las placas oficiales del fabricante, tienen una jaula SFP+. Esta pieza destaca visualmente, ya que es una pieza metálica relativamente grande en el borde de la placa. Este conector solo está presente cuando la FPGA tiene transceptores multigigabit (MGT, llamados GTX, GTH, GTY, etcétera en las FPGA de AMD). Dentro de la jaula, un conector hace una conexión directa a uno o varios de los MGT de la FPGA.
Un MGT es una unidad funcional que permite comunicación bidireccional a velocidades de gigabit, normalmente 1 Gbit/s y superiores. Es la bestia de carga detrás de varios protocolos bien conocidos, en particular PCIe, USB SuperSpeed, SATA, Gigabit / 10G Ethernet y DisplayPort. Hay toda una serie de páginas sobre los MGT en este sitio web, empezando por una página que explica los MGT en general.
El uso principal de la jaula SFP+ es insertar en ella un módulo de fibra óptica. Esto permite conectar dos placas de FPGA con un cable de fibra óptica, o conectar la placa de FPGA a otra unidad con una interfaz similar, por ejemplo un router de red de fibra óptica. El módulo de fibra óptica normalmente no se incluye en el kit de la placa de desarrollo de FPGA, pero no son muy caros. También hay cables que permiten conectar dos conectores SFP+ directamente, sin fibra.
¿Significa el hecho de que las jaulas SFP+ sean tan comunes en las placas de FPGA que deberías convertirte en experto en MGT cuanto antes? Yo no diría eso. Aparecen mucho en las placas, entre otras razones porque el componente en la placa es barato y no requiere componentes adicionales ni mucha conectividad. También es una forma elegante de conectar dos placas de FPGA en comparación con las alternativas (que normalmente consisten en cuatro cables de RF conectados a cada MGT).
Y los MGT no son fáciles de manejar: en cierto modo son parecidos a los canales de radio digitales. Hay errores de bit en el enlace, la frecuencia de reloj del transmisor a menudo no es exactamente la misma que la del receptor, el receptor necesita encontrar el comienzo de las tramas de datos en el canal de datos, y la lista continúa.
Por eso es habitual que los MGT se usen junto con un bloque IP que gestione el protocolo de comunicación. En particular, prácticamente todas las FPGA con MGT también tienen un bloque IP hard que implementa el protocolo PCIe. También hay núcleos IP (IP cores) para otros cuantos protocolos bien conocidos usados con ordenadores. Para una conexión entre dos FPGA, Xillyp2p presenta una interfaz sencilla.
Así que, aunque los MGT estén por todas partes, este tema no es necesariamente lo primero que hay que aprender.
Ethernet
Muchas placas de desarrollo de FPGA tienen un conector Ethernet. La razón que hay detrás depende del tipo de FPGA.
El caso más fácil de explicar es cuando la FPGA lleva un procesador dentro, por ejemplo los dispositivos Zynq de AMD. En estas placas, el conector Ethernet está casi siempre conectado a los pines dedicados del procesador para ese propósito. Es exactamente igual que el conector Ethernet de cualquier placa con un procesador embebido.
¿Y qué hay de las placas con FPGA sin procesador? En primer lugar, incluso una FPGA así puede contener un "procesador soft" (por ejemplo MicroBlaze o Nios). Un procesador así puede hacer el mismo buen uso de un conector Ethernet que cualquier otro. Este no es necesariamente un escenario de uso común, pero durante mucho tiempo los fabricantes de FPGA intentaron promover la idea de usar FPGA en centros de datos. De verdad querían crear una asociación mental entre las FPGA y los ordenadores. El conector Ethernet forma parte de eso.
Si no hay ningún procesador en la FPGA, el conector Ethernet se puede usar para comunicarse con un ordenador. TCP/IP es quizá lo primero que se te viene a la cabeza, sin embargo este protocolo está hecho a medida para implementarlo en software. Implementar este protocolo en lógica es complicado y da como resultado una funcionalidad limitada. La pila de protocolos también necesita responder a peticiones ARP y, preferiblemente, también a paquetes ICMP.
Por lo tanto, la única forma práctica de usar Ethernet para conectar una placa de FPGA (sin procesador) a un ordenador es con paquetes de difusión (broadcast): la placa de FPGA y el ordenador se conectan punto a punto. Todas las tramas Ethernet transmitidas por el cable tienen la dirección MAC de difusión. Esto se consigue a menudo usando paquetes UDP/IP de difusión. Así que esto está a años luz de la forma en que solemos conectar un ordenador a una red Ethernet.
Aparte de no ser elegante, esta solución tiene un inconveniente importante: el protocolo Ethernet no garantiza la entrega de paquetes. Si hay un error de bit en un paquete Ethernet, se descarta silenciosamente. La tarjeta de red del ordenador también puede descartar aleatoriamente un paquete sin motivo alguno. Esto pasa desapercibido en el uso normal.
Por lo tanto, si no se permite la pérdida de datos, la FPGA debe conservar todos los datos que transmite en un búfer para poder hacer retransmisiones. Hay que aplicar un protocolo con un mecanismo de detección de errores para solicitar esas retransmisiones. Hacerlo bien sobre Ethernet se vuelve realmente complicado.
Alternativamente, se acepta la posibilidad de pérdida de datos. O, como ocurre a menudo en proyectos de estudiantes y aficionados, se ignora esa posibilidad, porque no se da cuando se prueba el sistema. Lo cual es suficientemente bueno cuando el proyecto no es profesional.
En resumidas cuentas: usa sin duda el conector Ethernet si hay un procesador ejecutándose en tu placa, en particular si ejecuta Linux. Pero no sugeriría profundizar más que eso.
Aquí termina la cuarta página de esta serie, y con esto concluye también el repaso de las habilidades profesionales. La página siguiente toma una dirección completamente distinta: ¿qué tipo de personalidad se valora en esta profesión?