TimeQuest Fmax Calculation

[Altera_Forum]

Hi, 

 I have been studying Altera's tutorials on digital logic. There is a question about maximum operation frequency using Timing Analyzer. I've read another tutorial on TimeQuest Timing Analyzer, but they have not mentioned anything about Fmax. I tried to figure it out intuitively, and used 'Fmax Summary' report.  Is it the report that I need to determine Fmax? or is there any other considerations?  Thank you in advance

[Altera_Forum]

I believe Fmax summary is fmax and may include fmax and restricted fmax. The other consideration is that altera advices on focusing on slack rather than fmax but it could be a pitfall at times. By the way you are based in Syria !! I thought it is all rabbles by now. Good luck.

[Altera_Forum]

Hi kaz, 

 Thank you for your reply.  So that is the "Fmax" that I want right? Another question if you don't mind... Is Fmax and slack are connected to each other? If so, how? Can I change "Restricted Fmax"?  Yes I am based in Syria :) it is all rabbles LOL but passion for FPGA has greater impact on me :D  Thank you so much sir.

[Altera_Forum]

--- Quote Start ---  Hi kaz,  Thank you for your reply.  So that is the "Fmax" that I want right? Another question if you don't mind... Is Fmax and slack are connected to each other? If so, how? Can I change "Restricted Fmax"?  Yes I am based in Syria :) it is all rabbles LOL but passion for FPGA has greater impact on me :D  Thank you so much sir.  --- Quote End ---    there are two types of reported fmax, one is fmax and the other is restricted fmax (not helpful terminology). fmax (classic) is restricted by setup time and so relates to register setup slack directly. It does care about register hold or io speed or pulse width. restricted fmax is restricted by these few other issues like pulse width, io toggle and register hold so any change of fmax or restricted fmax needs looking at its root causes.  Regarding your FPGA passion, I believe it is common secondary result of conflicts and wars and I suffered it before you.

[Altera_Forum]

Thank you very much kaz, you sufficed my confusion :) 

 Hope that you won't see wars anymore. All the best.

[Altera_Forum]

I touch on Fmax in the User Guide I wrote: 

http://www.alterawiki.com/wiki/timequest_user_guide Slack covers setup/hold/recovery/removal on all paths analyzed in the design. The benefit of slack is it can handle many situations, like timing analysis between two different clock domains(in which case Fmax may not make sense. If one can run faster than the other, do you throttle the faster one just to analyze paths to the slower domain) Fmax was added purely because some users feel more comfortable with it. It uses setup analysis and only within the same clock domain, so it ignores any transfers between domains(and therefore can't fully be trusted). But basically a clock with a 10ns period and a slack of 2ns would have an Fmax of 125MHz. My other pet peeve with Fmax is it doesn't give detailed path reports, so if you're not meeting timing you can't determine why. Slack reports give very fine-grained detail if you want it. Restricted Fmax comes from structures in the design that will only toggle so fast and are predetermined by that. Usually their requirements can be found in the data sheet. For example, a global clock tree may only run at 700MHz. Now, if you create a clock domain with two registers in the same LAB, normal setup analysis might show them having a 500ps delay between them and therefore could run at 2GHz, but Restricted Fmax limits it 700MHz of the clock tree. Memory blocks, I/Os, clock trees, I think DSP blocks, etc. all have restricted Fmax. Unless running really fast, you usually don't run into them at all.

[Altera_Forum]

--- Quote Start ---  I touch on Fmax in the User Guide I wrote: http://www.alterawiki.com/wiki/timequest_user_guide Slack covers setup/hold/recovery/removal on all paths analyzed in the design. The benefit of slack is it can handle many situations, like timing analysis between two different clock domains(in which case Fmax may not make sense. If one can run faster than the other, do you throttle the faster one just to analyze paths to the slower domain) Fmax was added purely because some users feel more comfortable with it. It uses setup analysis and only within the same clock domain, so it ignores any transfers between domains(and therefore can't fully be trusted). But basically a clock with a 10ns period and a slack of 2ns would have an Fmax of 125MHz. My other pet peeve with Fmax is it doesn't give detailed path reports, so if you're not meeting timing you can't determine why. Slack reports give very fine-grained detail if you want it. Restricted Fmax comes from structures in the design that will only toggle so fast and are predetermined by that. Usually their requirements can be found in the data sheet. For example, a global clock tree may only run at 700MHz. Now, if you create a clock domain with two registers in the same LAB, normal setup analysis might show them having a 500ps delay between them and therefore could run at 2GHz, but Restricted Fmax limits it 700MHz of the clock tree. Memory blocks, I/Os, clock trees, I think DSP blocks, etc. all have restricted Fmax. Unless running really fast, you usually don't run into them at all.  --- Quote End ---    Great explanation.... Thank you so much!

[Altera_Forum]

Thanks Rysc. In practice I don't see TimeQuest respecting your view. We have several projects and some show positive slack everywhere and so are deemed a "pass" but on reading fmax report it showed very low restricted fmax. I raised SR for that and was told it is due to bla bla... but we asked about how to locate the failing path that causes this low restricted fmax we did not get proper answer as far as I am aware. Our designs that show this low restricted fmax work bit true and so there is no concern at all.

[Altera_Forum]

Did you run Report Minimum Pulse Width? I believe that is where your Restricted Fmax is determined. It's not part of setup/hold/rec/rem analysis. There should be something in your default timing reports that is red and shows failing, which I believe will be the Report Minimum Pulse Width. (It's not the best at clearly explaining why something failed, but usually gives enough detail to figure out the block and then you can find it in the data sheet.) But I am certain there is nothing Report Fmax does that isn't done elsewhere, and there's really no need to have it except some users like it.

[Altera_Forum]

--- Quote Start ---  Did you run Report Minimum Pulse Width? I believe that is where your Restricted Fmax is determined. It's not part of setup/hold/rec/rem analysis. There should be something in your default timing reports that is red and shows failing, which I believe will be the Report Minimum Pulse Width. (It's not the best at clearly explaining why something failed, but usually gives enough detail to figure out the block and then you can find it in the data sheet.) But I am certain there is nothing Report Fmax does that isn't done elsewhere, and there's really no need to have it except some users like it.  --- Quote End ---    No it wasn't pulse width but hold restriction on fmax yet the hold slack was all positive. It must be tool responsibility not to pass hold slack in such cases but looks like it defines hold slack in the classic sense. I would rather look at slack as well as restricted fmax for final verdict.