time contain for a driver

Question

hi,

I have a divider as following. I usually ignore the timing report for the divider. I started to check those timing report for the divider. There is a hold timing violation as shown in the screen capture. Hold timing violation means the data changes too quick after the sampling clock. So I have several questions about the report.

1) Does the timing report really mean that the clk_out change too quick after the sampling edge due to the loop back to the input?

2) I implemented the divider like this for many years. If the answer is yes to question 1, how should the divider be implemented to correct the timing violation?

3) If the answer is no to question 1, then why does the TimeQuest reports it as a violation? Should I ignore this violation by set as a node false path from clk_out to clk_out?

thanks

Peng

module divider

#(

// parameter declarations

parameter divider = 1000,

parameter cnt_width = 16

)

(

// input ports

input rst_n,

input sys_clk,

output reg clk_out

);

// timer counter

reg[cnt_width-1:0] counter;

always @(posedge sys_clk or negedge rst_n)

begin

if(!rst_n)

begin

counter<=0;

clk_out<=1'b0;

end

else

if(counter==divider-1)

begin

counter<=0;

clk_out<=~clk_out;

end

else

counter<=counter+1'b1;

end

endmodule

https://alteraforum.com/forum/attachment.php?attachmentid=14256&stc=1

altera_forum · Answer

Have you created the false_path constraints for the reset and any other asynchronous signals? If you don't do this, the tool may report timing violations at these paths. It looks like the path is a data path and the slack is small -0.054. You could try and get the tool fix this by enabling the "Register re-timing" option in Quartus. This will instruct the tool to try and position the registers in your design to try and get rid of the -ve slack and can also get rid of your violations.

altera_forum · Answer

I spent some time on checking the data path. I then realized that this kind of feedback(loopback) is actually launch on one clock and latch on the next clock. Basically, the change of the output is launched on the current clock, but the feedback is latch on the next clock. This is a typical multicycle case. So if I set the the path to be multicycle, and set both setup and hold to be 1. It eliminates the violation.

I think the default setting of the filter is to not to prevent register re-timing, which means register re-timing it is enabled.

altera_forum · Answer

--- Quote Start ---

I spent some time on checking the data path. I then realized that this kind of feedback(loopback) is actually launch on one clock and latch on the next clock. Basically, the change of the output is launched on the current clock, but the feedback is latch on the next clock. This is a typical multicycle case. So if I set the the path to be multicycle, and set both setup and hold to be 1. It eliminates the violation.

I think the default setting of the filter is to not to prevent register re-timing, which means register re-timing it is enabled.

--- Quote End ---

I somewhat disagree.

Any data path is launch on one edge and latch on next. I think you mean in your case it is one register for source and destination, true but that still requires setup of 1, hold of 0.

if you make it setup of 1 and hold of 1 you are giving hold extra clock by mistake and so passes timing.

I believe you better insert delay in the inverter path of clk_out as it is launched too early for latch having a short path. Seems the fitter didn't manage it.

altera_forum · Answer

--- Quote Start ---

Hi Kaz,

I think I agree with you that the hold should be 0 for this case. However, I don't believe there should be a timing violation for this case.

To check the hold time, the data arrival time should be greater than the the data required time. The data required time is calculated by Latch Edge + dst_clk_dly as shown in the screen capture.

https://alteraforum.com/forum/attachment.php?attachmentid=14283&stc=1

In the case, because the data is feedback to its own input, the dst_clk_dly or any clock uncertainly should be removed, which means the required time is only the latch edge plus the uTh. So the require time is 0.212, not 0.712. The data arrival time is 0.658. So there's violation.

https://alteraforum.com/forum/attachment.php?attachmentid=14284&stc=1

This make sense to me, because the input data and the clock are related to each other now. The input to this register only changes after its own clock changes. And both changes are referred to the same time (latch time =launch time). So all kinds of dst clock delay and clock uncertainly should also be applied to the data input, or don't use the delay and the uncertainly at all.

Since it is for the same node (clk_out). I think it's better to assign a node to node false path.

--- Quote End ---

Again I disagree, the tool is mature enough to do the job and not depend on user to rectify it. clock uncertainty is still relevant but common clock path pessimism will be removed.

altera_forum · Answer

--- Quote Start ---

Again I disagree, the tool is mature enough to do the job and not depend on user to rectify it. clock uncertainty is still relevant but common clock path pessimism will be removed.

--- Quote End ---

That is fine, agree to disagree. My understanding is that the tool is mature enough so that it leave the space for the users to rectify some cases that it cannot solve under its normal rules. Otherwise, what's the point to have the falsepatth option in the constrain?

Forum Discussion

time contain for a driver

6 Replies

Recent Discussions

SDC_ENTITY_FILE critical warnings

How-to generate dual-port (read/write) RAM with clock enables

GTS SDI II IP Core not producing correct tx_vid_clkout frequency

Quartus 20.1std compilation fails for Quartus map - Device 10AS057K2F40I1SG

Failing IO buffer