Vale, ¿qué es esto?
Esta página es la parte de ejemplos de otro artículo, en el que se explica el significado de set_input_delay y set_output_delay en las restricciones de temporización (timing constraints) de SDC.
De acuerdo con ese otro artículo, las restricciones de temporización que hay detrás de los ejemplos siguientes son:
create_clock -name theclk -period 20 [get_ports test_clk] set_output_delay -clock theclk -max 8 [get_ports test_out] set_output_delay -clock theclk -min -3 [get_ports test_out] set_input_delay -clock theclk -max 4 [get_ports test_in] set_input_delay -clock theclk -min 2 [get_ports test_in]
Análisis de set_input_delay -max (setup)
Slack (MET) : 15.664ns (required time - arrival time)
Source: test_in
(input port clocked by theclk {rise@0.000ns fall@10.000ns period=20.000ns})
Destination: test_samp_reg/D
(rising edge-triggered cell FDRE clocked by theclk {rise@0.000ns fall@10.000ns period=20.000ns})
Path Group: theclk
Path Type: Setup (Max at Fast Process Corner)
Requirement: 20.000ns (theclk rise@20.000ns - theclk rise@0.000ns)
Data Path Delay: 2.465ns (logic 0.291ns (11.797%) route 2.175ns (88.203%))
Logic Levels: 1 (IBUF=1)
Input Delay: 4.000ns
Clock Path Skew: 2.162ns (DCD - SCD + CPR)
Destination Clock Delay (DCD): 2.162ns = ( 22.162 - 20.000 )
Source Clock Delay (SCD): 0.000ns
Clock Pessimism Removal (CPR): 0.000ns
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
Location Delay type Incr(ns) Path(ns) Netlist Resource(s)
------------------------------------------------------------------- -------------------
(clock theclk rise edge) 0.000 0.000 r
input delay 4.000 4.000
AE20 0.000 4.000 r test_in (IN)
net (fo=0) 0.000 4.000 test_in
AE20 IBUF (Prop_ibuf_I_O) 0.291 4.291 r test_in_IBUF_inst/O
net (fo=1, routed) 2.175 6.465 test_in_IBUF
SLICE_X0Y1 FDRE r test_samp_reg/D
------------------------------------------------------------------- -------------------
(clock theclk rise edge) 20.000 20.000 r
AE23 0.000 20.000 r test_clk (IN)
net (fo=0) 0.000 20.000 test_clk
AE23 IBUF (Prop_ibuf_I_O) 0.077 20.077 r test_clk_IBUF_inst/O
net (fo=1, routed) 1.278 21.355 test_clk_IBUF
BUFGCTRL_X0Y4 BUFG (Prop_bufg_I_O) 0.026 21.381 r test_clk_IBUF_BUFG_inst/O
net (fo=2, routed) 0.781 22.162 test_clk_IBUF_BUFG
SLICE_X0Y1 FDRE r test_samp_reg/C
clock pessimism 0.000 22.162
clock uncertainty -0.035 22.126
SLICE_X0Y1 FDRE (Setup_fdre_C_D) 0.003 22.129 test_samp_reg
-------------------------------------------------------------------
required time 22.129
arrival time -6.465
-------------------------------------------------------------------
slack 15.664
Este análisis comienza en el instante 0. A continuación suma los 4 ns de retardo de reloj a salida (clock-to-output) que se especificaron en la restricción de retardo máximo de entrada, y sigue por la ruta de datos (data path). Los valores de retardo de los elementos lógicos son los de la combinación más rápida posible de proceso, tensión y temperatura. Junto con el retardo propio de la ruta de datos de la FPGA (2,465 ns), el retardo total de la ruta de datos queda en 6,465 ns.
A continuación se calcula la ruta del reloj (clock path), partiendo del flanco siguiente del reloj, en 20 ns. Una vez más, los valores de los retardos se eligen con la combinación más rápida posible. El reloj viaja desde el pin de entrada hasta el flip-flop, sin compensar el retardo de la red de reloj, ya que no interviene ningún PLL. Este cálculo también tiene en cuenta el jitter estimado, mediante la «incertidumbre de reloj» (clock uncertainty). En resumen, la ruta del reloj termina en 22,129 ns, que son 15,664 ns después de que el dato llegara al flip-flop. Ese es el margen (slack) de la restricción.
Este análisis demuestra que el número que hay que poner en una restricción set_input_delay -max es el retardo de reloj a salida (clock-to-output) máximo del dispositivo externo que excita el pin de entrada, más el retardo de la pista de la placa (trace delay). Llegamos a esa conclusión porque ese número se usa como instante de partida de la ruta de datos. Observa la parte «Max» en el «Path Type» de más arriba.
Análisis de set_input_delay -min (hold)
Min Delay Paths -------------------------------------------------------------------------------------- Slack (VIOLATED) : -0.045ns (arrival time - required time) Source: test_in (input port clocked by theclk {rise@0.000ns fall@10.000ns period=20.000ns}) Destination: test_samp_reg/D (rising edge-triggered cell FDRE clocked by theclk {rise@0.000ns fall@10.000ns period=20.000ns}) Path Group: theclk Path Type: Hold (Min at Slow Process Corner) Requirement: 0.000ns (theclk rise@0.000ns - theclk rise@0.000ns) Data Path Delay: 3.443ns (logic 0.626ns (18.194%) route 2.817ns (81.806%)) Logic Levels: 1 (IBUF=1) Input Delay: 2.000ns Clock Path Skew: 5.351ns (DCD - SCD - CPR) Destination Clock Delay (DCD): 5.351ns Source Clock Delay (SCD): 0.000ns Clock Pessimism Removal (CPR): -0.000ns 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 Location Delay type Incr(ns) Path(ns) Netlist Resource(s) ------------------------------------------------------------------- ------------------- (clock theclk rise edge) 0.000 0.000 r input delay 2.000 2.000 AE20 0.000 2.000 r test_in (IN) net (fo=0) 0.000 2.000 test_in AE20 IBUF (Prop_ibuf_I_O) 0.626 2.626 r test_in_IBUF_inst/O net (fo=1, routed) 2.817 5.443 test_in_IBUF SLICE_X0Y1 FDRE r test_samp_reg/D ------------------------------------------------------------------- ------------------- (clock theclk rise edge) 0.000 0.000 r AE23 0.000 0.000 r test_clk (IN) net (fo=0) 0.000 0.000 test_clk AE23 IBUF (Prop_ibuf_I_O) 0.734 0.734 r test_clk_IBUF_inst/O net (fo=1, routed) 2.651 3.385 test_clk_IBUF BUFGCTRL_X0Y4 BUFG (Prop_bufg_I_O) 0.093 3.478 r test_clk_IBUF_BUFG_inst/O net (fo=2, routed) 1.873 5.351 test_clk_IBUF_BUFG SLICE_X0Y1 FDRE r test_samp_reg/C clock pessimism 0.000 5.351 clock uncertainty 0.035 5.387 SLICE_X0Y1 FDRE (Hold_fdre_C_D) 0.101 5.488 test_samp_reg ------------------------------------------------------------------- required time -5.488 arrival time 5.443 ------------------------------------------------------------------- slack -0.045
Este análisis comienza en el instante 0. Después suma los 2 ns de retardo de reloj a salida (clock-to-output) que se especificaron en la restricción de retardo mínimo de entrada, y sigue por la ruta de datos. Los valores de retardo de los elementos lógicos se toman de la combinación más lenta posible de proceso, tensión y temperatura. Si añadimos el retardo propio de la ruta de datos de la FPGA (3,443 ns), el retardo total queda en 5,443 ns. No debe extrañar que el retardo interno de la FPGA sea mayor que en el análisis rápido anterior.
Después se calcula la ruta del reloj, esta vez con la combinación más lenta posible. El cálculo parte del mismo flanco de reloj, en 0 ns. Al fin y al cabo, es una comprobación de hold: la pregunta es si el dato no cambió en la entrada del flip-flop antes de que éste llegara a capturarlo.
El reloj viaja desde el pin de entrada hasta el flip-flop, sin compensar el retardo de la red de reloj, porque no hay PLL. Este cálculo también tiene en cuenta el jitter estimado, mediante la «incertidumbre de reloj» (clock uncertainty). Observa que tiene el mismo valor que el cálculo para el setup, pero con el signo cambiado. Es el mismo jitter, pero el peor caso va en la dirección contraria.
En resumen, la ruta del reloj termina en 5,488 ns, lo que llega 0,045 ns tarde (el dato cambió en 5,443 ns). Por tanto, la restricción se viola, con un margen negativo de 0,045 ns.
Este análisis demuestra que el número que se debe usar en una restricción set_input_delay -min es el retardo de reloj a salida (clock-to-output) mínimo del dispositivo externo que excita el pin de entrada. Llegamos a esa conclusión porque ese número se usa como instante de partida de la ruta de datos. Observa la parte «Min» en el «Path Type» de más arriba.
Puede parecer sorprendente que un retardo de reloj a salida (clock-to-output) mínimo de 2 ns pueda violar una restricción de hold. No hay que tomárselo a la ligera: como cualquier restricción de temporización violada, puede causar problemas reales si se ignora.
La solución en este caso sería añadir un PLL a la ruta del reloj, de modo que el reloj de la red global se enganche con el reloj de entrada. En la práctica, eso equivale a adelantarlo varios nanosegundos, lo que resuelve el problema sin duda.
Análisis de set_output_delay -max (setup)
Slack (MET) : 2.983ns (required time - arrival time)
Source: test_out_reg/C
(rising edge-triggered cell FDRE clocked by theclk {rise@0.000ns fall@10.000ns period=20.000ns})
Destination: test_out
(output port clocked by theclk {rise@0.000ns fall@10.000ns period=20.000ns})
Path Group: theclk
Path Type: Max at Slow Process Corner
Requirement: 20.000ns (theclk rise@20.000ns - theclk rise@0.000ns)
Data Path Delay: 3.631ns (logic 2.583ns (71.152%) route 1.047ns (28.848%))
Logic Levels: 1 (OBUF=1)
Output Delay: 8.000ns
Clock Path Skew: -5.351ns (DCD - SCD + CPR)
Destination Clock Delay (DCD): 0.000ns = ( 20.000 - 20.000 )
Source Clock Delay (SCD): 5.351ns
Clock Pessimism Removal (CPR): 0.000ns
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
Location Delay type Incr(ns) Path(ns) Netlist Resource(s)
------------------------------------------------------------------- -------------------
(clock theclk rise edge) 0.000 0.000 r
AE23 0.000 0.000 r test_clk (IN)
net (fo=0) 0.000 0.000 test_clk
AE23 IBUF (Prop_ibuf_I_O) 0.734 0.734 r test_clk_IBUF_inst/O
net (fo=1, routed) 2.651 3.385 test_clk_IBUF
BUFGCTRL_X0Y4 BUFG (Prop_bufg_I_O) 0.093 3.478 r test_clk_IBUF_BUFG_inst/O
net (fo=2, routed) 1.873 5.351 test_clk_IBUF_BUFG
SLICE_X0Y1 FDRE r test_out_reg/C
------------------------------------------------------------------- -------------------
SLICE_X0Y1 FDRE (Prop_fdre_C_Q) 0.223 5.574 r test_out_reg/Q
net (fo=1, routed) 1.047 6.622 test_out_OBUF
AK21 OBUF (Prop_obuf_I_O) 2.360 8.982 r test_out_OBUF_inst/O
net (fo=0) 0.000 8.982 test_out
AK21 r test_out (OUT)
------------------------------------------------------------------- -------------------
(clock theclk rise edge) 20.000 20.000 r
clock pessimism 0.000 20.000
clock uncertainty -0.035 19.965
output delay -8.000 11.965
-------------------------------------------------------------------
required time 11.965
arrival time -8.982
-------------------------------------------------------------------
slack 2.983
Como este análisis pretende medir el retardo de salida, se empieza por el flanco de reloj, se sigue hasta el flip-flop y después por la ruta de datos. Todo ello suma un retardo total de 8,982 ns.
Observa que el «Path Type» no dice que sea un cálculo de setup (¿será para evitar confusiones?), aunque tiene en cuenta el flanco siguiente del reloj, en 20 ns, y no el mismo flanco, en 0 ns.
El cálculo se realiza con la combinación más lenta posible de proceso, tensión y temperatura (recuerda que el cálculo de setup para la entrada se hacía con la combinación más rápida). La ruta del reloj es muy parecida a la del análisis de hold del retardo de entrada. No es de extrañar, porque ambos cálculos se basan en el modelo lento.
El retardo total se compara con el instante del flanco siguiente del reloj, en 20 ns, menos el valor dado con set_output_delay. Y menos el jitter estimado (0,035 ns en el caso anterior).
En resumen: el dato alcanza un estado lógico estable en 8,982 ns, y debe permanecer estable hasta unos 12 ns, así que hay un margen de casi 3 ns.
Esto demuestra por qué el número que se usa con set_output_delay -max debe ser el tiempo de setup especificado para la entrada del dispositivo externo. Esta restricción se comprueba calculando la diferencia entre el retardo total hasta que el dato es válido en la salida y la posición temporal del siguiente flanco de reloj. Esa diferencia es el objetivo que hay que cumplir. Es exactamente la definición de tiempo de setup: cuánto tiempo debe permanecer estable el dato antes del siguiente flanco de reloj.
Análisis de set_output_delay -min (hold)
Slack (MET) : 0.791ns (arrival time - required time)
Source: test_out_reg/C
(rising edge-triggered cell FDRE clocked by theclk {rise@0.000ns fall@10.000ns period=20.000ns})
Destination: test_out
(output port clocked by theclk {rise@0.000ns fall@10.000ns period=20.000ns})
Path Group: theclk
Path Type: Min at Fast Process Corner
Requirement: 0.000ns (theclk rise@0.000ns - theclk rise@0.000ns)
Data Path Delay: 1.665ns (logic 1.384ns (83.159%) route 0.280ns (16.841%))
Logic Levels: 1 (OBUF=1)
Output Delay: -3.000ns
Clock Path Skew: -2.162ns (DCD - SCD - CPR)
Destination Clock Delay (DCD): 0.000ns
Source Clock Delay (SCD): 2.162ns
Clock Pessimism Removal (CPR): -0.000ns
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
Location Delay type Incr(ns) Path(ns) Netlist Resource(s)
------------------------------------------------------------------- -------------------
(clock theclk rise edge) 0.000 0.000 r
AE23 0.000 0.000 r test_clk (IN)
net (fo=0) 0.000 0.000 test_clk
AE23 IBUF (Prop_ibuf_I_O) 0.077 0.077 r test_clk_IBUF_inst/O
net (fo=1, routed) 1.278 1.355 test_clk_IBUF
BUFGCTRL_X0Y4 BUFG (Prop_bufg_I_O) 0.026 1.381 r test_clk_IBUF_BUFG_inst/O
net (fo=2, routed) 0.781 2.162 test_clk_IBUF_BUFG
SLICE_X0Y1 FDRE r test_out_reg/C
------------------------------------------------------------------- -------------------
SLICE_X0Y1 FDRE (Prop_fdre_C_Q) 0.100 2.262 r test_out_reg/Q
net (fo=1, routed) 0.280 2.542 test_out_OBUF
AK21 OBUF (Prop_obuf_I_O) 1.284 3.826 r test_out_OBUF_inst/O
net (fo=0) 0.000 3.826 test_out
AK21 r test_out (OUT)
------------------------------------------------------------------- -------------------
(clock theclk rise edge) 0.000 0.000 r
clock pessimism 0.000 0.000
clock uncertainty 0.035 0.035
output delay 3.000 3.035
-------------------------------------------------------------------
required time -3.035
arrival time 3.826
-------------------------------------------------------------------
slack 0.791
Este análisis es parecido al del retardo máximo de salida, solo que se calcula contra el mismo flanco de reloj, no contra el siguiente. Además, se realiza con la combinación más rápida posible de proceso, tensión y temperatura.
Igual que antes, la ruta del reloj es muy parecida a la del análisis de setup del retardo de entrada. No es de extrañar, porque ambos cálculos se basan en el modelo rápido.
Como con el cálculo de set_output_delay -max, la ruta de datos continúa después de la ruta del reloj hasta que la salida es estable. Según el cálculo, eso ocurre en 3,826 ns (fíjate en la diferencia con el modelo lento).
Eso se compara con el instante del mismo flanco de reloj, en 0 ns, menos el retardo de salida. Recuerda que el retardo mínimo de salida en la restricción es negativo (-3 ns), por lo que en el cálculo aparece como un número positivo.
También se suma el jitter estimado, 0,035 ns (la verdad es que no acabo de entender por qué se usa el jitter en este cálculo, si es en el mismo ciclo de reloj).
Conclusión: el dato se mantiene estable hasta 3,826 ns, y debe mantenerse estable hasta 3,035 ns. Eso está bien; el margen es de 0,791 ns.
Esto demuestra por qué el número que se usa con set_output_delay -min es el tiempo de hold especificado para la entrada del dispositivo externo, pero con el signo cambiado. Esta restricción se comprueba exigiendo que el retardo total sea mayor que ese número. Dicho de otro modo: el dato debe permanecer estable durante ese tiempo después del flanco de reloj. Esa es la definición de tiempo de hold.