Altera Cyclone V: problemas de sincronización con el enrutamiento (interconexión)

Estoy diseñando una aplicación con un SoC Altera Cyclone V (5CSXFC6C6U23I7N) y ADC y DAC de interfaz a 250 MS/s. Mientras tanto, la complejidad del diseño ha aumentado un poco y ahora hay violaciones de restricciones de tiempo cerca de la parte de la interfaz DAC. Esta interfaz utiliza el hardware LVDS SERDES para el formato de datos DDR. El reloj de datos es de 250 MHz y, por lo tanto, una velocidad de datos de 500 Mb/s. El FPGA está sincronizado internamente a la frecuencia de muestreo, es decir, 250 MHz, lo que no debería ser un problema con este dispositivo de grado de velocidad I7.

Ahora el problema: hay algunos registros cerca de la interfaz DAC para ordenar correctamente los bits de datos. Pero hay violaciones de tiempo entre dichos registros, aunque no hay absolutamente ninguna lógica entre los registros. Al observar los retrasos de la ruta en TimeQuest, veo que hay un retraso de 3,5 ns introducido por el enrutamiento (interconexión). Junto con los otros retrasos, los 4ns requeridos ya no se alcanzan. Al observar la ruta de datos en el planificador de chips, veo que se enruta aproximadamente desde el centro de la FPGA hasta la sección de E/S. Después de ver esto, pensé que podría simplemente insertar una etapa de registro adicional, de modo que los datos pudieran volver a sincronizarse en algún lugar de la ruta. Pero el instalador simplemente coloca esos registros cerca de la etapa de salida también, haciendo que siempre falle la(s) misma(s) ruta(s).

Sé que la interfaz en sí no es un problema, ya que funcionaba perfectamente bien en ejecuciones de compilación anteriores. La utilización de recursos está por debajo del 5 %, por lo que tampoco hay problema con los registros/ALM faltantes. Establecer el esfuerzo del instalador en "agresivo" o reducir el rango de temperatura objetivo mejora ligeramente las cifras, pero todavía hay una holgura negativa en el rango de 500ps a 1ns.

Por cierto: el diseño como tal funciona incluso con las violaciones cuando el dispositivo funciona aquí a temperatura ambiente. Sin embargo, quiero que funcione de manera confiable, por lo que ignorar las violaciones definitivamente no es una opción.

¿Algunas ideas?

Gracias y saludos,
Philipp

Cuando tiene un nivel de utilización tan bajo, el principal problema es transferir datos de IO pad a IO pad, la solución más fácil es canalizar los datos para ayudar con el tiempo, esto no debería afectar la funcionalidad general de su diseño si lo hace. bien.
@FarhadA Eso es algo que ya probé: "[...] simplemente inserte una etapa de registro adicional, de modo que los datos puedan volver a sincronizarse en algún lugar de la ruta. Pero el instalador simplemente coloca esos registros cerca de la etapa de salida también, siempre haciendo que la(s) misma(s) ruta(s) falle(n). ¿O quisiste decir algo diferente?
¿Puedes compartir tu archivo de restricciones? ¿Agrupa todas las señales de datos en el mismo grupo y usa la restricción set_max_delay para la ruta? Puede encontrar más información al respecto aquí: quartushelp.altera.com/15.0/mergedProjects/tafs/tafs/…
¡Gracias por tus comentarios! Las únicas restricciones relacionadas con estas rutas son deriva_pll_relojes y deriva_reloj_incertidumbre en este momento. ¿Qué tipo de retraso máximo podría establecer para esas líneas de datos? Dado que es solo una interfaz de salida, no tengo ninguna relación requerida entre algunos puertos de entrada y esas líneas de datos. Las salidas reales son impulsadas por los bloques LVDS SERDES como se mencionó, por lo que solo me preocupa el enrutamiento interno de FPGA en este momento.
Una nota más: después de reducir la complejidad del diseño en algún otro lugar, los tiempos se logran (casi). Entonces, tal vez los problemas actuales son solo problemas posteriores que surgen de alguna otra parte del diseño. ¿Existe una buena manera de identificar las rutas críticas incluso cuando se cumplen los plazos?

Respuestas (1)

¿Estás seguro de que hay violaciones reales? ¿Necesita establecer rutas falsas o grupos de relojes separados? Las herramientas de STA solo son inteligentes cuando usted las dice; Si no cree que haya una ruta lógica real/problema después de leer la infracción, modificaría mi SDC para que la herramienta sepa que no se preocupe por eso. Esto también podría eliminar restricciones innecesarias en el sintetizador y el enrutador.

Si se trata de un problema real y todo se debe a un retraso en la interconexión, me pregunto por qué el enrutador no se ubica de manera adecuada. Puede intentar agregar restricciones regionales o investigar por qué el enrutador cree que está bien colocarlos tan separados, tal vez falte alguna otra restricción.

Las violaciones son irreales en la medida en que el diseño funciona a pesar de ellas. Sin embargo, al mirar las rutas con las violaciones, estas son rutas FF a FF bastante reales que definitivamente causarán problemas si se violan los tiempos. Todo lo que puedo pensar en este momento es que el instalador tiene problemas con algunos requisitos de tiempo de espera e intenta atacar a aquellos con retraso de interconexión.
@PhilippBurch El tiempo de espera no debería ser el problema dentro del mismo dominio de reloj. Por ejemplo, la ruta de registro de desplazamiento dedicada entre dos flip-flops adyacentes tiene un retardo muy corto y funciona sin problemas. ¿El reloj está distribuido a través de una red de reloj global?
@MartinZabel El tiempo de espera puede ser un problema en una ruta de registro de desplazamiento si el reloj tiene más retraso que los datos por algún motivo. No he restringido manualmente la red del reloj, pero Quartus me dice que identificó la señal como un reloj y la "promocionó". Entonces debería ser una red global o regional.
Altera Cyclone V: problemas de sincronización con el enrutamiento (interconexión)
RespuestasAquíPolítica de privacidad1y, 0v