El diseño no funciona correctamente cuando el retraso neto del reloj es ligeramente superior en spartan3a fpga

Estoy ejecutando mi diseño en spartan3a 3s700afg484 a 50 mhz.

No hay infracciones de tiempo de configuración y espera.

Solo hay una red de reloj global.

Mi informe de reloj para dos carreras es

EJECUCIÓN 1:

Información: [707]: | reloj neto | Recurso |Bloqueado|Fanout|Sesgo neto(ns)|Retraso máximo(ns)|

Información: [707]: | clk_int | BUFGMUX_X2Y11| No | 2056 | 0.236 | 1.213 |

La frecuencia post pnr es de 140 mhz

Compilé mi diseño para algunas optimizaciones de tiempo y obtuve los siguientes resultados.

EJECUTAR 2:

Información: [707]: | reloj neto | Recurso |Bloqueado|Fanout|Sesgo neto(ns)|Retraso máximo(ns)|

Información: [707]: | clk_int | BUFGMUX_X2Y11| No | 2049 | 0.216 | 1.191 |

La frecuencia post pnr es de 112 mhz

Tenga en cuenta que el retraso neto del reloj es menor en RUN 2 y funciona correctamente.

La frecuencia posterior a pnr es más alta en RUN 1 pero los diseños no funcionan correctamente en fpga

La única diferencia entre dos ejecuciones es que la EJECUCIÓN 2 se compila con algunas opciones de tiempo. He simulado la netlist post pnr y funciona bien.

¿Qué puede ser un posible problema? Quiero que mi diseño funcione correctamente para RUN 1, ya que tiene una mayor frecuencia de publicación. Si el retraso neto del reloj es el problema, ¿cómo reducirlo?

Gracias,

El número de 'fanout' es diferente: ¿por qué?
¿Puede ser un poco más específico que "algunas opciones de tiempo"? ¿Se supone que debemos adivinar cuáles eran?
He agregado las opciones -retime y -compile_for_timing en la segunda ejecución. Por lo tanto, los números de fanout son diferentes
¿Qué has vuelto a ejecutar? Todo, desde la síntesis en adelante, o solo el backend (Translate/Map/Par?) ¿Ha intentado tomar la ejecución del sintetizador en funcionamiento y volver a ejecutar Map/Par con diferentes restricciones de tiempo?
Cuál es el problema exactamente"? En la segunda ejecución, obtuvo retrasos netos de reloj más pequeños, lo que significa que, en general, su diseño tendrá mejores tiempos de reloj a salida. ¿No es eso lo que querías? La frecuencia de reloj máxima no es la única medida significativa de rendimiento y, a menudo, no es la más importante. Si la primera ejecución no funcionó en el dispositivo físico, tal vez necesite especificar restricciones de tiempo más estrictas en señales de E/S específicas.
@BrianDrummond, he vuelto a ejecutar desde el principio, es decir, desde la síntesis en adelante, ya que la opción -retime es específica de la síntesis. He simulado la salida de síntesis y funciona bien. Creo que el único problema se debe a un mayor retraso neto del reloj, pero no sé cómo resolverlo.
@DaveTweed, estoy preocupado porque el tamaño de mi diseño aumentará ya que tengo que agregar lógica adicional. Y debido a la mayor demora neta del reloj, mi diseño no funcionará correctamente.
Las herramientas trabajarán tan duro como sea necesario para satisfacer sus limitaciones de tiempo. Solo necesita especificarlos completamente. En este momento, estoy trabajando en una canalización de procesamiento de video de alta definición en un 3S1400A que cumple con todas sus limitaciones de tiempo a 148,5 MHz. Solo debe asegurarse de que su diseño no tenga demasiada lógica entre dos registros. Las herramientas se encargarán de usted o le dirán exactamente dónde no pueden hacerlo.

Respuestas (1)

He estado usando chips y herramientas Xilinx durante mucho tiempo. La primera versión que usé fue Foundation 2.1, hace unos 20 años. Hago MUCHO con FPGA. Así que no hace falta decir que he aprendido algunas cosas en el camino.

Una cosa que he aprendido es que si sus restricciones de tiempo están configuradas correctamente y el analizador de tiempo dice que no tiene un problema de tiempo, entonces no tiene un problema de tiempo. Es curioso cómo es eso: ¡una herramienta que realmente funciona correctamente!

Esto significa que si tiene un problema de sincronización, es probable que sus restricciones no estén configuradas correctamente o que esté haciendo algo mal con respecto a las señales que son asíncronas con su reloj.

Hacer una simulación post PAR (con datos de tiempo) no garantiza un funcionamiento correcto. De hecho, diría que para la mayoría de los diseños con requisitos de tiempo simples, una simulación de tiempo posterior a PAR no hace nada más que lo que se puede lograr con una simulación de comportamiento. En estos días no hago simulaciones de tiempo en absoluto por eso, y nunca me ha quemado esa decisión.

De todos modos, el punto es este: lo más probable es que sus restricciones de tiempo sean incorrectas o que esté haciendo algo mal con las señales asíncronas.

La depuración de este tipo de problema es difícil, pero aquí hay algunos consejos sobre cómo abordarlo:

Sea meticuloso y metódico en su depuración. Concéntrese en lo que sabe sobre el problema y sígalo hasta la fuente. No adopte un enfoque de escopeta y pruebe muchas cosas diferentes dispersas. Concéntrese en el problema conocido (las señales de salida son incorrectas) y siga hasta el error. No se limite a buscar anomalías en los muchos archivos de informes de Xilinx, ya que hay muchas cosas de las que preocuparse y casi ninguna de ellas son realmente problemas. La búsqueda de anomalías simplemente te frustrará.

Gracias David. Meticuloso y metódico fue la clave!!! Aparentemente, no he mencionado la ubicación de una señal de entrada en el archivo .ucf y esto da como resultado una ubicación aleatoria de esa señal por par en el tablero de una ejecución a otra.
El diseño no funciona correctamente cuando el retraso neto del reloj es ligeramente superior en spartan3a fpga
RespuestasAquíPolítica de privacidad1y, 0v