En el desarrollo de circuitos integrados, es práctica estándar insertar registros en las señales de entrada y salida del módulo o chip. Esto ayuda a lograr la convergencia temporal y proporciona margen para el cierre de tiempos, evitando violaciones de temporización en la interfaz de E/S al instanciar módulos sintetizados. Durante la fase de síntesis, se pueden establecer restricciones de entrada y salida entre el 40% y 60% del período del reloj, según los requisitos del diseño y la tecnología.

Sin embargo, durante el sign-off de temporización, pueden surgir violaciones menores en las E/S, como violaciones de hold en los registros de entrada o violaciones de setup en los registros de salida. Esto ocurre porque las herramientas de análisis temporal de EDA asumen que los registros externos son modelos ideales sin retrasos de propagación del reloj.

Por ejemplo, al ejecutar el comando set_propagated_clock, el reloj CLK2 en el registro de entrada no tiene retraso de inserción, mientras que CLK1 (con la misma frecuencia y fase) sí lo tiene. Esto puede causar violaciones de hold en la entrada, mientras que el setup se cumple más fácilmente. De manera similar, para la salida, el setup puede violarse, pero el hold se facilita.

Consideremos un registro de salida donde el path de datos del reloj de lanzamiento tiene un retraso de 1.5 ns. Debido a que el registro externo asumido no tiene retraso de propagación, se produce una violación de setup, aunque el hold se mantiene.

El reloj virtual surge como solución. Se crea sin asignar a un pin o puerto físico:

create_clock -name clk_virtual -period 10

Luego, se utilizan restricciones de retraso de entrada y salida basadas en este reloj virtual:

set_input_delay 8 -clock clk_virtual [get_ports entrada_datos]

set_output_delay 8 -clock clk_virtual [get_ports salida_datos]

La herramienta EDA evaluará el retraso de propagación del registro externo asumido basándose en el retraso real del reloj interno, evitando violaciones falsas. Sin un reloj virtual, sería necesario revisar manualmente estas violaciones en cada análisis, reduciendo la eficiencia.

Al definir restricciones con set_input_delay y set_output_delay, se puede usar un reloj real o uno virtual. Para un reloj virtual con la misma frecuencia que el real, no se especifica puerto:

set periodo 5

create_clock -name CLKP -period $periodo [get_ports CLKP]

create_clock -name vCLKP -period $periodo

Antes del árbol de relojes (CTS), no hay diferencia entre usar relojes reales o virtuales, ya que ambos se consideran ideales. Después de CTS, las diferencias son clave:

• Con un reloj real, el retraso del reloj en el registro virtual externo se ignora, tratándose como un modelo ideal.
• Con un reloj virtual, la herramienta puede estimar el retraso promedio del reloj interno para el registro externo, proporcionando un aálisis más preciso.

Para facilitar el cierre de temporización a nivel superior, se aplica sobrerestricción en los caminos IN2REG y REG2OUT, típicamente configurando el retraso externo al 60% del período del reloj, dejando el 40% para el path interno. Esto depende de los requisitos del proyecto, especificaciones y condiciones tecnológicas.

Además, es importante especificar las opciones -max y -min en set_input_delay para verificar setup y hold respectivamente. Si no se especifican, la herramienta usará el mismo valor para ambos análisis.

set retraso_relativo 0.6

set_input_delay [expr $retraso_relativo * $periodo] -clock vCLKP [get_ports CIN]