Cómo analizar el informe de tiempo para Xilinx FPGA

Question

Cómo analizar el informe de tiempo para Xilinx FPGA

#1 de Jonathan Drolet (5 votos)
#2 de Dave Tweed (3 votos)

4

Estoy tratando de aprender la programación FPGA, mi proyecto de prueba es una CPU MIPS canalizada de 5 etapas, que funciona.

Hasta ahora he estado optimizando la utilización del área, sin embargo, esto ha provocado una velocidad de reloj muy lenta (~ 50MHz).

He estado mirando el informe de sincronización estática del mapa de publicación generado por el ISE, pero no puedo darle mucho sentido. A continuación, se encuentra la sección de una ruta única (la más lenta), no puedo entender por qué esta ruta sería tan lenta.

Mis preguntas:

1) Si el retardo de tiempo es 80% de enrutamiento (como parece indicar este informe), ¿puedo mejorar esto? Si es así, ¿cómo?

2) ¿Cómo puedo reducir el componente lógico del tiempo?

3) Lo que se entiende por "origen" y "destino", en el siguiente ejemplo, opcode_out[1] es el origen y finished[0] es el destino, sin embargo, en mi diseño, estos nunca se conectan directamente. Uno se establece en el borde negativo de la etapa de decodificación, el otro se establece en el borde positivo de la etapa de ejecución.

4) En algunos lugares en los que he jugado usando asignaciones no bloqueantes, esto no es posible en todas partes. ¿Qué efectos de rendimiento tiene esto? He encontrado informes mixtos sobre esto.

5) Finalmente, ¿cuál es la probabilidad de que mi velocidad de reloj llegue a 200MHz, dado que actualmente está luchando por alcanzar los 50Mhz?

Paths for end point XLXI_30/XLXI_5/XLXI_3/execute_inst/finished_1 (OLOGIC_X2Y2.D1), 131 paths 
 -------------------------------------------------------------------------------- 
 Slack (setup path):     -6.906ns (requirement - (data path - clock path skew + uncertainty)) 
   Source:               XLXI_30/XLXI_5/XLXI_3/decode_inst/opcode_out_2 (FF) 
   Destination:          XLXI_30/XLXI_5/XLXI_3/execute_inst/finished_1 (FF) 
   Requirement:          5.000ns 
   Data Path Delay:      11.871ns (Levels of Logic = 6) 
   Clock Path Skew:      0.000ns 
   Source Clock:         XLXN_200 falling at 5.000ns 
   Destination Clock:    XLXN_200 rising at 10.000ns 
   Clock Uncertainty:    0.035ns 

   Clock Uncertainty:          0.035ns  ((TSJ^2 + TIJ^2)^1/2 + DJ) / 2 + PE 
     Total System Jitter (TSJ):  0.070ns 
     Total Input Jitter (TIJ):   0.000ns 
     Discrete Jitter (DJ):       0.000ns 
     Phase Error (PE):           0.000ns 

   Maximum Data Path at Slow Process Corner: XLXI_30/XLXI_5/XLXI_3/decode_inst/opcode_out_2 to XLXI_30/XLXI_5/XLXI_3/execute_inst/finished_1 
     Location             Delay type         Delay(ns)  Physical Resource 
                                                Logical Resource(s) 
     -------------------------------------------------  ------------------- 
     SLICE_X40Y70.DQ      Tcko                  0.408   XLXI_30/XLXI_5/XLXI_3/decode_inst/opcode_out<2> 
                                                XLXI_30/XLXI_5/XLXI_3/decode_inst/opcode_out_2 
     SLICE_X41Y70.D5      net (fanout=8)     e  0.759   XLXI_30/XLXI_5/XLXI_3/decode_inst/opcode_out<2> 
     SLICE_X41Y70.DMUX    Tilo                  0.313   XLXI_30/XLXI_5/XLXI_3/execute_inst/_n0402<5>1_FRB 
                                                XLXI_30/XLXI_5/XLXI_3/execute_inst/Mmux_func_in[5]_PWR_69_o_mux_83_OUT22_SW0 
     SLICE_X39Y70.B5      net (fanout=1)     e  0.377   N118 
     SLICE_X39Y70.B       Tilo                  0.259   XLXI_30/XLXI_5/XLXI_3/execute_inst/rd_value_out_wire<31> 
                                                XLXI_30/XLXI_5/XLXI_3/execute_inst/Mmux_func_in[5]_PWR_69_o_mux_83_OUT22 
     SLICE_X41Y72.A6      net (fanout=3)     e  0.520   XLXI_30/XLXI_5/XLXI_3/execute_inst/Mmux_func_in[5]_PWR_69_o_mux_83_OUT22 
     SLICE_X41Y72.A       Tilo                  0.259   XLXI_30/XLXI_5/XLXI_3/decode_inst/immediate_out<4> 
                                                XLXI_30/XLXI_5/XLXI_3/execute_inst/GND_74_o_GND_74_o_equal_146_o<5>1 
     SLICE_X41Y72.C5      net (fanout=19)    e  0.547   XLXI_30/XLXI_5/XLXI_3/execute_inst/GND_74_o_GND_74_o_equal_146_o<5>1 
     SLICE_X41Y72.C       Tilo                  0.259   XLXI_30/XLXI_5/XLXI_3/decode_inst/immediate_out<4> 
                                                XLXI_30/XLXI_5/XLXI_3/execute_inst/func_in[5]_PWR_69_o_equal_125_o<5>1 
     SLICE_X31Y70.A3      net (fanout=23)    e  0.934   XLXI_30/XLXI_5/XLXI_3/execute_inst/func_in[5]_PWR_69_o_equal_125_o 
     SLICE_X31Y70.A       Tilo                  0.259   XLXI_30/XLXI_5/XLXI_3/decode_inst/rd_out<3> 
                                                XLXI_30/XLXI_5/XLXI_3/execute_inst/_n0453 
     SLICE_X31Y70.B5      net (fanout=1)     e  0.359   XLXI_30/XLXI_5/XLXI_3/execute_inst/_n0453 
     SLICE_X31Y70.B       Tilo                  0.259   XLXI_30/XLXI_5/XLXI_3/decode_inst/rd_out<3> 
                                                XLXI_30/XLXI_5/XLXI_3/execute_inst/finished_glue_set 
     OLOGIC_X2Y2.D1       net (fanout=2)     e  5.556   XLXI_30/XLXI_5/XLXI_3/execute_inst/finished_glue_set 
     OLOGIC_X2Y2.CLK0     Todck                 0.803   XLXI_30/XLXI_5/XLXI_3/execute_inst/finished_1 
                                                XLXI_30/XLXI_5/XLXI_3/execute_inst/finished_1 
     -------------------------------------------------  --------------------------- 
     Total                                     11.871ns (2.819ns logic, 9.052ns route) 
                                                (23.7% logic, 76.3% route)

fpga timing xilinx timing-analysis

pregunta Zack Newsham

2 respuestas

Lea otras preguntas en las etiquetas fpga timing xilinx timing-analysis

¿Es el voltaje una medida precisa para probar la carga de una batería de NiMH? ¿Cómo funcionan los diodos en una aplicación de banda AM?

score 5 · Answer 1

1) El enrutamiento es siempre el factor dominante que limita el tiempo. Es por eso que un carry-lookahead no es realmente más rápido en FPGA, ya que el sumador más grande requiere más retrasos que superan en parte las ventajas. Tu camino tiene 6 niveles de lógica, que es O.K. Sería muy difícil poner todos los caminos por debajo de 6. Sin embargo, algunas redes tienen un alto número de fanout, lo que produce mayores retrasos. Puedes intentar duplicar algunos registros para cortar el fanout o probar las opciones de Xilinx.

2) Al cambiar la ecuación lógica ... El retardo en un sector solo se ve afectado por la ruta que toma, no por la operación lógica. Por supuesto, el camino que toma es dictado por la operación lógica. Sin embargo, puede ver en el informe de tiempo que toma alrededor de 0.250 a 0.300 ns por porción (más los retrasos de enrutamiento ...).

3) La fuente y el destino son exactamente lo que dicen. Hay un camino entre opcode y terminado. En el borde descendente de clk, el código de operación se vuelve válido y su nuevo valor se propaga en su circuito. La ruta finaliza en el registro finalizado y la propagación debe estabilizarse antes del borde ascendente de clk para cumplir con los tiempos.

4) No tiene influencia si los usas apropiadamente. Debe ser una opción de codificación para hacer que el código sea más fácil de leer y entender, pero los dos pueden describir el mismo circuito. Los problemas surgen cuando las personas los usan sin comprender el impacto.

5) ¿Cuál es tu FPGA? Si es la serie 7, será difícil pero posible, de lo contrario, de ninguna manera. Además, no aumentar el reloj drásticamente. Cuando las restricciones son demasiado altas, Xilinx se asusta y los resultados no son fiables. Un diseño que funciona en 10ns con una holgura de 1ns puede fallar con -2ns en un reloj de 11ns. Hay un punto de ruptura en el que el sintetizador se esfuerza demasiado para cumplir con los tiempos, y falla drásticamente cuando se intenta colocar y enrutar el diseño más grande.

También te sugiero que elimines el reloj DDR. No hay ninguna razón para tener la lógica DDR en un procesador, use un reloj dos veces más rápido. Tener DDR agrega restricciones innecesarias sobre qué porción puede contener qué lógica, y probablemente inflará sus retrasos de enrutamiento. Al usar un solo reloj, la ubicación (con suerte) usará la porción óptima para todos los registros.

score 3 · Answer 2

Esta es solo una respuesta parcial, ampliando algunos de los puntos planteados por Jonathan Drolet.

3) Lo que se entiende por "origen" y "destino", en el siguiente ejemplo, opcode_out[1] es el origen y finished[0] es el destino, sin embargo, en mi diseño, estos nunca se conectan directamente. Uno se establece en el borde negativo de la etapa de decodificación, el otro se establece en el borde positivo de la etapa de ejecución.

Cada señal en un diseño síncrono es generada por un flip-flop. Por lo tanto, la convención es etiquetar cada FF con la señal que genera. El analizador de temporización verifica cada par de FF para los cuales existe una ruta lógica entre ellos. Entonces, en este caso particular, se trata de la ruta desde la salida del FF que genera opcode_out[1] a la entrada del FF que genera finished[0] .

Puede confundirse en diseños complejos, porque a veces la herramienta de síntesis replicará FF o lógica para tratar los problemas de fanout, y esto crea señales con nombres que no coinciden exactamente con los nombres en el código fuente. A medida que profundices en esto, verás lo que quiero decir.

4) En algunos lugares en los que he jugado usando asignaciones no bloqueantes, esto no es posible en todas partes. ¿Qué efectos de rendimiento tiene esto? He encontrado informes mixtos sobre esto.

El tipo de asignación no tiene ningún efecto en el tiempo de la lógica sintetizada, que solo depende de cómo se activan las asignaciones por eventos como los bordes del reloj. Sin embargo, el tipo de asignación puede cambiar la funcionalidad del código, así que asegúrate de hacer lo que quieras en cada caso.

5) Finalmente, ¿cuál es la probabilidad de que mi velocidad de reloj llegue a 200MHz, dado que actualmente está luchando por alcanzar los 50Mhz?

La única forma de obtener una aceleración de 4 × es rearchitect con cuidado su implementación, utilizando muchas más etapas de canalización y haciendo mucho menos lógica por etapa.

En el ejemplo que muestra, tiene seis niveles de lógica en la ruta que se está analizando. Es posible que deba limitarlo a dos o tres niveles de lógica por ruta, pero esto tiene implicaciones importantes sobre cómo funciona el diseño en general. Una vez tuve que implementar un sumador binario largo para que no tuviera más de 3 niveles de lógica por etapa de canalización. Es factible, pero realmente necesitas prestar atención a los detalles.

Cómo analizar el informe de tiempo para Xilinx FPGA

Publicaciones recientes del blog

2 respuestas