¿Por qué los proyectos FPGA tardan siempre lo mismo en compilarse?

Question

Con el software, cuando compilamos el proyecto por primera vez podemos tardar un rato, pero después ya no se tarda tanto. Si cambiamos un solo archivo del proyecto, no es necesario compilarlo todo de nuevo.

Esto no parece ser cierto para la compilación de diseños FPGA.

Ahora he utilizado Intel Quartus Prime Standard con MAX 10 y Cyclone IV & V y Microsemi Libero SoC con IGLOO2 y SmartFusion2. Con ambos programas y todas las FPGAs que he mencionado, el proyecto siempre tarda lo mismo en compilar. Quiero saber, ¿por qué? ¿Estoy haciendo algo mal? Debería tardar menos en compilar después de la primera vez ¿no? ¿Cómo debería solucionarse?

Answer 1

Con el software... si cambiamos un solo archivo del proyecto, no hace falta volver a compilarlo todo.

Sólo si su compilación crea archivos intermedios para evitar recompilar archivos no modificados.

FPGAs ... Se debe tomar menos tiempo para compilar después de la primera vez no es así?

En una compilación FPGA, a menos que estés utilizando la compilación incremental (que es un esfuerzo complejo), entonces tendrá que resintetizar todo todo el tiempo.

Recuerde que un diseño FPGA es no software. Estás describiendo un circuito físico. Cualquier cambio en una parte de ese circuito puede tener efectos en cadena en otras partes del circuito, debido a la forma en que optimizan las herramientas de síntesis. Además, las herramientas no "compilan" cada archivo de forma aislada, y en la mayoría de los casos no pueden hacerlo, porque los archivos suelen ser descripciones de pequeñas partes del circuito global.

Cuando el diseño se ajusta en la FPGA, a menos que bloquees ciertas partes del mismo (netlists postajuste y compilación incremental), el ajustador empezará desde cero cada vez para intentar encontrar la forma más óptima de ajustar el diseño. Normalmente, el tiempo de compilación se ve muy afectado por las restricciones de temporización, ya que el ajustador intenta minimizar los retrasos de enrutamiento para cumplir con las frecuencias de reloj requeridas.

Answer 2

Esto se debe al funcionamiento de la cadena de herramientas FPGA. Hay varios pasos principales: síntesis, mapeado, colocación y enrutamiento. La síntesis es la única que se parece a la compilación. La síntesis es también el único paso que es más fácil de paralelizar (cada módulo se puede sintetizar independientemente de los otros módulos) y como resultado suele ser sólo una pequeña parte del tiempo total que se tarda en ejecutar las herramientas. En cierto modo, se puede comparar el mapeado, la colocación y el enrutamiento con el enlace, ya que estas tareas funcionan en el diseño completo. Sin embargo, el enlazado es básicamente una operación trivial que consiste principalmente en leer todo el código objeto del compilador, corregir algunas direcciones y escribir el archivo ejecutable. Cada vez que vuelvas a ejecutar tus herramientas de software, puede que sólo haya que recompilar unos pocos archivos, pero habrá que volver a enlazar todo el archivo de salida. Pero esto es rápido porque el enlazador no está haciendo nada especialmente complicado.

Por otro lado, el mapeo, la colocación y el enrutamiento requieren una gran cantidad de recursos informáticos, no se pueden paralelizar fácilmente y no es fácil realizarlos de forma incremental. El mapeado toma una lista de redes de "alto nivel" de la síntesis (compuertas AND, compuertas OR, muxes, flip-flops, sumadores, etc.) y la convierte en primitivos de dispositivo (LUTs, flip-flops, carry-chains, etc.). A continuación, se decide dónde colocar cada primitiva en el dispositivo y se calcula el encaminamiento de todas las conexiones a través de la red de interconexión. Y todo ello en función de la temporización: las herramientas intentan asignar, colocar y encaminar toda la lógica de forma que se cumplan todas las restricciones de temporización. Es un problema mucho más complejo que convertir un montón de C en un montón de ensamblador.

Hacer esto de forma incremental significa realizar un seguimiento de lo que su cambio en el nivel HDL resulta en el diseño final enrutado. Esto no es trivial y es imposible hacerlo bien. Básicamente, las herramientas tienen que comparar el antiguo netlist sintetizado con el nuevo, propagar los cambios hacia abajo y esperar que las cosas funcionen al final y se puedan cumplir las restricciones de temporización.

Tengo alguna experiencia personal con construcciones incrementales que van mal. Recientemente, tuve que borrar y volver a crear un proyecto Intel FPGA cuando se negó a volver a colocar un registro en particular después de cambiar algunas restricciones de temporización, ya que la construcción incremental pensó que, dado que la lógica que generó ese registro no cambió, el registro no tenía que ser movido. Esto fue después de perder varias horas probando varias combinaciones de directivas oscuras para tratar de conseguir que las herramientas cooperaran antes de darme cuenta de cuál era realmente el problema.

Answer 3

Porque en el software hay una fase de enlace. El enlazador toma todos los archivos objeto (resultantes de la compilación de cada uno de los archivos fuente), y sólo altera las llamadas a las funciones para que todo funcione conjuntamente. El enlazador tiene un trabajo bastante sencillo, y no tiene que pasar por el proceso de generar código a partir de la fuente, y optimizarlo todo (lo que consume muchos recursos). Porque eso ya lo ha hecho el compilador, independientemente, para cada archivo fuente.

Por lo tanto, si cambias un archivo fuente, sólo tienes que recompilar este archivo fuente específico y rehacer toda la vinculación, pero la compilación de los otros archivos fuente no es necesaria.

Para la síntesis de hardware, no hay fase de enlace. Hay que optimizar todo el diseño en su conjunto. Si no se hiciera así, los diseños serían muy poco óptimos. Es necesario conocer todos los módulos para que el compilador organice eficazmente el diseño en las LUT disponibles y cumpla los requisitos de temporización. ¿Te has dado cuenta de que, a veces, si cambias sólo unas pocas líneas de código en tu HDL, el diseño resultante es completamente diferente? Todo afecta a todo. Si se mueve una LUT, los tiempos pueden cambiar, y hay que compensarlo moviendo otras cosas, a veces en áreas que parecen no tener nada que ver. Así que, aunque tu diseño esté organizado en varios archivos fuente, la herramienta de síntesis tiene que revisarlo todo cada vez.

En software, las unidades de compilación pueden ser mucho más independientes, y es mucho más fácil para la cadena de herramientas evitar recompilar partes que no se han visto afectadas por cambios en el código fuente.

Answer 4

NOTA (no explícita en otras respuestas): Tanto las herramientas de construcción de FPGA como las de software tienen que encajar el producto final en un espacio. Para el software es un lógico y la relación espacial de una subrutina con otra es completamente irrelevante para su interacción. Pero, para una FPGA, es un físico espacio. Y las relaciones espaciales entre los distintos componentes del diseño son muy importantes.

Answer 5

He utilizado la compilación incremental FPGA en el pasado distante sin ninguna partición de diseño, pero IIRC falló cada 1 en 2 o 3 intentos y terminé haciendo una compilación completa de todos modos.

Sin embargo, si tienes un diseño grande y quieres reducir el tiempo total de compilación, hay algunos trucos que puedes probar. No son triviales, ni rápidos de aplicar, así que sólo ganarás a largo plazo. Podrías convertir algunos de tus sub-bloques en IP pre-empaquetados y arreglar la colocación relativa, de forma que el sub-bloque se coloque como un único elemento.

Aparte del elevado coste del trabajo inicial, como ya han señalado otros, esto podría repercutir negativamente en la eficacia general de la colocación, ya que no se puede optimizar todo el diseño.