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

timing problem

Hi everyone : 

Timequest shows errors, removal slack: 

http://www.alteraforum.com/forum/attachment.php?attachmentid=9466&stc=1  

The timing report is : 

http://www.alteraforum.com/forum/attachment.php?attachmentid=9467&stc=1  

In the report timing, the from clock is one output of my pll in Qsys (I think this is the launch clk), the to clock is the clk of fpga, the input of pll(I think this is the latch clk) 

http://www.alteraforum.com/forum/attachment.php?attachmentid=9468&stc=1  

From the report timing waveform, it shows that the data arrival is 0.854ns earlier than the data required time, so I think if I add 2ns phase delay to the pll’s output, the problem will be fixed. 

 

Then I add 2ns phase delay to the pll’s output in the Qsys, generate the system, then start compilation in the quartus. 

Then I check the timequest, and I find the problems still there, even the waveform of the report timing never changes.  

I dout that the quartus did not change the settings of the pll. 

Am I right? 

How to fix it? 

Thanks!
0 Kudos
3 Replies
Altera_Forum
Honored Contributor I
21 Views

No you are not right as you can see. 

 

try registering reset in several locations to reduce fanout. 

altenatively use synchronous reset but this shifts timing burden to hold which is rare.
Altera_Forum
Honored Contributor I
21 Views

 

--- Quote Start ---  

No you are not right as you can see. 

 

try registering reset in several locations to reduce fanout. 

altenatively use synchronous reset but this shifts timing burden to hold which is rare. 

--- Quote End ---  

 

hi thanks ! 

i am new to timing problems, can you explain more?  

or can you give me a document? 

thanks!
Altera_Forum
Honored Contributor I
21 Views

 

--- Quote Start ---  

hi thanks ! 

i am new to timing problems, can you explain more?  

or can you give me a document? 

thanks! 

--- Quote End ---  

 

 

Not a lucky start for a beginner as this is a bit hard. 

reset whether applied to async port or through D input(called synchronous) must be presynchronised by two stage register. This path itself need be excluded from timing. 

 

If reset is not registred then TQ will not report as there would be no reg to reg path and this is misleading. In your case you have TQ reporting it but with failure and hence your reset is registered somewhere... 

 

if double synchroniser does not work then it could be helped by applying further registers on reset path to reduce the fanout or duplicate it and don't let compiler remove them.