jueves, 7 de octubre de 2010

Entendiendo (parte de) la Información dada por Timing Analyzer




Supongamos que se tiene un diseño que necesitamos que corra a una frecuencia de unos 100MHz (10 ns periodo). Un ejemplo de constraint para el reloj es el siguiente: 

NET "sys_clk_100" TNM_NET = sys_clk_100;
TIMESPEC TS_sys_clk_100 = PERIOD "sys_clk_100" 10 ns HIGH 50%;

Fijando un periodo de 10 ns para la señal de reloj sys_clk_100. 
Ahora bien, una vez que se ejecuta en el ISE el proceso "Analyze Post-Place & Route Static Timing",  un montón de información con respecto al timing del diseño se detalla en la respectiva ventana de la herramienta. Entender parte de esa información, la que creo que la parte mas importante, es lo que deseo explicar a continuación: 
Timing Analyzer (TA) califica la información en función de los diferentes contraints que se hayan especificado en el diseño. Por ahora estudiaremos la que nos interesa y es la referida al constraint que detallamos arriba. Asi, Taming Analizar detalla la siguiente información referida a ese constraint: 

------------------------------------------------------------
Timing constraint:
  TS_sys_clk_100=PERIOD TIMEGRP "sys_clk_100" 10 ns HIGH 50%;

 1459 items analyzed, 0 timing errors detected. (0 setup errors, 0 hold errors)
 Minimum period is   4.207 ns.
------------------------------------------------------------

Detallando que han sido analizados 1459 diferentes caminos relativos a ese reloj, con 0 errores de timing, pudiendo usarse un reloj de periodo mínimo de 4.124 ns (máxima frecuencia). 

Debajo de esa información TA empieza a detallar los caminos referidos a ese reloj, listando el de mayor retardo primero. Se detalla a continuación como se interpreta la información que presenta TA, en este caso para un camino específico. 

------------------------------------------------------------------
Slack:                  5.793ns(requirement-(data path - clock path skew + uncertainty))

  Source:               baud_gen/count_x16_13 (FF)
  Destination:          baud_gen/count_x16_4 (FF)
  Requirement:          10.000ns
  Data Path Delay:      4.207ns (Levels of Logic = 3)
  Clock Path Skew:      0.000ns
  Source Clock:         sys_clk_100_IBUFG rising at 0.000ns
  Destination Clock:    sys_clk_100_IBUFG rising at 10.000ns
  Clock Uncertainty:    0.000ns
-----------------------------------------------------------------

La información más importante se refiere a si el camino ha cumplido con el requerimiento de tiempo. Esta información aparece en la primer línea y es definida como Slack. Si el Slack es positivo, significa que la ruta detallada cumple el requerimiento de tiempo por el número especificado como Slack. Si el Slack es negativo, entonces esa ruta viola el tiempo requerido por el número specificado en el Slack. Al lado del número de Slack se detalla la ecuación usada para calcular el Slack (mas abajo se explican los valores de la misma).
La próxima línea en el reporte es Source. Este es el punto de comienzo del camino analizado, normalmente un componente, en este caso es un flip-flop (FF), pero puede ser otro componente como RAM, PAD, LATCH, etc.
Sigue la línea de Destination, que es el punto final del camino analizado, y corresponde en este caso a un flip-flop (FF).
La siguiente línea se refiere a Requierement. Este es un número calculado con el constraint del periodo del reloj y el tiempo de los flancos del reloj. El reloj de destino y el fuente en este caso son los mismos, por lo que el Requirement es igual el periodo del reloj fijado en el constraint respectivo. Si el reloj de destino o el reloj fuente usaran el flanco de bajada del reloj, el valor de Requierement hubiera sido 5 ns, o sea la mitad del período fijado por el constraint.
EL Data Path Delay es el retardo del camino del dato desde la fuente hasta el destino. Normalmente este valor es la suma del retardo de ruteo más el retardo de la lógica. El retardo de la lógica se mide en niveles de lógica que normalmente es implementada en LUTs, y en este caso se tienen 3 niveles de lógica. Este retardo NO incluye clock-to-out del flip-flop o setup time.
Clock Skew es la diferencia entre el tiempo que la señal de reloj llega al flip-flop fuente y el tiempo en que llega al flip-flop destino. En este caso no hay diferencia, por lo que el valor es 0 ns.
Source ClockDestination Clock reporta el nombre del reloj en la fuente o destino. También incluye si el flanco de reloj es positivo o negativo y el tiempo en que ocurre el flanco.
Clock Uncertainty se refiere a un parámetro de tiempo que se fija como constraint basado en el jitter del reloj y al error de phase que pueda tener el reloj (en breve escribiré al respecto). En este caso no se ha definido ningún valor en el constraint (restricción) por lo que es igual a 0 ns. 
Ahora si podemos volver al cálculo del Slack:



Slack = requirement-(data path - clock path skew + uncertainty)





Slack = 10 - (4.207 + 0 + 0)  = 5.793 ns


A continuación del análisis de tiempo detallado arriba, TA presenta un análisis de los distintos componentes en el camino analizado. Debajo se puede ver el detalle, que luego se analiza. 


-------------------------------------------------------------------------------------------------------------
 Data Path: baud_gen/count_x16_13 to baud_gen/count_x16_4
    Delay type         Delay(ns)  Logical Resource(s)
    ----------------------------  -------------------
    Tcko                  0.374   baud_gen/count_x16_13
    net (fanout=2)        0.417   baud_gen/count_x16<13>
    Tilo                  0.288   baud_gen/count_x16_cmp_eq000062
    net (fanout=1)        0.920   baud_gen/count_x16_cmp_eq000062
    Tilo                  0.313   baud_gen/count_x16_cmp_eq000076
    net (fanout=18)       1.582   baud_gen/count_x16_cmp_eq0000
    Tilo                  0.313   baud_gen/Mcount_count_x16_eqn_41
    net (fanout=1)        0.000   baud_gen/Mcount_count_x16_eqn_4
    Tdyck                 0.000   baud_gen/count_x16_4
    ----------------------------  ---------------------------
    Total                 4.207ns (1.288ns logic, 2.919ns route)
                                  (30.6% logic, 69.4% route)
-------------------------------------------------------------

Data Path especifica el origen (baud_gen/count_x16_13) y el destino (baud_gen/count_x16_4)del camino analizado.
La primer columna es la Location (ubicación) del componente en el FPGA, por defecto esta off , por eso no se puede ver en listado de arriba, pero se puede activar activando Preference al hacer click con el botón derecho en un lugar en blanco de TA. La próxima columna es el Delay Type, si es una ruta, el fanout de la misma es mostrado. Los nombres detallados en esta columna corresponden con los detallados en la respectiva hoja de datos. Dentro de Timing Analyzer doble-click sobre cualquiera de estos nombres y se abrirá una figura que gráfica el retardo.
La columna del Delay detalla los respectivos retardos para cada Delay Type
La próxima columna son los nombres del Logical Resource. Los nombres detallados en esta columna son nombres generados durante el proceso de Map y se asocian a estos componentes. 
Al final del reporte se detalla la suma total del retardo para el camino analizado, 4.207 ns en este caso, seguido por un análisis de cuanto de ese total corresponde a retardo lógico y cuanto a retardo de ruteo. En este caso hay un 70% de retardo de ruteo  y un 30% de retardo lógico, valores bastantes lógicos J y que deberían ser estandars en diseños con FPGAs. 

Wow! q manera de escribir,.... espero q le sea útil a alguien.... :) 


Hasta pronto ! 

1 comentario: