El largo retraso se debe probablemente a la estructura interna de un FPGA. Es un dispositivo bastante complejo.
Dentro del FPGA, tienes una lógica que "hace algo". Digamos que algo cambia una salida de 0 a 1. Primero, esa salida tiene que propagarse a través de la matriz de conexión del FPGA. Dependiendo de dónde colocó el mapa / lugar / ruta su lógica, ¡esto podría muy bien estar en todo el FPGA! Especialmente dado el reloj de 24 MHz y es probable que no haya proporcionado ninguna otra restricción de tiempo, la cadena de herramientas hará lo que a un humano normal le parecería tonto durante el mapa / lugar. Incluso podría usar algunos CLB para ayudar a propagar la señal, dependiendo de las elecciones realizadas por la cadena de herramientas, pero eso generalmente ocurre solo en diseños grandes cuando el enrutador comienza a quedarse sin recursos.
Una vez que llega a la IOB, todavía tiene que filtrarse a través de todo tipo de otros circuitos antes de que salga a la plataforma. Una vez fuera de la almohadilla, por cada 6 "de traza, agregará aproximadamente 1 n al retardo de propagación. Luego tendrá otro viaje dentro del otro FPGA, nuevamente viajando a través de la IOB y la matriz de conexión. Cualquier registro también potencialmente agregará retardo porque el La señal tendrá que esperar un borde del reloj.
EDITAR:
La capacitancia del cable o-scope no es un factor en el retraso de la propagación (no cambia la permitividad de las trazas, etc.). Lo que afectará es el tiempo de subida de la señal. Puedes medir esto con tu alcance. Si cree que el tiempo de subida es demasiado lento, también puede establecer atributos en la IOB en el archivo de restricciones, lo que aumentará la velocidad de giro y la potencia de la unidad, a expensas de la integridad de la señal. Tenga en cuenta que incluso a 24 MHz, la integridad de la señal puede ser un problema porque es el tiempo de subida de una señal y no la frecuencia lo que determina su contenido espectral. La fuerza de la unidad no es tan difícil para la integridad de la señal, pero si comienza a cambiar una gran cantidad de IOB de alta fuerza de la unidad al mismo tiempo (por ejemplo, un bus de dirección que va de todos los 1 a los 0), puede provocar un rebote a tierra. / p>
Veo en los comentarios que tienes problemas para comunicarte entre los FPGA. Debería considerar utilizar algún tipo de protocolo de enlace para que FPGA2 sepa cuándo FPGA1 está enviando datos. Si los FPGA tienen diferentes relojes, entonces también estás cruzando dominios de reloj, y eso causará problemas porque las señales son asíncronas entre sí, lo que significa que algunas de tus flip flops serán metaestables.
Considere dos señales, Req (Request) y Ack (Acknowledge). Si FPGA1 es el "maestro", pídale que coloque los datos en el bus y aumente la señal de Req. Luego, FPGA2 verá que Req es alto, muestreará los datos y luego aumentará la señal de Ack. FPGA1 verá la señal de Ack y luego disminuirá el Req. Y, lo que es más importante, FPGA1 también debe esperar a que Ack baje antes de que decida enviar más datos.