1 puntos por GN⁺ 2025-10-05 | 1 comentarios | Compartir por WhatsApp
  • Se presenta un experimento para comprar una placa Kintex UltraScale+ FPGA por 200 dólares y usarla como plataforma de desarrollo
  • La placa se vende sin documentación oficial ni garantía, por lo que hay retos en la depuración por JTAG y en la configuración inicial
  • Se explora la posibilidad de implementar por cuenta propia un entorno de configuración y depuración de FPGA usando OpenOCD y Segger JLink
  • Los objetivos del experimento incluyen la verificación de la interfaz PCIe/Ethernet, la comprobación del pinout y el monitoreo del sistema de una FPGA usada
  • Se resumen los procedimientos paso a paso y la experiencia de resolución de problemas, desde la inicialización y la conexión JTAG hasta la identificación de la scan chain y el monitoreo de temperatura/voltaje

Introducción

  • El autor quería una FPGA potente para prototipado de proyectos grandes, en particular una UltraScale+ de la familia Xilinx Virtex, pero por el costo y la carga de la licencia Enterprise de Vivado redujo sus opciones a chips Kintex UltraScale+ compatibles con WebPack (XCKU3P, XCKU5P)
  • Incluso estos chips ofrecen especificaciones altas para ir más allá del nivel hobby, con LUTs y transceptores GTY, entre otros recursos
  • Se necesitaba una placa de desarrollo que cumpliera con al menos 2 SFP+ o 1 QSFP, JTAG y PCIe x8 o superior; entre diseñarla directamente, comprar un producto de Alinx o buscar en el mercado de segunda mano, terminó comprando en Ebay una placa FPGA aceleradora de Alibaba Cloud por 200 dólares
  • La placa comprada no tenía ningún soporte documental y ni siquiera estaba claro si funcionaba correctamente, pero resultaba atractiva por el bajo precio y por la idea de hackear una placa Kintex UltraScale+

Retos del depurador

  • Según el documento UG908 de Xilinx, lo habitual es configurar y depurar la FPGA con una sonda JTAG recomendada, pero aquí se intentó usar alternativas de código abierto (como OpenOCD) en lugar de una sonda oficial costosa
  • A cambio de renunciar al toolchain oficial de Xilinx (como ILA), es posible desarrollar una lógica de depuración propia basada en registros JTAG USER
  • OpenOCD se usa sobre todo con ARM/RISC-V, pero también puede servir para FPGA gracias a su compatibilidad con una amplia variedad de sondas, el control detallado de operaciones JTAG y el soporte para el formato SVF
  • Hay poca documentación sobre soporte para la serie UltraScale+, pero los estándares JTAG y SVF, así como la estructura de escaneo, siguen siendo válidos

Plan general

  • Se trata de un plan experimental por etapas para tomar una placa FPGA usada comprada barata en Ebay y convertirla en plataforma de desarrollo usando sondas de código abierto o no oficiales sin soporte formal (OpenOCD, JLink, etc.)
  • Cada etapa avanza en el orden de verificar el funcionamiento del hardware → conectar un depurador JTAG → encontrar el pinout → transferir el bitstream

Etapa 1 - Verificar que la placa funciona correctamente

  • Si la memoria Flash no fue borrada, se puede hacer una verificación inicial del funcionamiento identificando un endpoint PCIe o comprobando la presencia de señal Ethernet en el PHY SFP a través del bitstream del usuario anterior

Etapa 2 - Conectar el depurador JTAG

  • Es necesario identificar la ubicación de los pines de la interfaz JTAG, la cantidad de dispositivos conectados y el estado de la daisy chain
  • También se puede aprovechar el monitoreo en tiempo real de temperatura/voltaje mediante los registros del sistema JTAG de la FPGA (especialmente SYSMON), con la expectativa de ampliar el soporte de openOCD

Etapa 3 - Identificar la asignación de pines (pinout)

  • Hace falta analizar el circuito físico para conocer el tipo/frecuencia/pin de conexión de la fuente de reloj externa y la información de los transceptores conectados a SFP y PCIe

Etapa 4 - Escribir el bitstream

  • Se planea usar configuración temporal por JTAG (saltando la Flash), el driver virtex2 + pld de openOCD o la reproducción de SVF generado en Vivado
  • También está previsto automatizar todo el flujo de conversión de Vivado a SVF

Recepción de la placa y pruebas iniciales

  • Se recibió una placa Kintex UltraScale+ FPGA (XCKU3P-FFVB676) proveniente de un acelerador de Alibaba Cloud, junto con un transceptor Huawei SFP28 25G, un cable patch OS2 y otros accesorios
  • La placa muestra algo de uso, pero el estado de los accesorios y de PCIe/SFP es bueno

Verificación de alimentación en modo standalone

  • Se hizo una primera comprobación básica de alimentación inyectando energía con un adaptador PCIe-USB y observando LEDs y calentamiento del hardware

Experimento con la interfaz PCIe

  • Se probó la FPGA (compatible con Gen3.0 y x8) usando la interfaz externa PCIe Gen2.0 x1 de una Raspberry Pi 5, esperando reconocimiento correcto por retrocompatibilidad
  • En los logs dmesg de Linux, la placa fue detectada como un PCIe Bridge y como endpoint (tipo Ethernet); se asignó un vendor/device id poco común para evitar conflictos con el sistema operativo
  • Con el comando lspci -vvv se revisó el estado completo del dispositivo PCIe: aunque la placa indica soporte para Gen3.0 x8, al conectarla a la Pi el ancho de banda/la velocidad bajan a Gen2.0 x1 (por la limitación del Bridge y de la conexión física real)
  • Con esto se confirmó que la interfaz PCIe de la placa FPGA funciona correctamente

Interfaz JTAG

  • Las FPGA de Xilinx pueden actualizar/cargar por JTAG el CMOS Configuration Latch (CCL) interno usando un esquema basado en SRAM
  • La interfaz JTAG de la placa física está compuesta por las 4 señales estándar (TCK/TMS/TDI/TDO) y alimentación/tierra; el reset puede implementarse mediante la FSM de Xilinx
  • La disposición real de pines difiere del estándar, por lo que se requiere cableado aparte

Uso de Segger JLink

  • Como no se disponía de un programador JTAG oficial de AMD, se usó un Segger JLink junto con OpenOCD
  • JTAG puede montarse solo con 4 GPIO, así que resulta adecuado para experimentos improvisados
  • Se incluye un diagrama de cableado entre el JLink y la placa FPGA; considerando jumpers de protoboard y el retardo de señales por la longitud, la velocidad de TCK (reloj) se limitó a 1~10MHz

Entorno OpenOCD

  • OpenOCD es un depurador on-chip de código abierto compatible con diversas sondas y placas
  • Su soporte para el formato SVF estándar (integrable con Vivado) y la disponibilidad del circuito como código abierto facilitan analizar o parchear problemas directamente
  • Se compiló y utilizó una versión reciente de OpenOCD (0.12.0+dev) junto con la biblioteca de JLink

Verificación de la JTAG Scan Chain y comprobación de IDCODE

  • Sin conocer el esquemático de la placa, se usó la función de escaneo automático de OpenOCD para explorar los dispositivos y el IDCODE dentro de la cadena JTAG
  • Se confirmó que esta placa coincide con el IDCODE del Xilinx KU3P (0x04a63093)
  • También fue necesario especificar manualmente la longitud del IR (registro de instrucciones de 6 bits) para una detección correcta
  • Finalmente se pudo establecer la JTAG scan chain de la placa

Monitor del sistema SYSMON

  • En generaciones antiguas de Xilinx se usaba XADC; en la familia UltraScale+ viene integrado SYSMON4 para medición de temperatura y voltaje
  • openOCD no trae soporte base para integración JTAG con SYSMON, así que hubo que agregarlo manualmente
  • Mediante scripts se pudo hackear incluso el envío de comandos SYSMON (DRP) y la lectura en tiempo real de temperatura/voltaje a través del registro de estado

A través de este proceso, se documenta la experiencia de conseguir a bajo costo una antigua placa aceleradora FPGA de Alibaba Cloud sin soporte oficial y establecer, usando solo herramientas de código abierto, una base para depuración y reutilización (interfaces PCIe/JTAG y monitoreo del sistema)

1 comentarios

 
GN⁺ 2025-10-05
Comentarios de Hacker News
  • Probé la interfaz PCIe de la placa Lattice Certus-Pro NX "Versa" con una Raspberry Pi V y me pareció realmente muy conveniente La Raspberry Pi V es lo suficientemente rápida como para ejecutar software de escritorio moderno (¡hasta Microsoft Teams!) Pude hacer una demo en vivo de un diseño en FPGA y compartir la pantalla del escritorio durante una llamada de conferencia Lo único lamentable es la falta de documentación del SoC de Broadcom Intel, en cambio, proporcionaba toda la documentación de sus chips bajo NDA, así que pude montar un entorno PCIe para FPGA muy bueno en un Xeon Ivy Bridge Guardar los registros de configuración PCI, reconfigurar la FPGA y luego volver a programar los registros hacía que el chip reapareciera en el bus sin reiniciar el servidor ni volver a enumerarlo, lo cual era muy cómodo El truco era establecer temporalmente el bit de root complex durante la reconfiguración para desactivar la detección de errores de PCIe (En ese momento estaba usando una Altera Stratix-IIgx) Parece que también puede haber otros métodos, así que dejo una referencia: enlace de Stack Overflow En general, cuando la documentación está bien hecha, el reporte de errores durante el arranque de PCIe resulta muy útil

    • Me parece un truco realmente genial En mi caso tuve varios problemas al tocar la configuración de PCIe en Linux Al final lo resolvimos usando Partial Reconfiguration, dejando intacta la parte de PCIe y recargando solo el resto Claramente había trade-offs en términos de layout y reserva de espacio
  • Si tienes un adaptador FT2232H (o si no, te recomiendo comprar uno), se puede flashear fácilmente para que sea compatible con Vivado Referencia: guía de programación de dispositivos FTDI para Vivado

    • En nuestra empresa siempre tenemos entre 20 y 30 FT2232H en inventario Son realmente útiles porque soportan varios protocolos como GPIO, I2C, SPI, parallel FIFO, etc. Y la librería de Python pyFTDI es excelente

    • Tengo uno de estos adaptadores que me sobró de otro proyecto, pero nunca he trabajado con FPGA Me pregunto qué significa exactamente que sea compatible con Vivado ¿Se puede configurar una FPGA de AMD con esto, o significa otra cosa?

  • Esto me recordó el caso innovador de Alibaba en bases de datos, donde usaron un clúster de FPGA para encargarse de la compactación de LSM con un motor de almacenamiento personalizado para MySQL Referencia: PDF del paper relacionado Frente a RocksDB, mejoraron mucho el rendimiento y la latencia, y en algunas cargas de trabajo estaban un nivel por encima Incluso ofrecieron esta tecnología como servicio, pero al final la retiraron No sé si todavía la usan internamente, pero me sorprendía que casi nadie aprovechara aceleración por hardware para tareas repetitivas de base de datos

    • AWS también usó su propio acelerador de consultas por hardware en Redshift hace algunos años Referencia: introducción a Redshift AQUA Últimamente AWS parece estar más enfocada en el P&L, así que no sé qué tanto destaque ni cuánto mejore realmente el rendimiento
  • Si te interesan las FPGA PCIe o las tarjetas PCI, también hay bastantes placas Gidel usadas Existen varias series como ProcSpark/ProcStar El software oficial es propietario, y como tienen varias FPGA, para usarlas directamente en Quartus hay que encontrar primero el pinout Yo conseguí una placa con una Stratix IV gigantesca La placa Kintex UltraScale+ es realmente muy codiciable, así que esta publicación me impresionó bastante

    • Conseguí el módulo Verilog de nivel superior y el archivo .xdc de Vivado (mapa de pines, restricciones de timing, etc.) para la Gidel HawkEye 20G-48 No tenía el SDK de Gidel Uno de mis proyectos a largo plazo es conectar dos por 10 GbE para crear un sniffer/intermediario/emulador de dispositivo de TLP de PCIe Los puertos 10 GbE restantes serían para enviar los TLP esnifeados e inyectados a la PC host El PCIe hard IP de la FPGA Aria 10 puede trabajar tanto en modo root como endpoint, así que tendría que hacerse de forma completamente transparente, sin usar módulos IP de Quartus No sé qué tan viable será pasar los TLP de PCIe de un dispositivo rápido por un enlace de 10 gigas, pero fail0verflow incluso logró hacer proxy de TLP con un UART de 115200 baudios enlace de referencia de Gidel HawkEye 20G-48 diapositivas de fail0verflow
  • Si estás en China, el mismo producto se vende en idlefish por 480 yuanes (unos 68 dólares) Es increíblemente barato, así que pienso probarlo yo mismo

  • Todavía no sé si ya encontraron la información de pinout del conector SFP de la parte trasera Si esa parte se documenta y también se confirman las líneas PCI-e, suena divertido intentar hacer con esto un equipo de red óptica personalizado Los transceptores SFP simplemente sacan la señal que se les mete, así que se podrían construir dispositivos personalizados interesantes de señal óptica, ya sea en un backplane PCIe o de forma independiente

    • La información de pinout del conector SFP ya está en la sección de pinout
  • ¿Alguien conoce ejemplos de implementación de redes neuronales u otras arquitecturas conexionistas con FPGAs? Lo más interesante de las FPGA es que incluso universidades o individuos pueden costear un chip "personalizado" En un momento en que la IA está tan concentrada en los LLM, creo que pequeños grupos o personas podrían experimentar con enfoques de inteligencia artificial bottom-up más orientados a animales usando FPGAs

    • En FNAL usan redes neuronales basadas en FPGA para inferencia en resultados experimentales de física de altas energías del LHC/CMS También hay casos de control de sistemas dinámicos en escala de microsegundos Materiales de referencia: HLS4ML PDF de presentación de CERN IRIS-HEP Deploying tinyML on FPGAs Whitepaper PDF de caso de NeurIPS ML4PhysicalSciences

    • Me pregunto si "implementar redes neuronales con FPGAs" significa usarlas como acelerador de hardware para inferencia, o sintetizar toda la red (incluyendo los pesos) directamente en la arquitectura de la FPGA En cualquier caso, una FPGA no puede implementar lógica completamente arbitraria; la estructura consiste en aprovechar bloques limitados a partir del resultado de la síntesis de software No es adecuada para casos como los LLM, donde se necesita mucha memoria de alta capacidad y alto ancho de banda Aunque se puede conectar memoria rápida a una FPGA, hoy en día las GPU son muy superiores para ese uso

    • Vale la pena revisar las differentiable logic gate networks; son interesantes

    • Paper de referencia: arXiv:2404.10076

    • Me pregunto por qué tiene tantos votos negativos Según entiendo, la IA necesita mucha RAM y RAM rápida para el modelo, así que una FPGA no parece adecuada Las FPGA tienen pines para conectar RAM rápida, pero el diseño de la placa y el trazado de capas se vuelven muy complejos Por eso una tarjeta gráfica encaja mucho mejor

  • Viendo todo este furor por la IA, personalmente pienso esto

    • A largo plazo, el hardware de inferencia no parece tener una barrera de entrada muy alta (del lado del entrenamiento no estoy tan seguro)
    • El modelo en sí es un commodity fácilmente reemplazable
    • La velocidad de lanzamiento de productos va más lenta de lo esperado; ya pasaron 3 años desde el lanzamiento de ChatGPT y todavía no encuentro el servicio que quiero (subir documentos y hacer preguntas sobre ellos)
    • Me pregunto exactamente a qué te refieres con poder hacer preguntas después de subir documentos ¿No existen ya servicios con esa función, como NotebookLM o Gems de Gemini? (No conozco bien las alternativas de otros proveedores)
  • Todavía hay mucho inventario en eBay enlace de eBay No parece que el GPIO salga a headers o algo parecido; si alguien tiene ideas de proyectos buenos para usarla, agradecería recomendaciones

    • Es una noticia realmente buena Durante la época del covid este tipo de hardware barato desapareció por completo, así que poder volver a conseguir un Kintex por 200 dólares está genial De niño me interesaban muchísimo este tipo de tarjetas, y con 2x SFP y PCIe me recuerda al proyecto NetFPGA Esta tarjeta es perfecta para ese uso
  • Me llamó la atención que "la placa viene con un estuche de viaje" Me pregunto por qué; ¿en el datacenter sacan esta placa seguido para moverla de un lado a otro? ¿O el vendedor de eBay la puso para protegerla?

    • Lo pusieron para que la llevaras al campo Porque es un Field Programmable Gate Array, o sea, programable en el campo (chiste)