El diseño no funciona correctamente cuando el retardo de la red del reloj es ligeramente mayor en spartan3a fpga

2

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

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

Solo hay una red de reloj global.

El informe de mi reloj para dos ejecuciones es

RUN 1:

Información: [707]: | Reloj de red | Recurso | Bloqueado | Fanout | Inclinación de red (ns) | Retardo máximo (ns) |

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

La frecuencia de publicación de pnr es 140 mhz

He compilado mi diseño para algunas optimizaciones de tiempo y obtuve los siguientes resultados.

RUN 2:

Información: [707]: | Reloj de red | Recurso | Bloqueado | Fanout | Inclinación de red (ns) | Retardo máximo (ns) |

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

La frecuencia de publicación de pnr es 112 mhz

Tenga en cuenta que el retardo de la red del reloj es menor en RUN 2 y funciona correctamente.

La frecuencia de envío de pnr es mayor en RUN 1 pero los diseños no funcionan correctamente en fpga

La única diferencia entre dos ejecuciones es que RUN 2 se compila con algunas opciones de temporización. He simulado la publicación netlist pnr y funciona bien.

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

Gracias,

    
pregunta quartz

1 respuesta

3

He estado usando chips y herramientas Xilinx durante mucho tiempo. La primera versión que utilicé fue Foundation 2.1, hace unos 20 años. Hago mucho con FPGAs. No hace falta decir que he aprendido algunas cosas a lo largo del 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 tiempo, 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 a su reloj.

Realizar una simulación de PAR posterior (con datos de temporización) no garantiza un funcionamiento correcto. De hecho, argumentaría que para la mayoría de los diseños con requisitos de tiempo simples, una simulación de tiempo post 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 debido a eso, y esa decisión nunca me ha quemado.

De todos modos, el punto es el siguiente: 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 tome un enfoque de escopeta y pruebe muchas cosas diferentes dispersas alrededor. Concéntrese en el problema conocido (las señales de salida son incorrectas) y siga eso hasta el error. No se limite a buscar anomalías en los muchos archivos de informes de Xilinx, ya que hay muchas cosas por las que preocuparse y casi ninguna de ellas son realmente problemas. La caza de anomalías simplemente te frustrará.

    
respondido por el user3624

Lea otras preguntas en las etiquetas