Las reglas de oro para el buen diseño FPGA

Introducción

Ser diseñador FPGA requiere una serie de habilidades muy variadas que, desde luego, no puedo resumir en una página. Pero sí hay unas pocas pautas generales especialmente relevantes en esta profesión. He intentado resumirlas en las cinco reglas de oro del diseño FPGA.

Regla n.º 1: Conoce lo que haces

Esta es la primera regla, y la más difícil de cumplir. Significa entender qué implica cada línea de código, cada restricción o cada comando de configuración, y qué consecuencias tiene. Es comprender la teoría subyacente del diseño lógico y cómo responden las herramientas de diseño a lo que les damos.

Es lo contrario de trabajar por prueba y error, algo que los fabricantes de toda herramienta de desarrollo de alta tecnología fomentan de forma implícita, ofreciendo depuradores, simuladores y un montón de utilidades que se venden con un «es fácil».

No es raro desarrollar software escribiendo algo a vuelapluma, hacer una pasa con el depurador, ver qué tal ha salido, corregir algo y repetir. De vez en cuando también se acaban pegando en el software fragmentos de código (code snippets) sacados de ejemplos de Internet. Esta forma de trabajar iterativa puede ser bastante productiva con software sencillo, como una web o aplicaciones para móviles: los errores pequeños no son demasiado graves y se pueden corregir cuando aparecen, o al menos esa es la actitud habitual.

Pero cuanto más sofisticado es el software, antes lleva este método a un callejón sin salida. Y en el diseño FPGA, las prácticas de desarrollo iterativas tienden a pasar factura pronto y con dureza. Las herramientas de diseño FPGA no ayudan ni de lejos a prevenir errores graves, ni a avisar de ellos. Tienes vía libre para estropearlo todo: las herramientas no te pondrán ninguna pega.

Regla n.º 2: Garantiza que funcione

O mejor dicho: que «funcione» no basta.

Una FPGA es un componente electrónico, no un ordenador. Pese a ello, puede ser tan repetible y fiable como un ordenador si se siguen ciertos principios de diseño (ver Regla n.º 1). Si no se siguen, puede muy bien gastarte malas pasadas, con o sin motivo aparente.

Que no se vea ningún error no demuestra que no haya ningún problema; esto vale en cualquier campo. Por ejemplo, si el fontanero termina su trabajo y no hay agua goteando de la tubería, no significa que lo haya hecho bien. La tubería puede empezar a gotear más adelante porque ha subido la presión del agua, o porque alguien la ha tocado sin querer.

Y aun así, todos caemos en la trampa de hacer una prueba rápida, o un poco más a fondo, y dar el trabajo por terminado cuando todo parece correcto. Eso es bastante aceptable para una tubería que gotea, para desarrollar una web sencilla o incluso para software que no forma parte de una aplicación crítica. Pero con las FPGA, sencillamente, no basta.

Desarrollar un diseño para una FPGA significa garantizar que el diseño va a funcionar. Significa obligar a las herramientas de diseño a generar un flujo de bits (bitstream) a prueba de fallos, utilizando las técnicas que ofrecen precisamente para conseguir ese objetivo.

Consiste en hacerte demostraciones, como las demostraciones matemáticas, de que el diseño lógico es correcto, en lugar de pensar en términos de «si ocurre esto, haz esto otro». La lógica debe funcionar hasta en los casos límite más extraños, no porque se hayan tenido en cuenta esas posibilidades una a una, sino por la misma razón por la que una expresión matemática correcta sigue siendo verdadera pase lo que pase.

Que al final funcione no es motivo de celebración. Es el resultado natural de haber trabajado bien.

Regla n.º 3: Simula con criterio, o no simules

Una de las quejas más habituales entre los novatos del diseño FPGA es: «mi simulación funciona perfectamente, por lo tanto mi diseño está bien, y el problema debe estar en otra parte». Lo cual, por supuesto, es un disparate.

Así que, antes de nada, pongamos las cartas sobre la mesa: si el estilo de código Verilog no sigue unas reglas estrictas, la simulación y el hardware pueden hacer cosas completamente distintas (y lo mismo ocurre con VHDL, por supuesto). Ver Regla n.º 1.

Pero las simulaciones cubren un margen limitado de tiempo y de escenarios, incluso cuando están bien hechas. Con un diseño de tamaño mediano ya se tarda una eternidad en simular lo que ocurre dentro de la FPGA durante, digamos, 100 ms. No solo eso: al ejecutar el diseño de verdad en el hardware, la lógica se ve expuesta a escenarios que el diseñador no imaginó y que, por tanto, no simuló. Así que un diseño que superó la simulación a la perfección puede acabar siendo un completo fiasco en el hardware, simplemente porque la FPGA funciona mucho más tiempo del que cubre la simulación, o porque han ocurrido cosas inesperadas.

Para colmo, los errores son difíciles de encontrar en el hardware, porque allí todo ocurre en paralelo. A diferencia de la depuración de software, rara vez hay una secuencia de eventos que seguir, y mucho menos la opción de ir paso a paso. Hay, por supuesto, herramientas para capturar señales dentro de la FPGA, pero no siempre es fácil saber qué señales conviene capturar y qué condición usar como disparo para recoger esos datos.

Por tanto, proponte utilizar la simulación lo menos posible. Si la usas para ir corrigiendo el diseño una y otra vez hasta «conseguir que funcione», lo más probable es que tengas problemas cuando lo pruebes en el hardware.

Más bien, intenta escribir el diseño FPGA de modo que funcione perfectamente a la primera. Eso exige pensar bien las cosas antes de escribir la primera línea de código, además de saber lo que estás haciendo (Regla n.º 1). La simulación debería limitarse a confirmar que lo has hecho bien o, como mucho, a detectar alguna errata tonta. Llegar a este objetivo es un proceso de aprendizaje y mejora, pero merece la pena. Al final, las simulaciones se convierten en una pérdida de tiempo, porque nunca encuentran nada que corregir.

Eso no solo ahorra tiempo: además, los errores que haya que corregir en el hardware serán menos y más fáciles de localizar.

Soy muy consciente de que la primera lección habitual sobre diseño FPGA es «primero simulamos, luego lo probamos en el hardware», pero eso está bien como primera lección.

Regla n.º 4: No tientes a la suerte

O, lo que es lo mismo: cíñete a un estilo de código bien establecido.

Verilog no es un lenguaje de programación cuando se utiliza para síntesis. La diferencia principal es que si escribes algo sintácticamente correcto en cualquier lenguaje de programación, el compilador (o intérprete) está garantizado que ejecutará exactamente lo que significa la sintaxis; o, en el peor de los casos, informará de un error.

Los sintetizadores (synthesizers), en cambio, generan lógica a partir de un conjunto limitado de elementos lógicos. Por eso es bastante fácil escribir código Verilog que dé lugar a lógica poco fiable, o incluso código imposible de implementar en una FPGA. Para colmo, si no hay manera de implementar el código Verilog como lógica en la FPGA, los sintetizadores suelen producir lógica con un comportamiento distinto. Y muchas veces el sintetizador lo hace sin lanzar ninguna advertencia. Dicho de otra forma: la lógica de la FPGA hace algo distinto de lo esperado (es decir, de lo que se simula), y esto ocurre sin ningún aviso.

Y para rematarlo, los errores en los sintetizadores son mucho más frecuentes que en los compiladores. Un estilo de código creativo puede, desde luego, destapar esos errores.

Todo lo dicho anteriormente es aplicable también a VHDL, por supuesto.

Así que la única manera de evitar problemas de este tipo es adoptar un estilo de código que mucha otra gente utilice. La pregunta que debes tener en mente es: «si el sintetizador se hace un lío con este fragmento de código, ¿cuánta gente más se va a quejar además de mí?» Si la respuesta es «mucha gente», estás en terreno seguro.

Ceñirse a un estilo de código bien establecido tiene otra ventaja: la portabilidad. Te guste o no, hoy trabajas con un sintetizador y mañana te encuentras con una FPGA completamente distinta y con otras herramientas de desarrollo.

Para hacerte una idea de cómo es ese estilo, mira el código Verilog que las herramientas generan para los núcleos de IP que incorporan (IP cores). Hay cierta variedad entre los distintos autores del código, pero algunos patrones de código se repiten más que otros. Esos son los que conviene imitar.

Casi huelga decir que hay que trabajar según el paradigma RTL. No es solo un estilo de código bien establecido: es lo que las herramientas FPGA esperan.

Los libros de texto y tutoriales sobre Verilog pueden inducir a error, porque normalmente pretenden ser exhaustivos. Por eso cubren muchas posibilidades que son sintácticamente correctas, pero que rara vez se usan y que a veces ni siquiera son adecuadas para síntesis.

Regla n.º 5: Los tiempos lo son todo

El diseño lógico no es programación de software. No basta con que el valor correcto aparezca en las señales y registros de Verilog; es igual de importante que aparezca en el sitio adecuado en el momento adecuado. También hay que manejar los relojes correctamente.

Los temas principales son, más o menos, estos:

• Piensa bien cómo y cuándo fluyen los datos por las distintas etapas de una segmentación (pipeline), en particular cuando la segmentación puede detenerse, del todo o en parte. En realidad, esto es aplicable a cualquier flujo de datos.
• Asegúrate de que las restricciones de tiempos (timing constraints) sean correctas. En particular, lee las hojas de datos (datasheets) de los componentes externos y haz las cuentas. Esta página trata sobre la comprobación de los tiempos.
• Presta atención a los relojes: ¿son estables desde el primer momento en que se usan? ¿Tienen una fluctuación de fase (jitter) lo bastante baja para lo que se necesita?
• Cruces entre dominios de reloj (clock domain crossing): ¿hace falta lógica de resincronización? Si es así, ¿garantiza una transmisión a prueba de fallos de la señal de un dominio de reloj (clock domain) a otro? Más sobre esto aquí.

En resumen: a diferencia de los programas de ordenador, en el diseño lógico no solo importa qué va a ocurrir, sino también cuándo ocurre.

Resumen

Nadie ha dicho que el diseño FPGA sea fácil, y ninguna de estas cinco reglas es fácil de seguir. Cada una requiere conocimientos y cierto grado de autodisciplina. Aun así, merece mucho la pena esforzarse por cumplirlas. Hacerlo ahorra mucha frustración, sobre todo en esa última fase del proyecto, cuando se espera que todo funcione sin más.