Why does this code generate extra combinational logic?

[student8]

The timing analysis indicates the presence of extra levels of combinational logic, but  I only have one layer of combinational logic.I don't know where the extra combinational logic is?

The recommended violation resolution methods in the time series analysis report are as follows.

The code for this path is as follows.Among them, clk_6 is a 500MHz clock generated by a PLL.

always@(posedge clk_6 or negedge rst) begin
       if(!rst) begin
                         pps_6<=1'd0;
                  end
       else begin
                if(delay_2==4'd5)
                 begin
                         pps_6=pps_coarse;end
                 else begin
                           pps_6<=1'b0;end
               end
       end

Below is the timing analysis for the error path.

[FvM · Accepted solution]

Hi,
to answer the question precisely, you can review the post-mapping or post-fitting schematic. It will show you the function of each lcell.

Without seeing the actual logic, I'd guess: The circuit has 5 input bits, 4 delay_2 bits and pps_coarse. Respectively it needs 2 combinational logic cells if it's implemented in 4-input LUTs.

[student8]

Thank you for your reply. This is the post-fitting schematic.

What do you mean by "actual logic" in your reply? chip planner or resource property editor？

The complete code for this section is included in the attachment. I aim to achieve an 8x frequency multiplication of the 500M clock through phase shifting in a  (PLL) to achieve precise delay control.

I'm using Cyclone 5CGXFC5C6F23C6, and the underlying architecture should be based on 6-input LUTs.

Thank you again for your response.

[FvM]

Hi,
the key for explanation is in the logic cell name pps_6~0_RESYN438. Quartus is actually generating extra logic in resynthesis, trying to meet timing, apparently without success. 

This would never happen if the basic design achieves timing closure.

I see that the module has multiple input clocks and a variable delay_value input. Without knowing the timing relation of all clocks and delay_value and specified timing constraints, it's impossible to determine if and how the design can meet timing. You have e.g. a pretty long combinational path from delay_value through dividers, unless it's static data flagged as false path, the design can't achieve higher clock rates. Or the output of delay calculation has to be resynced to respective clk_6 domain.  

[student8]

Thank you very much for your response. Following your advice, I successfully converted delay_value to synchronous logic, eliminating the setup time violation issue from pps_coarse to pps_6.

Unfortunately, my code still has timing problems. As shown in the diagram, there are timing violations between the adders. For example, an illustration is provided below. I'm unsure how to address this issue.

The code for the section, except for the delay_value part, remains unchanged and is the same as the previous attachment.

Once again, thank you for your reply, and I apologize for taking up your time.

[sstrell]

I don't know if this is part of the problem, but when does count_1_l[16] ever get set?  Your adder is only adding one to the lower 16 bits:

count_1_l<=count_1_l[15:0]+17'd1;

Is that a typo?

It's not clear why so much logic is between bit 4 and bit 10 but this vector slicing could have something to do with it.

[student8]

Thank you for your reply.

in this segment, I calculate the sum of count_1_l[15:0] and 1 each time. The carry bit, count_1_l[16], is assigned as the carry input (cin).

The carry input (cin) is involved in the calculation of count_1_h.

If there is any error in my logic, please point it out.

[sstrell]

No.  Your carry bit is not going into count_1_l[16] because that bit is not included in your adder.  You need to fix your addition:

count_1_l<=count_1_l[16:0]+17'd1;