Uso de reloj en restricciones de E/S de estilo SDC para FPGA

Pregunta sobre el uso del reloj en las restricciones de retardo de E/S de estilo SDC

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:

  • establecer_retraso_de_entrada

    Uso: set_input_delay [-add_delay] -clock [-clock_fall] [-fall] [-max] [-min] [- reference_pin ] [-rise] [-source_latency_included]

  • establecer_retraso_de_salida

    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.

Restricción de E/S de FPGA

  • 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.


Actualización sobre la pregunta:

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.

Respuestas (1)

ingrese la descripción de la imagen aquí

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 .

Gracias por la respuesta. Estoy de acuerdo contigo en ambos puntos. Puede que me tome un tiempo hundir la declaración "dicho análisis será pesimista para la configuración y optimista para la espera". Con respecto al caso 2, ¿cómo cree que podemos estimar el retraso de inserción de clk_init? Puede haber PLL/MMCM y búferes de reloj dentro de la FPGA que pueden agregar latencia a clk_init. ¿Algo así como una ruta de informe de clk_osc_fpga a clk_init daría una estimación?
Aún no estoy familiarizado con vivado. Debería estar allí en el informe de tiempo como "desviación de la ruta del reloj" del flip-flop que nos preocupa.
Entiendo. ¡Excelente! Y finalmente, ¿puede señalarme algunos buenos recursos sobre STA?
Para mí, para los FPGA, los mejores recursos son xilinx y altera docs :-) tienen guías extensas sobre análisis de tiempo. Además, la sinopsis tiene una guía avanzada de síntesis asic.
Si está buscando una buena teoría extensa, le sugiero "STA para diseños de nanómetros" por la publicación Springer.
¿Podría mirar la actualización de la pregunta? Necesito una aclaración sobre la configuración de la latencia del reloj.
Use el mismo valor de latencia en la latencia establecida del reloj virtual.
Entonces, ¿esto parece correcto? create_clock -period 6.400 -name clk_osc_asic # reloj virtual set_clock_latency –source -1.3000 [get_clocks clk_osc_asic]
Sí. Siempre que clock_osc_asic y clk_int sean síncronos.
Bueno. El analizador de tiempo calcula automáticamente la latencia de la red. Entonces, ¿supongo que no podemos configurar la latencia para clk_int? ¿Y necesitamos configurar el borde del pestillo para el reloj virtual?
No es necesario establecer que cz es el valor utilizado por la herramienta .....
Creo que la latencia es suficiente. Y sí, enganche de borde positivo