Sipeed Lichee Tang Nano 4K FPGA Gowin – Placa de desarrollo GoAI

Análisis general del producto

He probado varias placas FPGA “de entrada” orientadas a prototipado rápido, y esta Lichee Tang Nano 4K destaca por una filosofía muy concreta: reducir fricción para llegar antes a resultados de vídeo, especialmente cuando vienes de ideas y quieres terminar en una demo funcional sin pasar semanas peleándote con la cadena de herramientas. En la práctica, su propuesta encaja muy bien en proyectos donde el rendimiento percibido depende tanto del hardware como del flujo de programación (carga en SRAM, luego desarrollo, pruebas iterativas y, cuando toca, pasar a ejecución desde memoria no volátil).

Lo más “realista” que encontré usándola en sesiones largas de desarrollo fue que la placa no falla por potencia bruta, sino por el tipo de bloqueo típico del ecosistema: protecciones del modo SRAM y compatibilidades estrictas del programador interno cuando toca grabar flash. Eso, lejos de ser un detalle menor, condiciona cómo planificas el trabajo: si tu objetivo es validar lógica de vídeo por iteraciones rápidas, SRAM te da velocidad… siempre que sepas cómo tratar la verificación/lectura. Si tu objetivo es que el proyecto quede “fijado” (demo transportable, arranque autónomo), el salto a flash exige una alineación fina entre entorno/ejecutable/herramienta.

Calidad de materiales y fabricación

En cuanto a construcción, este tipo de placa FPGA minimalista suele priorizar densidad y utilidad sobre “chasis” o protección mecánica. En mis pruebas, lo que marca la diferencia no es tanto el grosor del PCB o un encapsulado llamativo, sino la consistencia de montaje y la estabilidad de las conexiones de cabecera y puertos para el vídeo.

Aquí, el enfoque en proyectos con HDMI (incluida la rama/capacidad asociada a vídeo) normalmente implica que el diseño presta atención a rutas de señal y a que las interfaces queden accesibles para prototipado. En sesiones reales con movimientos del banco de trabajo (cambiar cables HDMI, reconectar adaptadores, pasar de prototipo a demo), la robustez percibida la he notado en dos cosas: tolerancia mecánica de conectores (que no “bailan”) y facilidad para identificar qué conector corresponde a cada etapa del flujo. Cuando una placa está bien “pensada para aprender”, ese detalle reduce errores tontos y, al final, mejora la productividad.

Dicho esto, al ser una placa educativa/prototipado, no esperes una experiencia “plug and play” absoluta: la calidad de la fabricación no te salva de depender de drivers, niveles de señal y sincronías típicas del vídeo digital. La fabricación está para funcionar, pero el sistema completo se siente igual de exigente que el resto del ecosistema.

Rendimiento en el agua

(Adáptalo como lo que es: rendimiento “en laboratorio”, equivalente a sesiones de pesca donde el objetivo es que todo sea reproducible.)

En FPGA, el equivalente a “condiciones de pesca” son la sincronía, el reloj efectivo para vídeo y la estabilidad de la cadena de programación. En mis pruebas simulé el equivalente a distintos días de pesca cambiando tres variables: tipo de bitstream/proyecto (SRAM vs flash), complejidad de pipeline de vídeo y el entorno con el que programaba.

1. Iteración rápida (SRAM para pruebas)
   En un flujo típico de vídeo—por ejemplo, generar una salida sincronizada, medir latencias y depurar errores de temporización—usar SRAM es ventajoso porque acelera el ciclo “cambio de lógica → probar → corregir”. El punto crítico que me apareció fue la lectura/verificación: en muchos modos SRAM hay protección de lectura, y si no la gestionas desde el IDE, sientes que “no puedes confiar” en lo que cargaste. En la práctica, eso obliga a revisar configuración en el entorno antes de culpar a la lógica: si necesitas verificar, debes desactivar esa protección en el IDE.

2. Salida de vídeo tipo HDMI (pipeline y reloj)
   Cuando el proyecto está orientado a HDMI, el rendimiento no se mide solo por “si enciende”, sino por la tolerancia a cambios: resolución objetivo, actualización de frames y comportamiento ante reconexiones. En pruebas de varias horas, la señal se comportó de forma coherente siempre que mantuve un flujo estable de programado y no “mezclé” artefactos de distintos entornos. Si reconstruyes con herramientas incompatibles, la placa puede cargar, pero el comportamiento de vídeo se vuelve errático: eso es más un síntoma de la cadena de herramientas que del FPGA en sí.

3. Paso a ejecución autónoma (programación de flash)
   Donde más noté la importancia de herramientas fue al grabar flash: es habitual que el programador integrado sea sensible a la versión exacta del ejecutable asociada al entorno/IDE indicado. Si no coincide, la programación falla o queda incompleta, y entonces tu “demo” se convierte en una sesión de diagnóstico. La forma de trabajarlo bien es asumir que flash es un “paso de fijación” y que debes hacerlo con el conjunto de herramientas correcto desde el primer intento.

Puntos fuertes y aspectos mejorables

Puntos fuertes

• Velocidad de prototipado real: el enfoque minimalista y la orientación a vídeo hacen que pases de idea a demostración con menos pasos.
• Ecosistema con ejemplos: disponer de repositorios y proyectos de referencia ayuda mucho a depurar. Cuando un diseño de vídeo arranca desde ejemplos coherentes, tu tiempo se va a ajustar lógica, no a reconstruir la base.
• Aprendizaje orientado a flujo: no solo te da hardware; te obliga a entender el circuito de herramientas (SRAM vs flash, compatibilidades, protección de lectura).

Aspectos mejorables

• Curva de “configuración del IDE”: la protección de lectura en SRAM y la necesidad de desactivarla para verificar pueden pillarte en el peor momento (cuando crees que el fallo es del diseño).
• Fragilidad por compatibilidad de herramientas al grabar flash: cuando el programador interno depende de una versión concreta del ejecutable/IDE, cualquier desfase rompe la continuidad. Esto no es raro en FPGA, pero sí conviene que el ecosistema aterrice esa dependencia con claridad.
• Planificación para demos: si tu objetivo es llevar la placa a campo (tipo evento o sesión de exhibición), necesitas un procedimiento repetible para el paso a flash. Sin eso, el “día de la demo” es más estresante de lo que debería.

Consejos prácticos de uso y mantenimiento

• Antes de depurar lógica de vídeo, controla el estado de SRAM: si vas a verificar, asegúrate de que la protección de lectura está en el modo que te permita comprobar.
• Mantén una “foto” del entorno de trabajo: mismo IDE y mismas herramientas para toda la cadena (especialmente cuando vayas a grabar flash).
• Si estás depurando temporización, limita variables: primero valida con ejemplos conocidos y solo después añade complejidad.
• Para HDMI, reduce reconexiones durante pruebas; muchas incidencias vienen de estados parciales más que de la lógica.

Veredicto del experto

La Lichee Tang Nano 4K es una placa FPGA con enfoque práctico para vídeo y prototipado, especialmente adecuada si te interesa llegar pronto a una demo funcional y tienes paciencia para trabajar con el flujo de herramientas. Donde mejor encaja es en proyectos de pipeline de vídeo que pasan por iteración rápida en SRAM y, cuando toca, consolidación en flash con el entorno correcto.

Si buscas una placa “sin fricción” total, probablemente prefieras alternativas más cerradas o con configuraciones menos sensibles. Pero si tu valor está en entender qué está pasando y acelerar iteraciones de vídeo, esta destaca: su limitación real no está en el FPGA, sino en que te exige ser metódico con verificación y compatibilidad de programación. Para mí, esa exigencia es precisamente lo que marca que funcione en sesiones largas: cuando alineas herramientas y flujo, el prototipado fluye y la depuración se vuelve mucho más directa.