- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

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.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

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.

Link Copied

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

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.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

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.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

Hi,

the key for explanation is in the logic cell name pps_6~0_**RESYN**438. 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.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

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.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

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.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

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.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

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;

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page