¿La configuración de pines como virtuales afecta el tiempo?

Tengo un submódulo Verilog que estoy probando de forma independiente. Este módulo tiene demasiados pines de nivel superior para caber en mi FPGA, por lo que configuré algunos de los pines como virtuales para que compilaran sin optimizar las señales correspondientes.

Sin embargo, me preocupa que el análisis de tiempo se vea afectado al configurar esos pines como virtuales. Tengo la sensación de que los pines tienen una ruta falsa.

¿La configuración de pines de nivel superior como virtuales en Quartus II afecta el tiempo? Si es así, ¿cómo puedo asegurarme de que el análisis de tiempo es como si el FPGA tuviera suficientes pines para empezar?

Respuestas (3)

Acabo de terminar un proyecto en el sitio del cliente mapeando una IP con más de 2700 IO. En los primeros pasos del proyecto, usamos un contenedor para poner todas las señales en un registro de desplazamiento gigante para asegurarnos de que no estuvieran optimizadas. Pero más tarde usamos las E/S virtuales para obtener la sincronización del diseño correcta y obtener la estimación correcta de los recursos necesarios para el proyecto.

El uso de Virtual IO, en mi experiencia, no afecta el momento de su diseño. Puede "RUTA FALSA" esas señales si lo desea, pero si no lo hace y esas señales están conectadas a uno de sus relojes, entonces obtendrá el análisis de tiempo adecuado de esas señales.

Necesita crear otro módulo dentro de su FPGA que se conecte a todas esas señales y también tenga conexiones a pines reales en su FPGA. Algo así como un registro de desplazamiento largo: piense en una cadena JTAG. Esto obligará a las herramientas de síntesis a tratar todas esas señales como reales y aplicarles las restricciones de tiempo correctas.

Ya no es necesario. En Quartus, puede usar Virtual IO y en Vivado puede establecer la configuración "fuera de contexto" para sintetizar e implementar su IP sin la necesidad de crear un envoltorio o el diseño completo. Esto ayuda a los diseñadores de IP a obtener una buena estimación de los recursos necesarios, así como a optimizar el tiempo de su IP.

Los pines virtuales se colocan como alimentación de la LUT de entrada en un ALM libre, que se puede colocar muy cerca de su lógica de diseño. El tiempo para la LUT asignada se verificará como de costumbre, incluidas las salidas combinatorias que tenga su bloque en esa ruta. Esto es lo que desea al inspeccionar la complejidad del bloque, aunque durante la integración el destino real podría estar mucho más lejos.

Si observa ChipPlanner, encontrará el submódulo densamente empaquetado en el centro utilizando pines IO virtuales. Si enruta a pines físicos, suponiendo que haya suficientes, encontrará que el diseño se estira como una telaraña mientras el instalador intenta cumplir con el tiempo (y lo más probable es que no pueda). Dado que la mayoría de las E/S probablemente vendrán a través de buses de bloques PCS duros dedicados de pads HSSI en núcleos IP, no tiene sentido instalarlo en pines duros.

Actualización: lo que le gustaría probar es agregar una partición de diseño para su bloque y configurar una región de bloqueo lógico para esa partición, que es una pequeña subsección de todo el chip. Esto le dará un pequeño cuadrado de área en el que el núcleo tendrá que cumplir con el tiempo dentro, con un número ilimitado de interconexiones que salen en la periferia. Esto le dará un análisis de tiempo en la entrada/salida a un límite estricto, que puede ser más realista que los LUT de pines virtuales arbitrarios/posicionados favorablemente.

Quartus ayuda: def_virtual_pin

¿Está seguro de que los IO virtuales tienen FalsePath asociado?
Revisando mi respuesta.
Solo una nota rápida, no necesita crear un bloque para usar Virtual IO con Quartus, puede dejar que P&R tenga cierta libertad en las primeras etapas del desarrollo de IP en lugar de centrarse en crear un bloque.