Simulación FPGA con oscilador de cristal, ¿qué hacer con la entrada XTL?

Instalé un oscilador de cristal (y CCC) en un diseño de FPGA Microchip/Microsemi IGLOO2, y el módulo VHDL del oscilador tiene un pin de entrada XTL .

¿Cuál es la preparación/cableado adecuado para la simulación?

No me queda claro en la documentación qué hacer con ese pin:

"El oscilador de cristal proporciona una señal de reloj de hasta 20 MHz. Físicamente, requiere conexión a un cristal externo; sin embargo, para fines de simulación, el pin XTL proporciona una señal de reloj que se ejecuta en la frecuencia de entrada deseada".

Es un pin de entrada , entonces, ¿cómo proporciona una señal de reloj?

Para ser claros, mi pregunta no es sobre los osciladores de cristal y cómo funcionan, sino sobre el cableado adecuado en un banco de pruebas y en el nivel superior.

Referencia de diciembre: https://coredocs.s3.amazonaws.com/Libero/11_8_sp4/sf2_mlg.pdf

Esperaría que un pin sea la entrada y su salida amortiguada junto a él utilizada para la retroalimentación al cristal.
Tal vez. Pero es una macro, por lo que hay varias conexiones que no son visibles, y creo que la conexión de cristal es transparente en el módulo VHDL, no hay retroalimentación visible ni nada (no es un sim analógico). Ni siquiera entiendo por qué se necesita un pin XTL para la simulación: el módulo osc simplemente puede crear el reloj de referencia, que va directamente al PLL, y de todos modos nunca se usa en el diseño. Entonces podríamos alimentar el banco de pruebas desde el PLL... a menos que me falte algo aquí.
Creo que deberías adjuntar la documentación de esta IP en particular.
@MituRaj ok, hecho. Le agradecería que proporcionara alguna de sus ideas, incluso si no es específica del dispositivo. Tengo la sospecha de que el TB tiene que proporcionar la señal de reloj XTL y simplemente pasa al CCC/PLL, y como el nivel superior de FPGA, el puerto simplemente se deja abierto. Pero no me gusta adivinar... y abrir puertos.
Lo que he entendido es (si XTL es la entrada de la macro), XTL se usa solo para fines de simulación cuando CCC está en modo XTLOC. Emula la frecuencia de cristal que el usuario usa en la placa, y sea cual sea la frecuencia de reloj que alimente allí, obtendrá lo mismo en CLKOUT en la simulación. Para el modo de oscilador RC, es irrelevante ya que la frecuencia se fija a bordo y, por lo tanto, también en la simulación.
@MituRaj con "obtendrás lo mismo en CLKOUT en la simulación" Supongo que te refieres a la misma frecuencia de reloj después de CCC/PLL, ¿no a la misma frecuencia de cristal ?
El simulador no conoce la existencia del cristal ni su frecuencia. Pero hay que simular como si existiera. La entrada XTL es una forma de comunicar su frecuencia al simulador.
@MituRaj en realidad, el bloque OSC está configurado con la frecuencia xtal, de la cual se derivan las restricciones de tiempo; así que conceptualmente podrían haberlo dejado fuera como con el RC OSC. De ahí vino mi confusión. No me gusta la doble definición, dejar entradas abiertas, etc.

Respuestas (1)

Mi comprensión de la descripción es que para la simulación se alimenta XTLcon una señal de su banco de pruebas correspondiente a la frecuencia de su cristal para permitir simular diferentes frecuencias. Luego continúa usándolo CLKOUTen tu diseño como si tuvieras un cristal real.

Para la síntesis, XTLse alimenta desde el nivel superior y se asigna al pin correcto, o se deja desconectado, por lo que las herramientas de síntesis lo asignan automáticamente al hardware del oscilador correcto. No puedo decir cuál.

Sí, esta es la conclusión a la que también estoy llegando. Lo intentaré y leeré cuidadosamente los archivos de registro (todavía no me gustan las entradas desconectadas...).
Confirmado: durante la simulación, la entrada XTL debe recibir una señal de reloj coincidente a través del nivel superior del banco de pruebas y, para la síntesis, la herramienta la vincula a la IO correspondiente para el cristal, según el informe de IO.
Simulación FPGA con oscilador de cristal, ¿qué hacer con la entrada XTL?
RespuestasAquíPolítica de privacidad1y, 0v