Salida de clk lenta (Spartan-6)

2

Tengo un diseño que se parece a esto:

-controller
--Module1
---SubModule1.1
---SubModule1.2
----SubModule1.2.1
--Module2
---SubModule2.1
---SubModule2.2
---SubModule2.3
---SubModule2.4
--Module3
---SubModule3.1
---SubModule3.2
---SubModule3.3

Entonces obtuve un módulo de nivel superior llamado controlador que hereda 3 módulos. Cada módulo está conectado a un FIFO como un búfer. Por lo tanto, la salida del Módulo1 está conectada a la Entrada de FIFO1 y la salida de FIFO1 está conectada a la entrada del Módulo2 y así sucesivamente.

Ahora aquí está mi problema. Si ejecuto Place & Ruta con Xilinx ISE que me da

----------------------------------------------------------------------------------------------------------
Constraint                                |    Check    | Worst Case |  Best Case | Timing |   Timing   
                                          |             |    Slack   | Achievable | Errors |    Score   
----------------------------------------------------------------------------------------------------------
Autotimespec constraint for clock net clk | SETUP       |         N/A|     9.055ns|     N/A|           0
_IBUF_BUFG                                | HOLD        |     0.411ns|            |       0|           0
----------------------------------------------------------------------------------------------------------
Autotimespec constraint for clock net clk | SETUP       |         N/A|    18.826ns|     N/A|        5804
_IBUF                                     | HOLD        |     0.131ns|            |       0|           0
----------------------------------------------------------------------------------------------------------
Autotimespec constraint for clock net Ins | SETUP       |         N/A|     8.537ns|     N/A|           0
t_part1/Inst_A2Precalc/state[2]_GND_274_o | HOLD        |     1.534ns|            |       0|           0
_Mux_639_o                                |             |            |            |        |            
----------------------------------------------------------------------------------------------------------
Autotimespec constraint for clock net Ins | SETUP       |         N/A|     7.946ns|     N/A|           0
t_part1/Inst_A2Precalc/state[2]_GND_306_o | HOLD        |     1.890ns|            |       0|           0
_Mux_703_o                                |             |            |            |        |            
----------------------------------------------------------------------------------------------------------
Autotimespec constraint for clock net Ins | SETUP       |         N/A|     7.966ns|     N/A|           0
t_part1/Inst_A2Precalc/state[2]_GND_338_o | HOLD        |     2.224ns|            |       0|           0
_Mux_767_o                                |             |            |            |        |            
----------------------------------------------------------------------------------------------------------
Autotimespec constraint for clock net Ins | SETUP       |         N/A|     8.252ns|     N/A|           0
t_part1/Inst_A2Precalc/state[2]_GND_370_o | HOLD        |     1.950ns|            |       0|           0
_Mux_831_o                                |             |            |            |        |            
----------------------------------------------------------------------------------------------------------

Así que clk_IBUF tiene un Best Case Achievable de 18.826ns que es demasiado lento para mi caso. ¿Esto significa que el clk necesita 18.826 para alcanzar todas las partes cronometradas? ¿Y cómo podría mejorar esto? ¿Y puedo de alguna manera buscar qué causa exactamente esto?

    
pregunta nablahero

1 respuesta

1
  

¿Esto significa que el clk necesita 18.826 para llegar a todas las partes cronometradas?

En realidad, significa que el retraso máximo de la ruta combinacional entre dos FF controlados por ese reloj (o de regreso al mismo FF) es de 18.826 ns. Este retardo es la suma del tiempo de salida del reloj del FF de origen, el retardo de la lógica combinacional y el tiempo de configuración del FF de destino.

  

¿Y puedo buscar de alguna manera qué es exactamente lo que causa esto?

Después de P & R, la cadena de herramientas ISE ejecuta el analizador de tiempo estático. En este informe, encontrará la ruta que realmente causa el alto retraso. Si el informe está casi vacío, debe especificar una restricción de reloj con la frecuencia de reloj deseada en un archivo UCF, que debe agregarse a su proyecto. Un ejemplo de restricción de reloj sería:

NET "clk" TNM_NET = "clk_grp";
TIMESPEC "TS_clk_grp" = PERIOD "clk_grp" 100 MHz HIGH 50%
  

¿Y cómo podría mejorar esto?

Como ya ha almacenado en búfer la ruta de datos usando FIFO, observe la ruta de control.

Un problema común con una cadena de FIFO es que el último FIFO puede detener toda la tubería cuando está lleno. Lo mismo se aplica a la primera, cuando está vacía. Si las señales de control FIFO no están almacenadas en el búfer por los FF, esto generalmente conduce a una ruta de señal larga que pasa por todos los FIFO intermedios. Por lo tanto, muchas etapas de LUT y retardo de enrutamiento causan una ruta crítica larga.

    
respondido por el Martin Zabel

Lea otras preguntas en las etiquetas