Has hecho una serie de preguntas muy generales, por lo que mis respuestas también serán necesariamente muy generales. Si tiene un ejemplo específico que le gustaría discutir, agréguelo a su pregunta.
Con un diseño de HDL, ¿cómo se puede predecir que la lógica combinacional entre dos registros será más que un ciclo de reloj y, por lo tanto, es necesario utilizar la restricción de ruta multi_cycle?
Está implícito en el diseño. Si necesita que el resultado esté disponible en un ciclo de reloj (según lo especificado por el comportamiento), el ciclo de reloj deberá ser tan largo como sea necesario para permitir que esto suceda. Si el comportamiento se escribe para permitir 2 o 3 ciclos de reloj para el resultado, entonces esto también es cuando debe agregar la restricción de varios ciclos. No haces lo último sin hacer lo primero.
Además de esto, para un diseño HDL en el que no sepamos exactamente de qué registros estamos hablando, ¿cómo podemos poner una restricción de ruta de múltiples ciclos?
En este punto, debe abandonar la abstracción de alto nivel y profundizar en los detalles de implementación proporcionados por las herramientas de síntesis. Al principio puede ser complicado descifrar los informes, pero se vuelve más fácil con la experiencia.
¿Es importante que este retraso sea de más de 1 ciclo de reloj en las mejores y las peores condiciones?
No.
Por lo que yo entiendo. Primero sintetizamos nuestro diseño y, si el retraso de propagación de las puertas es lo suficientemente grande entre dos registros, sabemos que necesitamos esta restricción. Esto sucederá antes de que el instalador, ya que después de ajustar el retardo de enrutamiento, también se sumará. ¿Esto es correcto?
Tipo de. Las herramientas de síntesis trabajarán arduamente para implementar la lógica de modo que cumpla con las restricciones de tiempo que ya ha establecido, incluidos los retrasos de enrutamiento. Si no puede, te lo dirá.
Las herramientas avanzadas incluso saben cómo mover la lógica de un lado de un registro a otro para equilibrar los retrasos de propagación, minimizando el período de reloj requerido.
¿Podemos también forzar al instalador a que se ajuste a la lógica de tal manera que tome 2 ciclos de reloj para que los datos alcancen el registro de retención?
En general, no. Pero no hay necesidad real de hacer esto.
Mi confusión existe porque cuando tenemos un diseño de HDL estamos en un nivel más alto de abstracción y no conocemos todos los registros físicos que existen en el diseño, es decir, hasta que hagamos una STA en el post netlist de síntesis.
Los altos niveles de abstracción son una multa a un punto, pero si realmente le interesa obtener el máximo rendimiento de su diseño, debe estar dispuesto a trabajar en el código RTL (nivel de transferencia-registro), en el que saber explícitamente dónde están los registros y qué lógica hay entre ellos.
Mi propio fondo es el de un EE, así que siempre escribo mi código sintetizable como RTL, ya que así es como pienso en el diseño de hardware. Solo uso código de alto nivel y comportamiento puro en mis bancos de pruebas de simulación, que nunca se pretende sintetizar.