La intención de este artículo es aclarar cómo se debe restringir una interfaz FPGA IO. Como preámbulo, las dos restricciones de tiempo que se pueden usar para restringir una interfaz FPGA IO son:
Uso: set_input_delay [-add_delay] -clock [-clock_fall] [-fall] [-max] [-min] [- reference_pin ] [-rise] [-source_latency_included]
Uso: set_output_delay [-add_delay] -clock [-clock_fall] [-fall] [-max] [-min] [- reference_pin ] [-rise] [-source_latency_included]
La restricción set_input_delay asegura que una entrada a la FPGA desde un chip externo cumpla con los requisitos internos de configuración y retención. De manera similar, set_output_delay se asegura de que los datos impulsados desde un FPGA cumplan con los requisitos de configuración y retención del chip externo. Las restricciones usan varios tiempos como [tCO tSU tH] del chip externo, retardo de seguimiento de PCB, sesgo de reloj, etc. para la estimación. Estas cosas son bastante claras para mí, excepto el "uso del reloj" . ¡Aquí comienza la confusión!
Ambas restricciones especifican los valores de retraso con respecto a un reloj. Ahora viene el concepto de un reloj virtual, un reloj que alimenta el chip externo y que no existe dentro de la FPGA. He visto documentaciones de Intel FPGA (anteriormente Altera) que prescriben el uso de un reloj virtual para restringir todas las interfaces IO. ¡Pero no tenía mucho sentido para mí hasta ahora!
Con respecto al cronometraje, hay dos casos que me interesan. Consulte el archivo adjunto para ver los dibujos.
Caso 1 : si tengo una interfaz síncrona de origen como una interfaz SDRAM o QSPI, la FPGA genera internamente el reloj para el chip externo. En la figura clk_ext y los datos se envían desde la FPGA. Entonces, ¿debería la restricción de SDC usar un reloj virtual o un reloj generado de FPGA?
Caso 2 : Hay un sintetizador de reloj externo que alimenta los relojes FPGA y ASIC. Los relojes clk_osc_fpga y clk_osc_asic pueden o no estar relacionados en lo que a nosotros respecta. Pero, de hecho, hay un flujo de datos desde el FPGA -> ASIC. ¡Tenga en cuenta que la generación de datos dentro de FPGA se realiza utilizando clk_int que no se envía! Entonces, ¿es aquí donde deberíamos usar un reloj virtual? ¿Y cómo modelaría el analizador de temporización los sesgos o diferencias de frecuencia en el reloj virtual con respecto al reloj fpga interno?
Agradecería cualquier consejo al respecto. Y gracias por leer una pregunta realmente larga.
En uno de los diseños pude estimar la latencia del clk_int con respecto al clk_osc_fpga . Encontré que estaba alrededor de -1.3ns . Básicamente, esto significa que el reloj virtual o clk_osc_asic se propaga por adelantado con respecto al reloj interno de fpga clk_int . La pregunta es ¿cómo limito esta latencia? ¿Debo usar set_clock_latency en el reloj virtual? ¿O simplemente ajustar la fase del reloj virtual cuando se usa la restricción create_clock? Además, ¿cómo especificar el borde de muestreo del reloj virtual?
Gracias de nuevo por el apoyo.
Considere el caso anterior, donde el bloque se encuentra fuera de la FPGA y la FPGA le proporciona datos sincrónicos a través de un puerto de salida. Aquí, el analizador de tiempo no podrá analizar la ruta Reg A --> a --> b --> Reg B. Porque la frecuencia del reloj. y la herramienta desconoce la latencia en la ruta física fuera de FPGA. Entonces definiremos un retraso de salida en el puerto de salida con respecto a un reloj imaginario clock_in_virtual llamado reloj virtual. El retraso de salida constituirá el retraso de la ruta, el retraso de b y el tiempo de configuración de Reg B (el retraso de a y el retraso de reloj q de Reg A ya son conocidos por la herramienta del analizador de tiempo). Podemos modelar el período de tiempo y la latencia del reloj virtual. La herramienta ahora puede analizar esta ruta en busca de violaciones de configuración en espera. Supongamos que no usamos el reloj virtual y definimos el retardo de salida con respecto al reloj en sí mismo, tal análisis será pesimista para la configuración y optimista para la espera, porque la latencia del reloj de captura se toma como cero. La misma idea también se usa en los puertos de entrada. Espero que esto tenga algún sentido para usted ahora sobre por qué se usan los relojes virtuales.
Caso I:
Aquí el diseño es fuente síncrona. La salida de datos y el reloj cambiarán en el tiempo conocido y la ruta física es irrelevante porque los retrasos en la ruta para las líneas de reloj y de datos serían casi iguales. Esto asegura el mejor momento para la configuración y espera. Por lo tanto, puede restringir el retraso de salida con respecto al reloj generado para restringir la ruta. No se necesita reloj virtual.
Caso II:
Para analizar esto, ambos relojes deben estar sincronizados. Debe definir un reloj virtual que modele las características y la relación entre el reloj ASIC y el reloj FPGA. Entonces, el retardo de salida se restringe con respecto al reloj virtual. La latencia del reloj virtual se define como el retraso de inserción/latencia de red de clk_int .
electro_sm11
mitu raj
electro_sm11
mitu raj
mitu raj
electro_sm11
mitu raj
electro_sm11
mitu raj
electro_sm11
mitu raj
mitu raj