¿Cómo restringe el compilador de diseño las rutas combinatorias?

Generalmente, el análisis de tiempo se realiza de registro a registro. El análisis debe verificar todas las rutas posibles: no intenta determinar cuál es crítica, simplemente las calcula todas y luego ordena la lista por la longitud de la ruta. Es posible tener restricciones de tiempo contra los pines de E / S que no están registrados, pero esto es más un caso especial. El requisito de tiempo no debe ignorarse a menos que haya un problema con la forma en que el software determina las rutas. Es posible, por ejemplo, que la ruta crítica en la que está interesado se optimice. Además, tenga en cuenta que la sincronización de un bloque en particular variará dependiendo de cómo se coloca. Podría obtener un rendimiento diferente cuando coloca el bloque solo como componente de un diseño más grande.

Primero: agrego mi voz a todas las personas que sugieren agregar registros en las entradas / salidas del bloque que está "perfilando" a medida que el DC realiza el análisis de tiempo en registro-registro rutas.

Sin embargo, lo que informa (es decir, la sincronización de una ruta ignorada ) se parece más a otro tipo de problema, por ejemplo, que el multiplicador no se sintetizó en absoluto o se sintetizó incorrectamente. Por ejemplo, en la pregunta a la que hizo referencia, su bloque always contiene un multiplicador y un pestillo , que podrían confundir DC, especialmente si sus bibliotecas no tienen pestillos. Si desea un multiplicador combinacional, debe especificar qué sucede en todos casos:

always @(*)
begin
  if(enable)
    out = in1 * in2;
  else
    out = 0;
end

Si la semántica de enable es diferente (por ejemplo, retenga el valor anterior si enable=0 ) lo que quiere es un multiplicador combinativo sin habilitación + un registro con habilitación:

reg [31:0] mul_comb;
assign mul_comb = in1 * in2;
always @(posedge clk or negedge rst_n)
begin
  if(rst_n==1'b0)
    out <= 0;
  else if(enable)
    out <= mul_comb;
end

No estoy 100% seguro de que este sea tu problema, pero ciertamente is es un problema en tu RTL.

El análisis de tiempo se basa en eventos, en el sentido de que se deben crear restricciones para que los datos se generen y muestreen, y para permitir que Design Compiler (DC) analice las rutas de tiempo entre los distintos puntos de eventos.

Normalmente, un bloque muestreará los datos de entrada antes de usarlos y también se muestreará la salida de la lógica combinatoria interna. En un diseño de este tipo, DC informará el tiempo entre el primer pin del reloj de flop y el segundo pin de datos del flop porque el reloj que se conecta a estos flops está definido y DC puede generar eventos de tiempo con él.

Los comandos set_input_delay y set_output_delay pueden usarse para generar eventos a nivel de puerto con respecto a un reloj dado que DC terminará analizando de la misma manera que las rutas entre los flops cronometrados. Espero que esto sea lo que está buscando si solo hay lógica combinatoria entre los puertos de entrada y salida en su diseño.