How does design compiler constrain combinational paths?

Question

This is with reference to the question asked here: Finding Critical Path of Combinational Logic. When design compiler command report_timing is run, it appears the timing requirement for the combinational multiplier doesn't get reported (I say this because I expect the multiplication to be the critical path). Will the circuit still be able to run at the given frequency even though it appears that the timing requirement for the multiplier circuit was ignored? From the answer in the link provided, I understand report_timing only reports timing for register-register paths, in general, should registers be applied to all combinational paths in a digital circuit in order to get a correct functionality/ timing report?

Answer 1

Generally the timing analysis is done register-to-register. The analysis should check all possible paths - it doesn't try to figure out which one is critical, it just calculates all of them and then sorts the list by the path length. It is possible to have timing constraints against I/O pins which are not registered, but this is more of a special case. The timing requirement should not be getting ignored unless there is an issue with how the software determines the paths. It is possible, for example, for the critical path you're interested in to get optimized away. Also, note that the timing of a particular block will vary depending on how it is placed. You could get different performance when you place the block by itself vs. as a component of a larger design.

Answer 2

First: I add my voice to all people suggesting to add registers at the input/outputs of the block you are "profiling" as DC performs timing analysis on register-register paths.

However, what you report (i.e. the timing of a path being ignored) looks more like another kind of problem - for example that the multiplier was not synthesized at all, or synthesized incorrectly. For example, in the question you referenced, your always block contains a multiplier and a latch, which could confuse DC - especially if your libraries don't have latches. If you want a combinational multiplier, you have to specify what happens in all cases:

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

If the semantics of the enable is different (e.g. retain previous value if enable=0) what you want is a combinational multiplier with no enable + a register with enable:

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

I'm not 100% sure this is your problem, but it certainly is a problem in your RTL.

Answer 3

Timing analysis is based on events, in the sense that constraints must be created such that data is generated and sampled and to allow Design Compiler (DC) to analyse timing paths between the various event points.

Typically a block will sample the input data before using it and the output of the internal combinatorial logic is also sampled. In such a design DC will report the timing between the first flop clock pin and the second flop data pin because the clock connecting to these flops is defined and DC is able to generate timing events with it.

The commands set_input_delay and set_output_delay can be used to generate events at port level in respect to a given clock that will end up being analysed by DC in the same way as paths between clocked flops. I expect that this is what you are looking for if there is only combinatorial logic between the input and output ports in your design.