Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Altera_Forum
Honored Contributor I
839 Views

time contain for a driver

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
0 Kudos
6 Replies
Altera_Forum
Honored Contributor I
38 Views

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
Honored Contributor I
38 Views

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
Honored Contributor I
38 Views

 

--- 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
Honored Contributor I
38 Views

 

--- 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
Honored Contributor I
38 Views

 

--- 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?
Altera_Forum
Honored Contributor I
38 Views

 

--- Quote Start ---  

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? 

--- Quote End ---  

 

 

commands like false path, multicycle, set input delays ...etc are determined by user. The tool cannot know the internl sampling behaviour of your design or board issues. 

In future, I assume, it might automatically detect internal multicycle paths or even some false paths by examining your logic and given inputs.
Reply