Es esencial aplicar restricciones de tiempo a su cruce de dominio de reloj multibit. Si este bus tiene una restricción de set_false_path , entonces el sesgo a través del bus puede ser más de 1 período de reloj, lo que puede causar errores funcionales.
El primer requisito es que no tenga una restricción de set_false_path entre los dos dominios de reloj. Si no desea que las rutas entre ellos se analicen para la configuración y la retención, puede usar set_clock_groups, que tiene una prioridad más baja.
A continuación, restrinja los caminos con set_net_delay para hacerlos lo más cortos posible y con set_max_skew. set_max_skew no restrinja al ajuste, pero puede analizar contra esta restricción en el Analizador de tiempo.
Las restricciones para un cruce de dominio de reloj entre data_a en clk_a de dominio de reloj y data_b en clk_b de dominio de reloj podrían tener este aspecto.
create_clock -name clk_a -period 4.000 [get_ports {clk_a}]
create_clock -name clk_b -period 4.500 [get_ports {clk_b}]
set_clock_groups -asynchronous -group [get_clocks {clk_a}] -group [get_clocks {clk_b}]
set_net_delay -from [get_registers {data_a[*]}] -to [get_registers {data_b[*]}] -max -get_value_from_clock_period dst_clock_period -value_multiplier 0.8
set_max_skew -from [get_keepers {data_a[*]}] -to [get_keepers {data_b[*]}] -get_skew_value_from_clock_period min_clock_period -skew_value_multiplier 0.8
Los requisitos de sesgo dependerán de su diseño y de cómo manejó el cruce de dominio de reloj.
Por último, compruebe la temporización del cruce de dominio de reloj ejecutando Report Max Skew Summary e Report Net Delay Summary en el Analizador de tiempo.