Esta página es la primera de una serie de páginas sobre temporización.
La recompensa es la tranquilidad
El tema de la temporización, y en concreto las restricciones de temporización (timing constraints), supone un gran desafío para el diseñador de FPGAs. No es solo que la temporización sea difícil de entender. El verdadero reto está en resistir la tentación de ignorar todo este asunto mientras se trabaja en un diseño para FPGA, porque todo funciona correctamente. Es muy fácil caer en la trampa de sentirse satisfecho con el diseño cuando no se ve ningún problema.
No es raro oír a diseñadores de FPGAs decir que son conscientes de que su diseño cojea en cuanto a temporización, pero que, total, la electrónica va como un reloj. Y ciertamente, asegurarse de que la temporización se hace bien puede parecer una pérdida de tiempo en ese momento. A un jefe con ganas de seguir añadiendo prestaciones no le hará mucha gracia perder un par de semanas sin que el proyecto avance visiblemente. De hecho, un examen riguroso de la temporización del diseño puede sacar a la luz problemas difíciles de resolver. Y visto desde fuera, puede parecer que te estás inventando problemas que no existen y que luego encima pierdes un tiempo valiosísimo en resolverlos.
La verdad es que, muchas veces, la estrategia de ignorar la temporización da resultados a corto plazo. Pero con bastante frecuencia, la falta de atención a este tema conduce a los problemas más molestos, y suelen aparecer en los momentos más inoportunos. Por ejemplo, la electrónica puede fallar una vez cada varias horas durante las pruebas de aceptación finales, quizá cuando el sistema se prueba en todo el rango de temperaturas. O incluso peor: empiezan a llegar quejas de clientes varios años después de haber lanzado el producto. Tras un esfuerzo frenético por encontrar la razón de esas quejas, resulta que las FPGAs de esos productos se fabricaron en una remesa distinta. Así que, aunque todas las FPGAs cumplen las especificaciones de la hoja de datos, las diferencias en su silicio hacían que las FPGAs nuevas se comportaran de forma ligeramente distinta.
Las FPGAs se han ganado una mala reputación por incidentes de este tipo. Sin embargo, cuando la temporización se hace correctamente, puedes estar bastante seguro de que estas cosas no ocurren. Las FPGAs son extremadamente fiables cuando el diseño se ha hecho bien.
Por tanto, hazte un favor y dedica tiempo a aprender el tema de la temporización; después, asegúrate de aprovechar siempre este conocimiento al máximo. Haciéndolo te evitarás el miedo constante a que pase algo inesperado con el diseño cada vez que cambies algo. También te ahorrarás la persecución interminable de errores que aparecen y desaparecen. Y, sobre todo, te acostumbrarás a ver la FPGA como un componente fiable y sólido como una roca.
La importancia de las restricciones de temporización
La lógica de una FPGA solo puede funcionar de forma fiable si se cumplen los requisitos de temporización en todos y cada uno de los elementos síncronos del diseño. Para garantizarlo, hay que examinar todas las rutas posibles (paths). Incluso con un diseño lógico sencillo, es imposible hacer todos estos cálculos a mano.
Por tanto, es responsabilidad de las herramientas asegurar que se cumplen todos los requisitos de temporización. Para que esto sea posible, las herramientas tienen que recibir toda la información necesaria para hacer los cálculos. Por ejemplo, necesitan conocer las frecuencias de todos los relojes, así como el comportamiento temporal de los componentes externos. Esta información se les entrega mediante las restricciones de temporización, que normalmente consisten en un archivo de texto con una sintaxis especial.
Si las restricciones de temporización están mal escritas, o no cubren toda la información necesaria, las herramientas no tienen forma de garantizar un funcionamiento fiable del diseño lógico. Las herramientas dependen de la información que reciben en las restricciones de temporización; si esa información es incorrecta o está incompleta, los cálculos de temporización que hacen las herramientas también lo estarán. Unas restricciones de temporización mal escritas son una causa habitual de comportamiento no fiable en la FPGA.
El acuerdo no escrito con las herramientas es este: les contamos todo lo que necesitan saber sobre la temporización, y ellas se encargan de que no haya violaciones de temporización en el diseño.
Pero a veces las herramientas no consiguen evitar las violaciones de temporización. Cuando esto ocurre, las herramientas emiten un mensaje de aviso que así lo indica. Se trata solo de un aviso, no de un error, de modo que las herramientas de FPGA continúan y generan un flujo de bits (bitstream) que puede cargarse en la FPGA. Por eso es importante comprobar siempre que las herramientas confirman que las restricciones de temporización se han cumplido. Normalmente esa confirmación tiene la forma de un mensaje como «All timing constraints are met».
Pero no todo son restricciones de temporización
El acuerdo no escrito entre tú y el software de FPGA es en realidad más extenso: debes seguir varias reglas sobre cómo debe ser el diseño para FPGA, y las herramientas se aseguran de que la FPGA no falle. Pero si incumples las reglas, las herramientas te pasan factura.
Hacer bien la temporización es una parte importante de esas reglas. Además, la temporización no es solo cuestión de escribir restricciones de temporización. Hay tres aspectos distintos a tener en cuenta.
El primer aspecto es el diseño lógico en sí, es decir, el código Verilog (o VHDL). Está, por supuesto, el requisito obvio de que la lógica sea «suficientemente rápida» (o, más exactamente, que el diseño lógico permita que el reloj trabaje a la frecuencia deseada). Además de eso, hay que tener en cuenta varias cosas más:
- Deben seguirse las reglas fundamentales para escribir Verilog (o VHDL) correctamente, en particular el paradigma RTL. De lo contrario, las herramientas no podrán imponer las restricciones de temporización sobre la lógica que genere el sintetizador (synthesizer).
- En los cruces entre dominios de reloj (clock domain crossings) deben usarse técnicas adecuadas (más información aquí).
- Los relojes deben estar organizados para evitar confusiones. En particular, es importante evitar cruces entre dominios de reloj involuntarios.
El segundo aspecto consiste en escribir las restricciones de temporización. A veces esta parte es muy fácil, y otras requiere un trabajo cuidadoso. Un error muy común es copiar restricciones de temporización de otro diseño (en particular, una única restricción de periodo) y pensar que ya está todo hecho.
El tercer aspecto es generar y leer los informes de temporización para asegurarse de que las herramientas han cumplido su cometido y, por tanto, garantizar que el diseño funciona de manera fiable. Esta es la parte más difícil, sobre todo porque requiere entender cómo funciona la FPGA por dentro: los informes de temporización se escriben en términos de los bloques más pequeños de la FPGA. Por eso, sin ese conocimiento de la FPGA, es difícil sacar conclusiones útiles de estos informes.
Lo habitual es leer los informes de temporización para resolver un problema, sobre todo cuando las herramientas no consiguen cumplir los requisitos de las restricciones de temporización. El proceso de resolver un problema de este tipo se denomina cierre de temporización (timing closure). El problema más común es que la frecuencia del reloj sea demasiado alta para el diseño lógico (o, dicho de otro modo, que la lógica sea demasiado lenta para el reloj).
Como ya se ha mencionado, es muy recomendable examinar de vez en cuando la temporización del diseño para FPGA, incluso cuando las restricciones de temporización se cumplen y todo funciona perfectamente. Eso significa, en particular, revisar los informes de temporización, pero también comprobar que las restricciones reflejan con precisión las necesidades de la lógica. La dificultad es que esta revisión no da frutos a corto plazo: requiere tiempo y esfuerzo, y acaba o sin ningún resultado, o con el descubrimiento de un problema. Así que, si la revisión resulta fructífera, en realidad implica más trabajo para resolver un problema que nadie puede ver.
Cómo están organizadas estas páginas sobre temporización
Estas páginas se centran en el segundo y el tercer aspecto del acuerdo no escrito entre tú y las herramientas de FPGA: escribir restricciones de temporización y leer los informes de temporización. Estas habilidades requieren tanto conocimientos teóricos como herramientas prácticas.
Los aspectos prácticos de las restricciones de temporización son relativamente fáciles de aprender. Lo difícil es entender su significado exacto y su influencia sobre el diseño. La siguiente página de esta serie repasa los conceptos teóricos básicos. En las páginas posteriores, la discusión sobre teoría continúa con la ayuda de varios ejemplos de informes de temporización. La clave está en los pequeños detalles del análisis de temporización.
Las dos páginas siguientes a esa repasan la restricción de temporización más importante y útil: la restricción de periodo. Estas dos páginas incluyen una discusión detallada sobre los informes de temporización, debido a su importancia.
Las dos páginas siguientes tratan sobre el cierre de temporización. Quizá sea un poco pronto para abordar este tema, pero sirve para explicar la finalidad de los temas que vienen después: cinco páginas sobre restricciones de temporización (en sintaxis SDC) relacionadas con el tejido lógico. A continuación vienen dos páginas sobre restricciones de temporización de E/S.
La última página de esta serie está dedicada a la inspección de un diseño existente. No contiene nada nuevo; más bien repite los temas ya tratados. Pero esta vez, en forma de lista de cosas que conviene examinar.
Los temas se presentan en un orden que permite leer esta serie de páginas de principio a fin. Pero todos los temas están relacionados entre sí, así que hay muchas referencias cruzadas entre las páginas.
El mejor sitio para continuar desde aquí es la siguiente página. Nunca viene mal echar un vistazo a la teoría de la temporización.