Con un diseño HDL, ¿cómo/cuándo sabemos que necesitamos una ruta de varios ciclos? ¿Cómo la implementamos?

Ha 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 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 usar la restricción de ruta de ciclo múltiple?

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 que esto suceda. Si el comportamiento está escrito para permitir 2 o 3 ciclos de reloj para el resultado, entonces es cuando también necesita agregar la restricción de ciclo múltiple. No haces esto último sin hacer también lo primero.

Además de esto, para un diseño HDL en el que es posible que no sepamos exactamente de qué registros estamos hablando, ¿cómo podemos poner una restricción de ruta de ciclo múltiple?

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 tanto en las mejores como en las peores condiciones?

No.

Hasta donde 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 que el instalador, ya que después de la instalación también se sumará el retraso en el enrutamiento. ¿Es esto correcto?

Algo así como. Las herramientas de síntesis trabajarán duro para implementar la lógica de modo que cumpla con las restricciones de tiempo que ya ha establecido, incluidos los retrasos en el enrutamiento. Si no puede, te lo dirá.

Las herramientas avanzadas incluso saben cómo mover la lógica de un lado a otro de un registro para equilibrar los retrasos de propagación, minimizando el período de reloj requerido.

¿Podemos también obligar al instalador a ajustar la lógica de tal manera que los datos tarden 2 ciclos de reloj en llegar al registro de enclavamiento?

En general, no. Pero no hay una necesidad real de hacer esto.

Mi confusión existe porque cuando tenemos un diseño 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, a menos y hasta que hagamos un STA en la netlist posterior a la síntesis.

Los altos niveles de abstracción están bien hasta cierto punto, pero si realmente le importa obtener el máximo rendimiento de su diseño, debe estar dispuesto a trabajar en el código RTL (nivel de transferencia de registro), en el que sabe explícitamente dónde están los registros y qué lógica va entre ellos.

Mi propia experiencia es la de un EE, por lo que siempre escribo mi código sintetizable como RTL, ya que así es como pienso en el diseño del hardware. En mis bancos de pruebas de simulación solo uso código puramente conductual de alto nivel, que nunca está destinado a ser sintetizado.