¿Mi FPGA está fuera de los recursos de enrutamiento?

Tengo un diseño de controlador Serial-ATA que funciona en casi cualquier tipo de dispositivo de la serie 7 de Xilinx, excepto en el dispositivo Artix-7, que me da dolores de cabeza...

El diseño puro (SATA 6.0Gb/s, reloj de diseño de 150 MHz) se puede implementar en mi Artix-7 200T. Si agrego núcleos ILA (anteriormente conocidos como ChipScope), no se cumple el tiempo.

¿Qué hice para relajar la situación? - Agregué 2 etapas de canalización en cada núcleo de ILA - Agregué 1 etapa de canalización entre el transceptor GTP y la lógica - Usé retiming, remap y ubicación amplia como estrategia de implementación alternativa

Estas imágenes muestran el flujo de diseño normal. Los núcleos ILA están lejos del controlador SATA (SATAC) y la CPU de 8 bits ( SoFPGA ), pero el controlador todavía tiene rutas fallidas (esa es la única región con rutas fallidas).

ingrese la descripción de la imagen aquí

Parece que el Artix-7 no tiene recursos de enrutamiento en algunas áreas. ¿Cómo puedo obtener un informe que indique tal sospecha?

También probé retiming, remap y estrategias de ubicación más amplias. El resultado es este:

ingrese la descripción de la imagen aquí

El fallo de tiempo es casi el mismo...

PD El diseño usa solo 178 de >300 BlockRAM. Usé Xilinx ISE para usar casi todos los BlockRAM en otros diseños, pero nunca encontré tal comportamiento.

Editar:

Aquí hay un mapa de calor de todos los valores de holgura negativos por Slice (coloreados en rojo)ingrese la descripción de la imagen aquí

En Altera Quartus hay algo llamado regiones LogicLock que le permite restringir una partición o parte de la lógica a una región específica. Supongo que habrá algo similar para Xilinx (aunque no estoy seguro de cómo se llamaría). Si puede hacer eso, debe restringir el ILA a una región fuera de su lógica (para evitar que desplace cosas importantes) y agregar canalización adicional (sin restricciones a la región) para ayudar con el tiempo.
También puede ser un caso de caminos falsos entre el dominio del reloj del ILA y cualquier otro dominio del reloj que provoque caminos falsos que resulten en un esfuerzo adicional por parte del instalador (lo que hace que los caminos reales sean tratados con menos prioridad y, por lo tanto, falle la sincronización)
He tenido problemas similares con SignalTap (nuevamente el equivalente de Altera de ILA), con rutas fallidas causadas porque las rutas sensibles se estaban separando por la lógica de toque que quería estar más cerca de las señales que se estaban tocando. Ocurría principalmente donde había una alta densidad de BRAM porque los SignalTap BRAM estaban forzando a otros BRAM a separarse más. Una vez que SignalTap se limitó a una región menos crítica, los problemas desaparecieron.
@TomCarpenter Las restricciones de ubicación se denominan PBlock :). Por lo que puedo decir, no hay celdas ILA en la región SoFPGA o SATAC, están separadas a través de 3 etapas FF en cada una de las 151 señales de seguimiento. El diseño probado se ejecuta en el mismo dominio de reloj que el ILA (150 MHz). Todas las rutas están restringidas (sin restricciones, sin rutas entre relojes que fallan). Las rutas fallidas mencionadas están todas en el mismo dominio de reloj, ya sea en SATAC o en el propio ILA. Encontré un informe de congestión de enrutamiento, que dice alrededor del 54 % de uso (horizontal y vertical). Por favor vea mi neg. Se agregó un mapa de calor flojo a mi pregunta.
Encontré 2 problemas: al principio, el Artix-7 es entre un 15 y un 50 % más lento que un Kintex-7. Si cambio el grado de velocidad predeterminado de -2 a -3, todo está bien (hay un margen de seguridad de 200 ps en comparación con 670 ps de holgura negativa. ¡Así que el grado de velocidad -3 mejora una ruta de 6,600 ns en casi 0,970 ns! parece como si el apego puro de las señales de rastreo causara un despliegue más alto, lo que causa problemas de temporización.Además, las rutas de rastreo pasan por el dominio del reloj de 100 MHz para la CPU de 8 bits, lo que a su vez causa (una de cada 5 ejecuciones) problemas en ese dominio de reloj, por lo que las líneas largas / rutas causan problemas en otras líneas.

Respuestas (1)

Puede obtener un informe detallado haciendo un análisis de diseño en Xilinx Vivado. Ejecute el siguiente comando en la consola tcl: "report_design_analysis" Le brinda el informe de tiempo, complejidad y congestión del diseño implementado. También puede ejecutar este informe yendo a Herramientas->Informe->Diseño de informe_análisis.

En este informe, puede ver qué áreas están causando congestión debido a la ubicación. Qué Slices se utilizan por completo o cuál es la renta de dichos Slices y/o rutas.

Espero que esto haya sido de ayuda.

Saludos, KWQ

Gracias por este (para mí desconocido) informe. ¿En qué se diferencia de mi última imagen (el mapa de calor de tiempo)?
¿Mi FPGA está fuera de los recursos de enrutamiento?
RespuestasAquíPolítica de privacidad1y, 0v