Arreglando 1 restricción de tiempo fallida en Xilinx

Al final de mi proyecto, tengo una falla de restricción de tiempo de la siguiente manera:

ingrese la descripción de la imagen aquí

clk_ines el reloj del sistema de 100 Mhz en ML507 No sé por qué no cumple con los criterios, tampoco sé cuáles son los criterios, ¿cómo puedo solucionar esto, alguna idea de qué puede causar esta falla? Aunque el proyecto está funcionando. ¿Cómo puedo depurar esto?

Debe consultar el informe de tiempo detallado, que le indicará exactamente qué rutas están fallando.
su período de reloj es de 10 ns, mientras que el retraso máximo de la ruta de datos es de 11,902 ns. O necesita reducir el retraso de la ruta de datos o disminuir la frecuencia del reloj. Hay muchas técnicas para corregir la violación de configuración en ASIC, no estoy seguro de cuáles son aplicables para FPGA. por ejemplo electronics.stackexchange.com/questions/73456/…
@DaveTweed ¿Este informe de tiempo detallado se encuentra al final de la ejecución de Síntesis? ¿Dónde puedo encontrarlo? También sobre esta pregunta electronics.stackexchange.com/questions/116372/… ¿puedes hacer un comentario al menos?
De su pregunta anterior hubo 398 violaciones de la misma restricción de tiempo. ¿Qué hiciste para reducir el número a 262?
@DavidKoontz Nada Abrí el proyecto en la PC de mi casa, la captura de pantalla anterior era de la PC del laboratorio
De la Guía del usuario de Virtex-5 FPGA: "El DCM contiene un bucle de bloqueo de retraso (DLL) para eliminar por completo los retrasos en la distribución del reloj, al desviar los relojes de salida del DCM con respecto al reloj de entrada".
Desea ver el "Informe de tiempo estático posterior a PAR".

Respuestas (1)

en el directorio del proyecto ISE, debería ver un archivo con la extensión .twr. Ese es el informe detallado. Busque la palabra clave ERROR, debe encontrar un tiempo de ruta detallado en el que falla.

Le dirá cuánto del retraso es lógico, cuánto está en el camino. La forma en que lo veo es que los retrasos lógicos necesitan cambios de diseño para mejorar, los retrasos en la ruta podrían mejorarse con una planificación de piso diferente (por ejemplo, veo que usa IBUFG, al usar un pin físico que está más cerca de ese IBUFG puede acortar el retraso de la ruta) .

Tengo la mayoría de las restricciones en el archivo .ucf.

¿Está alimentando este clk en un DCM antes de usarlo?