Esta página pertenece a una serie de páginas sobre temporización (timing). La página anterior repasó los fundamentos de la teoría que hay detrás de las restricciones de temporización (timing constraints). El siguiente paso es ver cómo se aplica esta teoría.
Visión general
Esta página presenta la restricción de temporización más importante, la que define la frecuencia de un reloj. A continuación se ofrece un ejemplo detallado del análisis de un camino (path) en un informe de temporización.
Los detalles del análisis de tiempos dentro del informe pueden parecer un tema avanzado, pero no es así: el propósito de las restricciones de temporización es controlar el análisis de tiempos que la herramienta hace del diseño y establecer los requisitos exactos que deben cumplirse. Por tanto, para entender las restricciones de temporización es necesario examinar el análisis de tiempos. Y ese análisis de tiempos se muestra en los informes de temporización.
Además, escribir restricciones de temporización no basta en absoluto. Es importante poder verificar que estas restricciones actúan correctamente sobre el diseño. Esa verificación solo es posible si se comprende a fondo el informe de temporización. Sin esa comprensión, es muy fácil confiarse por error en restricciones de temporización que no cumplen su función y después preguntarse por qué el diseño lógico no funciona correctamente.
Todas las herramientas de FPGA generan informes de temporización como archivos de texto, y estos son los informes que se muestran aquí. Las herramientas también tienen una interfaz gráfica para ver exactamente la misma información. Esa interfaz gráfica a veces ayuda y a veces confunde, por lo que trabajar con los informes de texto es un primer paso importante.
La restricción de periodo
La restricción de temporización más útil es la restricción de periodo: informa a las herramientas de la frecuencia de una señal de reloj.
Por ejemplo, supongamos que el diseño lógico consiste únicamente en este módulo Verilog:
module top(
input clk,
input foo,
output reg bar_reg);
reg foo_reg;
reg bar;
always @(posedge clk)
begin
foo_reg <= foo;
bar <= !foo_reg;
bar_reg <= bar;
end
endmodule
En el Verilog se aprecia claramente que @clk se usa como reloj y que esta señal es un puerto externo (es decir, está conectada a un pin físico de la FPGA).
Si la frecuencia de @clk es 250 MHz (4 ns), se necesita una restricción de temporización como la siguiente:
create_clock -period 4 -name clk [get_ports clk]
Este comando significa lo siguiente: «Hay un reloj en el puerto de E/S llamado @clk. El periodo de este reloj es de 4 ns. Si hay otras restricciones de temporización que hagan referencia a este reloj, usarán el nombre "clk" para ese propósito».
Notas:
- El valor del parámetro "period" debe ser el periodo del reloj. No elijas un valor menor por «seguridad adicional» (sobrerrestricción; overconstraining). Nunca hay motivo para hacerlo. Si hacerlo ayuda, existe un problema distinto que hay que resolver.
- Si se usa un reset asíncrono (asynchronous reset), create_clock puede no proteger al flip-flop frente a incumplimientos de sus requisitos de temporización en esa señal de reset. Esto se explica en otra página.
Análisis de tiempos
Veamos ahora el análisis de tiempos de Vivado para el requisito de tiempo de setup (setup time) del camino que comienza en @foo_reg y termina en @bar. En otras palabras, es el camino correspondiente a esta expresión Verilog:
bar <= !foo_reg;
El análisis de tiempos que se muestra aquí consta de tres partes, que aparecen en el informe de temporización en este orden:
- Una cabecera, que contiene el resumen del análisis de tiempos del camino, junto con información adicional.
- Un cálculo del tiempo que transcurre desde un flanco del reloj hasta que aparece un estado lógico estable en la entrada del segundo flip-flop (@bar en este ejemplo).
- Un cálculo que determina cuándo debe ser estable la entrada del segundo flip-flop para cumplir el requisito de temporización.
Estas tres partes se muestran y se describen por separado más abajo. Observa que en el informe de temporización no hay ningún separador visible entre ellas. En particular, no se aprecia a simple vista dónde acaba la segunda parte y dónde empieza la tercera. Corresponde al lector del informe reconocer el comienzo de la tercera parte por su contenido.
Aunque aquí se muestra el informe de temporización de Vivado, Quartus y otras herramientas de FPGA siguen la misma metodología. La información que aparece en los informes de otras herramientas suele presentarse con un formato algo distinto, pero la teoría que hay detrás es la misma. Por eso, repasar este ejemplo resulta útil también para otras herramientas de FPGA.
Nos saltaremos la primera parte del informe de temporización y volveremos a ella después de comentar las dos primeras. Es más fácil explicar el informe en este orden. Pero antes, unas palabras generales.
La estrategia del análisis de tiempos
A diferencia del sencillo análisis estático de tiempos que se mostró en la página anterior, un análisis de tiempos real obliga a tener en cuenta las imperfecciones del reloj. Para ello, el cálculo del retardo comienza en el origen del reloj, por ejemplo en el pin físico de entrada del reloj. Esto difiere del cálculo sencillo del retardo del camino de datos (data path), como el mostrado en la página anterior, que solo considera el retardo del propio camino de datos.
El experimento teórico es ahora el siguiente: pon un cronómetro en marcha junto con un flanco del reloj en el origen del reloj. Deja que el cronómetro siga corriendo mientras ese flanco viaja hasta el primer flip-flop y lo activa. Continúa midiendo el tiempo mientras ese flip-flop actualiza su salida y sigue la señal actualizada hasta su destino. Detén el cronómetro cuando esa señal llegue al segundo flip-flop.
El siguiente paso es comprobar si el resultado es bueno. Para el requisito de tsu, esto significa que la señal llegó con tiempo suficiente respecto al siguiente flanco del reloj.
Pero se trata de un flanco de reloj en el segundo flip-flop. ¿Cuándo llegará?
Para averiguarlo, se pone en marcha el cronómetro otra vez, junto con el siguiente flanco del reloj en el origen del reloj. El cronómetro se detiene cuando ese segundo flanco llega al segundo flip-flop. El punto de partida es el mismo, pero el flanco es más tardío y el destino del flanco es distinto.
Después de este experimento teórico sabemos cuándo llega el flanco del reloj al segundo flip-flop. Para cumplir el requisito de tsu, la entrada de ese flip-flop debe ser estable con la antelación suficiente respecto a ese flanco.
El cronómetro del primer experimento teórico indica cuándo están estables los datos en el segundo flip-flop. El cronómetro del segundo experimento indica cuándo llega el flanco del reloj al mismo flip-flop. Solo queda comparar esos dos números y comprobar si la diferencia es mayor de lo que exige tsu.
Este método permite tener en cuenta las incertidumbres relacionadas con el reloj, ya que admite aplicar el peor caso en ambos experimentos teóricos. Para un cálculo del tiempo de setup, se usa el límite superior de todos los retardos en el primer experimento con el cronómetro. Así, el cálculo muestra el momento más tardío posible en que la señal puede llegar a la entrada del segundo flip-flop. Pero en el segundo experimento con el cronómetro se usa el límite inferior de todos los retardos; el resultado es el momento más temprano posible en que el segundo flanco del reloj puede llegar al segundo flip-flop.
Por tanto, el cálculo se hace para el escenario en que la señal llega lo más tarde posible y el flanco del reloj llega lo antes posible. Si el requisito de tiempo de setup se cumple en estas condiciones, no hay duda de que se cumple siempre.
Para un cálculo del tiempo de hold (hold time) es al revés: se usan los retardos mínimos en el primer experimento y los máximos en el segundo.
El cálculo del camino de origen
Como se ha dicho antes, la primera parte del informe de temporización se mostrará más adelante. Ahora veremos la segunda parte del análisis de tiempos: el cálculo del camino de origen. Consta de dos segmentos:
- El camino del reloj de origen (Source Clock Path) comienza en el flanco de subida del pin de entrada de reloj de la FPGA y termina cuando ese flanco de subida llega a la entrada de reloj de @foo_reg.
- El camino de datos (Data Path) continúa el viaje hasta que la señal en la entrada de datos de @bar se actualiza con el nuevo valor. Este segmento corresponde al sencillo análisis estático de tiempos mostrado en la página anterior.
En conjunto, estos dos segmentos calculan el tiempo desde el flanco de subida en el pin externo de reloj de la FPGA hasta que los datos llegan al segundo flip-flop.
Esta es la parte correspondiente del informe de temporización:
Location Delay type Incr(ns) Path(ns) Netlist Resource(s)
------------------------------------------------------------------- -------------------
(clock clk rise edge) 0.000 0.000 r
AG12 0.000 0.000 r clk (IN)
net (fo=0) 0.000 0.000 clk_IBUF_inst/I
AG12 INBUF (Prop_INBUF_HRIO_PAD_O)
0.738 0.738 r clk_IBUF_inst/INBUF_INST/O
net (fo=1, routed) 0.105 0.843 clk_IBUF_inst/OUT
AG12 IBUFCTRL (Prop_IBUFCTRL_HRIO_I_O)
0.049 0.892 r clk_IBUF_inst/IBUFCTRL_INST/O
net (fo=1, routed) 0.839 1.731 clk_IBUF
BUFGCE_X1Y0 BUFGCE (Prop_BUFCE_BUFGCE_I_O)
0.101 1.832 r clk_IBUF_BUFG_inst/O
X2Y0 (CLOCK_ROOT) net (fo=3, routed) 1.389 3.221 clk_IBUF_BUFG
SLICE_X49Y58 FDRE r foo_reg_reg/C
------------------------------------------------------------------- -------------------
SLICE_X49Y58 FDRE (Prop_EFF2_SLICEL_C_Q)
0.138 3.359 f foo_reg_reg/Q
net (fo=1, routed) 0.241 3.600 foo_reg
SLICE_X49Y58 LUT1 (Prop_D5LUT_SLICEL_I0_O)
0.244 3.844 r bar__0_i_1/O
net (fo=1, routed) 0.046 3.890 p_0_in
SLICE_X49Y58 FDRE r bar_reg__0/D
------------------------------------------------------------------- -------------------
Cada fila de esta parte representa un elemento lógico o un cable. Cuando el "Delay type" es "net", la fila corresponde a un cable. Todos los retardos de este tipo son retardos de enrutado (routing delays), es decir, el tiempo que tarda la señal en propagarse de un elemento lógico a otro.
La columna llamada "Incr" muestra cuánto retardo aporta cada elemento del camino. La columna "Path" muestra el retardo total acumulado hasta ese punto.
La línea horizontal del centro marca el final del camino del reloj de origen y el comienzo del camino de datos. Ahora vamos a examinar con más detalle los retardos de estos dos caminos.
Los siete primeros retardos corresponden al pin de entrada, que es AG12 (esa es la posición física del pin). Según el informe, el pin de entrada y la lógica asociada a ese pin aportan un retardo total de 1,731 ns.
El buffer global de reloj aporta otros 0,101 ns de su entrada a su salida. Le sigue el retardo de enrutado del reloj global, que es un valor relativamente grande: 1,389 ns. Es el tiempo que tarda la señal de reloj en llegar a la entrada de reloj de @foo_reg. Este retardo tan grande se debe a que se utilizan un buffer global de reloj y un árbol de reloj para distribuir la señal. Estos recursos de enrutado están pensados para distribuir un reloj a grandes zonas de la FPGA con el mismo retardo hacia todos los destinos. Por eso hay un retardo grande, incluso cuando el reloj llega solo a unos pocos destinos, como en este ejemplo (el fan-out del reloj es solo 3).
En este punto, el reloj ha llegado por fin a la slice (SLICE_X49Y58 en este ejemplo) que contiene el flip-flop. Así pues, aquí termina el camino del reloj de origen. La línea horizontal del informe indica el comienzo del camino de datos. En el ejemplo de la página anterior, este es el punto donde comienza el sencillo análisis estático de tiempos.
En la columna Netlist Resources, a la derecha, aparece "foo_reg_reg/C" en la fila anterior a la línea horizontal, y "foo_reg_reg/Q" justo después de esa fila. Por tanto, la fila posterior a la línea horizontal es sin duda el retardo de reloj a salida (clock-to-output) del flip-flop de @foo_reg (de C a Q). Este retardo es de 0,138 ns. "FDRE" significa flip-flop con datos, reset y habilitación (Flip-flop with Data, Reset and Enable).
A continuación viene un retardo de enrutado hasta la LUT (0,241 ns), el retardo de propagación (propagation delay) dentro de la LUT (0,244 ns) y el retardo de enrutado hasta el segundo flip-flop (0,046 ns). Los retardos de enrutado son excepcionalmente pequeños, porque todo está empaquetado en una única slice.
En resumen, el flanco del reloj tardó 3,221 ns en viajar desde el pin externo hasta la entrada de reloj del primer flip-flop. Luego tardó 0,669 ns en llegar la señal actualizada a la entrada del segundo flip-flop (3,890 - 3,221 = 0,669 ns). En total, el tiempo desde el flanco de reloj en el pin externo hasta que la señal es estable en el destino final (la entrada de datos del segundo flip-flop) fue de 3,890 ns (como máximo; se trata de un cálculo en el peor caso).
Es hora de preguntarse si fue suficientemente pronto. ¿Se cumple el requisito del tiempo de setup?
El camino del reloj de destino
El propósito de este segundo cálculo es averiguar con qué rapidez puede viajar el flanco del reloj desde el pin externo hasta la entrada de reloj del segundo flip-flop.
Observa que el destino del camino del reloj es el segundo flip-flop. No debe confundirse con el camino del reloj del cálculo anterior, cuyo destino era el primer flip-flop.
Hay otras diferencias notables:
- Solo se calcula el camino del reloj. En otras palabras, en comparación con el cálculo anterior, solo se tiene en cuenta el segmento hasta la línea horizontal.
- El cronómetro teórico se pone en marcha en 4 ns, no en cero. Esto se debe a que el propósito de este cálculo es averiguar si la señal de datos llega con la antelación suficiente para cumplir el requisito de tiempo de setup. Por consiguiente, el cálculo comienza en el segundo flanco del reloj, que, según la restricción de temporización para clk (es decir, el comando create_clock mostrado antes), se produce a los 4 ns.
- Los retardos de cada componente en este segmento son menores. Esto se aprecia fácilmente en este ejemplo concreto, porque ambos flip-flops están en la misma slice, de modo que los caminos del reloj son exactamente iguales en los dos cálculos (algo que normalmente no ocurre). Más sobre esto abajo.
- Las tres últimas filas de este cálculo (clock pessimism, clock uncertainty y Setup_DFF2_SLICEL_C_D) no son componentes lógicos, sino parámetros de temporización.
La tercera parte del análisis de tiempos (el camino del reloj de destino) es la siguiente:
(clock clk rise edge) 4.000 4.000 r
AG12 0.000 4.000 r clk (IN)
net (fo=0) 0.000 4.000 clk_IBUF_inst/I
AG12 INBUF (Prop_INBUF_HRIO_PAD_O)
0.515 4.515 r clk_IBUF_inst/INBUF_INST/O
net (fo=1, routed) 0.066 4.581 clk_IBUF_inst/OUT
AG12 IBUFCTRL (Prop_IBUFCTRL_HRIO_I_O)
0.034 4.615 r clk_IBUF_inst/IBUFCTRL_INST/O
net (fo=1, routed) 0.722 5.337 clk_IBUF
BUFGCE_X1Y0 BUFGCE (Prop_BUFCE_BUFGCE_I_O)
0.091 5.428 r clk_IBUF_BUFG_inst/O
X2Y0 (CLOCK_ROOT) net (fo=3, routed) 1.218 6.646 clk_IBUF_BUFG
SLICE_X49Y58 FDRE r bar_reg__0/C
clock pessimism 0.527 7.173
clock uncertainty -0.035 7.138
SLICE_X49Y58 FDRE (Setup_DFF2_SLICEL_C_D)
0.067 7.205 bar_reg__0
-------------------------------------------------------------------
required time 7.205
arrival time -3.890
-------------------------------------------------------------------
slack 3.315
Las herramientas han colocado @foo_reg y @bar en la misma slice, de modo que en este caso concreto el camino del reloj de este análisis coincide con el del primer análisis. Por eso se ve fácilmente que la secuencia de elementos lógicos es exactamente la misma que en el análisis anterior, hasta la línea horizontal. Tras esa secuencia hay dos parámetros de temporización que ajustan el cálculo: el pesimismo del reloj (clock pessimism) y la incertidumbre del reloj (clock uncertainty). Se comentan por separado al final de esta página.
En la penúltima fila de este cálculo tenemos el momento más temprano en que puede llegar el segundo flanco del reloj: 7,138 ns después del primer flanco. El requisito de tiempo de setup exige que la señal de datos sea estable antes de ese flanco; tsu indica cuánto antes. Así pues, para obtener el momento más tardío en que los datos deben ser estables, se resta tsu del tiempo de llegada del reloj.
En el ejemplo anterior, tsu es negativo y vale -0,067 ns. El resultado final es, por tanto, 7,138 - (-0,067) = 7,205 ns. Dicho de otro modo: los datos deben ser estables en el segundo flip-flop no más tarde de 7,205 ns después del primer flanco del reloj.
En el cálculo anterior, el resultado era que los datos están estables 3,890 ns después de ese flanco, en el peor caso. Así que es suficiente, con margen: la diferencia entre el requisito y lo garantizado es 7,205 - 3,890 = 3,315 ns. En otras palabras, el margen (slack) es de 3,315 ns.
Resumen del análisis de tiempos
Ha llegado el momento de volver a la primera parte del informe de temporización del camino. Esta parte aparece antes de los cálculos mostrados arriba y resume los resultados principales. Además, esta cabecera aclara algunos valores que aparecen en esos cálculos.
Así que ten en cuenta que así es como comienza el análisis de tiempos de un camino:
Slack (MET) : 3.315ns (required time - arrival time)
Source: foo_reg_reg/C
(rising edge-triggered cell FDRE clocked by clk {rise@0.000ns fall@2.000ns period=4.000ns})
Destination: bar_reg__0/D
(rising edge-triggered cell FDRE clocked by clk {rise@0.000ns fall@2.000ns period=4.000ns})
Path Group: clk
Path Type: Setup (Max at Slow Process Corner)
Requirement: 4.000ns (clk rise@4.000ns - clk rise@0.000ns)
Data Path Delay: 0.669ns (logic 0.382ns (57.100%) route 0.287ns (42.900%))
Logic Levels: 1 (LUT1=1)
Clock Path Skew: -0.048ns (DCD - SCD + CPR)
Destination Clock Delay (DCD): 2.646ns = ( 6.646 - 4.000 )
Source Clock Delay (SCD): 3.221ns
Clock Pessimism Removal (CPR): 0.527ns
Clock Uncertainty: 0.035ns ((TSJ^2 + TIJ^2)^1/2 + DJ) / 2 + PE
Total System Jitter (TSJ): 0.071ns
Total Input Jitter (TIJ): 0.000ns
Discrete Jitter (DJ): 0.000ns
Phase Error (PE): 0.000ns
Clock Net Delay (Source): 1.389ns (routing 0.002ns, distribution 1.387ns)
Clock Net Delay (Destination): 1.218ns (routing 0.002ns, distribution 1.216ns)
Esta parte contiene mucha información variada, así que la repasaré punto por punto. Empezando por la primera fila:
Slack (MET) : 3.315ns (required time - arrival time)
Esto indica que la restricción de temporización se ha cumplido (MET) y que ha sobrado margen (slack): 3,315 ns.
Source: foo_reg_reg/C
(rising edge-triggered cell FDRE clocked by clk {rise@0.000ns fall@2.000ns period=4.000ns})
Destination: bar_reg__0/D
(rising edge-triggered cell FDRE clocked by clk {rise@0.000ns fall@2.000ns period=4.000ns})
Estas filas indican qué camino de datos se examina, definido por la posición inicial y final de ese camino (el Source y el Destination, es decir, el origen y el destino). El camino de datos comienza en foo_reg_reg/C, que es la entrada de reloj de @foo_reg, y termina en la entrada de datos bar_reg__0/D.
Otra cosa es que se menciona "clk" y se describe su forma de onda. Observa que "clk" se refiere al nombre que se le dio al reloj con create_clock. En este ejemplo, "clk" es también el nombre de la señal de reloj. Pero si se usa otro nombre en el parámetro "-name" de la restricción de temporización, ese nombre es el que aparece en el informe, sea cual sea el nombre de la señal. Esto es válido para todos los sitios donde se menciona "clk" en este ejemplo de informe.
Path Group: clk
El Path Group es "clk" aquí, lo que indica que la razón por la que se examina este camino es la restricción de temporización con ese mismo nombre.
Path Type: Setup (Max at Slow Process Corner)
El Path Type es Setup. Eso significa que se examina el requisito de tiempo de setup. «Max at Slow Process Corner» significa que se usaron los retardos máximos en el cálculo del camino de datos (el primer cálculo). El significado de "corner" en este contexto se explica más abajo.
Requirement: 4.000ns (clk rise@4.000ns - clk rise@0.000ns)
Recuerda que hay un cronómetro imaginario que se pone en marcha en cada uno de los dos experimentos teóricos descritos antes. El "Requirement" es la diferencia de tiempo entre los instantes en que se pone en marcha ese cronómetro. En este caso es el periodo del reloj que exige la restricción de temporización, es decir, 4 ns.
Data Path Delay: 0.669ns (logic 0.382ns (57.100%) route 0.287ns (42.900%))
El Data Path Delay es la suma de todos los retardos posteriores a la línea horizontal en el primer cálculo (es decir, los retardos del camino de datos).
En esta fila, el retardo se muestra también por separado para lógica y ruta. Así se ve cuánto tiempo se emplea en los elementos lógicos y cuánto en los cables que hay entre ellos. La regla general suele ser que aproximadamente el 60% del retardo corresponda a la lógica y el resto al enrutado. Por tanto, el camino de este ejemplo muestra la situación normal.
Si el retardo del enrutado supone una proporción mucho mayor, podría indicar un problema, sobre todo si el camino no consigue cumplir la restricción de temporización. Hay más información sobre esto en la página siguiente, en la sección dedicada al análisis de thold.
Logic Levels: 1 (LUT1=1)
El camino de datos consiste en una única LUT, por lo que el número de niveles lógicos (logic levels) es 1.
Clock Path Skew: -0.048ns (DCD - SCD + CPR)
Destination Clock Delay (DCD): 2.646ns = ( 6.646 - 4.000 )
Source Clock Delay (SCD): 3.221ns
Clock Pessimism Removal (CPR): 0.527ns
El Clock Path Skew (desviación del reloj; clock skew) es la diferencia entre los instantes en que el mismo flanco del reloj llega a los dos flip-flops. Es un peor caso calculado que incluye el hecho de que se usan los retardos máximos en un camino del reloj y los mínimos en el otro. Véase más abajo la sección "Clock pessimism removal", que explica la aritmética de estas filas.
Clock Uncertainty: 0.035ns ((TSJ^2 + TIJ^2)^1/2 + DJ) / 2 + PE
Total System Jitter (TSJ): 0.071ns
Total Input Jitter (TIJ): 0.000ns
Discrete Jitter (DJ): 0.000ns
Phase Error (PE): 0.000ns
Ver la sección "Clock uncertainty" más abajo. Estas filas muestran cómo se calculó la incertidumbre del reloj. El resultado de este cálculo, 0,035 ns, es optimista hasta el punto de resultar poco realista. Esto ocurrió porque no se especificó ningún jitter en la restricción de temporización, así que las herramientas supusieron que el jitter es cero. Además, el reloj externo se usa directamente (es decir, sin una PLL dentro de la FPGA), por lo que casi no hay fuentes de jitter que considerar.
Aunque es un error no especificar el jitter del reloj externo en la restricción de temporización, así se hace normalmente. Rara vez es fuente de problemas, porque el jitter suele ser pequeño en comparación con otras magnitudes que se tienen en cuenta en el cálculo de tiempos.
Clock Net Delay (Source): 1.389ns (routing 0.002ns, distribution 1.387ns) Clock Net Delay (Destination): 1.218ns (routing 0.002ns, distribution 1.216ns)
Son los retardos de la propia señal de reloj, desde la salida del buffer de reloj hasta la entrada de reloj de cada flip-flop. En este ejemplo, estos números no aportan mucha información.
Análisis de tiempos multi-corner
El retardo de todos los elementos lógicos depende de algunos parámetros desconocidos, como la temperatura y la tensión de alimentación. Además, el término "process" se usa para referirse a las imprecisiones durante la fabricación de la FPGA. Aunque cada FPGA se prueba para garantizar que cumple la hoja de datos, aún existe cierta incertidumbre sobre el comportamiento de cada elemento lógico.
Las herramientas de FPGA realizan el análisis de tiempos de cada camino en unos pocos escenarios extremos, llamados "corners" (esquinas). Por ejemplo, un escenario podría ser la temperatura mínima permitida junto con el proceso más rápido (es decir, cuando la FPGA se ha fabricado con retardos bajos). Un segundo escenario podría ser la temperatura máxima junto con el proceso más rápido. El tercero y el cuarto repiten esto con el proceso más lento.
Así pues, en este ejemplo el análisis de tiempos se realiza para las condiciones extremas de dos parámetros: temperatura y proceso. Esto se llama análisis de tiempos de cuatro esquinas (four-corner timing analysis). Pero es solo una de las muchas formas posibles de realizar un análisis de tiempos multi-corner. Cada herramienta de FPGA realiza el análisis de tiempos de una manera distinta.
Pero independientemente de qué esquinas elija examinar la herramienta, el peor caso se considera siempre el resultado del análisis de tiempos. En otras palabras, la herramienta calcula el margen (slack) para cada esquina y el que cuenta es el margen más bajo.
Las herramientas están programadas para realizar el análisis multi-corner adecuado para cada FPGA, así que no hace falta dominar este tema a fondo. Pero al leer un informe de temporización, es importante comprobar si se refiere a una sola esquina o si es el resumen de todas ellas (es decir, el peor caso). Existe la posibilidad de confusión, en particular con Quartus.
A continuación se tratan la eliminación del pesimismo del reloj (clock pessimism removal) y la incertidumbre del reloj (clock uncertainty). Son temas relativamente avanzados. Si no te interesan los detalles más finos del cálculo de tiempos, puedes saltar sin problema a la página siguiente de esta serie.
Eliminación del pesimismo del reloj
Debido a la coincidencia de que ambos flip-flops están en la misma slice, es posible comparar los cálculos de los retardos del camino del reloj (es decir, el tiempo hasta que el flanco llega a la slice). En el segundo cálculo, ese tiempo es 2,646 ns, porque el cálculo empieza en 4 ns y termina en 6,646 ns, así que 6,646 - 4 = 2,646 ns. En el cálculo anterior, el resultado era 3,221 ns. La diferencia es de 0,575 ns.
La razón de esta diferencia es que en el primer cálculo se usaron los retardos máximos y en el segundo, los mínimos. La diferencia entre los retardos mínimos y los máximos refleja que los retardos no se conocen con exactitud debido a las imprecisiones naturales del proceso de fabricación. Así que si el camino del reloj hacia el primer flip-flop es completamente distinto del camino hacia el segundo, hay que tener en cuenta el peor caso. Ese peor caso consiste en que todos los retardos del primer camino sean los máximos permitidos y todos los del segundo, los mínimos permitidos. Esto se llama pesimismo del reloj (clock pessimism).
Observa que esto no tiene nada que ver con la temperatura ni con las diferencias entre una FPGA física y otra: ambos cálculos se hacen para la misma temperatura y el mismo proceso de fabricación. La diferencia se debe a que cada retardo del segmento tiene una tolerancia que está dentro de la especificación de la FPGA.
Pero ¿por qué el pesimismo del reloj forma parte del cálculo cuando el camino del reloj es idéntico en ambos caminos? La respuesta es que hacerlo es un error. Por eso hay una fila titulada "clock pessimism" en el camino del reloj de destino. Esa fila añade 0,527 ns al retardo para compensar ese error. El título debería ser en realidad "clock pessimism removal" (CPR).
La idea de la eliminación del pesimismo del reloj es eliminar las diferencias innecesarias entre el retardo mínimo y el máximo en las partes del camino del reloj que son idénticas en los dos cálculos. Las herramientas comparan los caminos del reloj de ambos cálculos y localizan el segmento común a los dos caminos. La suma de todas las diferencias de retardo en ese segmento compartido es el pesimismo del reloj que debe eliminarse.
Como se ha dicho antes, la diferencia entre los caminos del reloj era de 0,575 ns. Pero el pesimismo del reloj aplicado fue solo de 0,527 ns. Por tanto, la reducción fue 0,048 ns menor. La razón es que dentro de la slice hay un pequeño segmento del camino del reloj que no es común a los dos cálculos: un cable interno va al primer flip-flop y otro al segundo. Los retardos de estos dos cables pueden ser distintos.
Incertidumbre del reloj
En el cálculo de tiempos se restaron 0,035 ns al cálculo del camino del reloj. Esto hace más estricto el cálculo de tiempos.
La incertidumbre del reloj tiene en cuenta todo lo que hay de aleatorio en el tiempo entre dos flancos consecutivos del reloj. Esa aleatoriedad se llama jitter del reloj y es el resultado de diversas fuentes de ruido y del comportamiento aleatorio de la electrónica.
La resta de 0,035 ns del cálculo refleja que, aunque en la restricción de temporización (create_clock) el periodo del reloj se define como 4 ns, en realidad ese periodo es aleatorio. Como consecuencia, el tiempo entre dos flancos puede ser más corto. ¿Cuánto más corto? En este cálculo se ha supuesto que el tiempo entre dos flancos nunca será inferior a 3,965 ns (4 - 0,035 = 3,965 ns).
¿Está justificada esta suposición? Es una pregunta difícil, porque la estimación del jitter del reloj es un tema complicado que queda muy fuera del alcance de esta discusión sobre restricciones de temporización. No obstante, se recomienda profundizar en este tema, porque el jitter del reloj puede ser el origen de diversos problemas en un diseño lógico, al margen de las restricciones de temporización.
Con esto termina la primera de dos páginas sobre la restricción del periodo de reloj. Hay más cosas que aprender en la página siguiente...