Restricted Fmax due to minimum period

The restricted Fmax you're seeing comes into play primarily because of how certain blocks (like IOs, DSPs, and memory blocks) are treated in Quartus. Unlike regular logic paths (where setup/hold timing is explicitly calculated based on delays), these blocks have more complex internal timing architectures that aren't modeled in the same straightforward way. Instead, Quartus uses predefined datasheet-based timing specs for these elements, and those feed into the restricted Fmax figure.

So even if your regular logic can go faster (as shown by the higher unrestricted Fmax), Quartus will limit your clock rate to the lower restricted Fmax if you're using any of these complex blocks, to ensure you're within guaranteed operational limits.

This aligns with the “clock tree performance” numbers you're seeing in the Cyclone 10 LP datasheet — Quartus is enforcing those internal safe limits based on what resources your clock touches (global routing, IO, DSP, memory, etc.). So the restricted Fmax isn’t always about your path timing, it’s often about resource-specific frequency caps baked into the tool.

A few extra clarifications:

• As others have pointed out, you need to look at the lower of Fmax and restricted Fmax to judge the true max clock rate your design can safely achieve.
• To get more insight, it's a good idea to inspect the "Top Failing Paths" or similar reports in the Timing Analyzer to see what’s limiting you — be it logic delay or restricted block usage.

Do you mind to attached your design for me to view? User cannot usually ignore the restricted Fmax.

Thanks for your design,

Upon analysis, this touches on the distinction between achievable Fmax and device-limited Fmax (or restricted Fmax) in Quartus for Cyclone 10 LP devices. Let's break down what you're seeing.

Key Definitions

Fmax (unrestricted):

This is the frequency at which the logic in your design could theoretically run, based on post-fitting delays and your specific logic path. It reflects the performance limited by your design and fitting.

Restricted Fmax (due to minimum period restriction):

This is the frequency constrained by silicon-level device limitations like datasheet specs. In your case, it's Table 20 of the Cyclone 10 LP datasheet which gives a maximum input clock frequency for I/O standards and IOE usage.

Your Observations Explained

Let's break down your cases with interpretation:

Speed Grade Fmax (unrestricted) Restricted Fmax Table 20 Limit Comment

C8 866.5 MHz 402.09 MHz 402 MHz Quartus meets the datasheet restriction.

A7 939.85 MHz 402.09 MHz 402 MHz Device is faster, but still capped by I/O limit.

I7 961.54 MHz 403.06 MHz ~403 MHz Slightly better I/O spec due to industrial grade.

C6 1112.35 MHz 438.02 MHz 438 MHz Faster speed grade allows higher I/O toggle rate.

The Fmax (unrestricted) is higher with better speed grades because the design's flip-flops and interconnects are faster. However, the Restricted Fmax doesn't budge unless the IOE or clock input block limits change per the device datasheet.

Why the Restricted Fmax Doesn’t Increase (Much)

The restricted Fmax is not a limitation of your logic, but of the I/O standard and IOE circuitry used with that clock pin (e.g., LVDS input buffer and IOE PLL pre-processing). This is a hard datasheet constraint — no matter how fast your logic is, Quartus limits this path based on guaranteed device performance across voltage/temp corners.

That’s why even when your unrestricted Fmax goes up (due to better speed grades), the restricted Fmax follows only what the datasheet allows.

Example:

For C8 and A7, the max toggle rate for LVDS inputs is 402 MHz

For C6, it goes up to 438 MHz

This is what Quartus uses as a hard cap when calculating “Restricted Fmax”.

I attached another design for you to play with, usually, when both setup and hold fail at the same I/O path, it's often due to the physical I/O timing limitations — not your logic design.

Design is attached

If you look into the design above, you will need to solve the setup and hold timing by reducing the clock freq to match the restricted Fmax.

Thank you Kenny! This makes perfect sense. However, if Quartus was a little more verbose about the restricted Fmax and mentioned the LVDS frequency limitation in this case it would of course be easier to understand.

The numbers you mention for I/O frequency restriction vs. the different speed grades, I cannot find in the device datasheet. Are they listed somewhere else?

I'll try your design!

I'll answer my own question: Table 29 lists these frequencies for LVDS receiver.

But where are the corresponding max frequency specs for other I/O-standards?

And from table 19 I get the impression that LVDS and LVPECL can go above 500 Mbps (MHz?) if the differential voltage swing is sufficiently large(?)

Thank you for the question.

Regarding the first point — the maximum frequency specifications for other I/O standards (besides LVDS) — I don't believe there is a single table that explicitly lists them.

That said, while datasheets provide general electrical limits and guidance, the most accurate way to determine the maximum supported frequency for a specific I/O standard is to evaluate it directly in Quartus.

This is because Quartus incorporates key factors unique to your design, such as:

• Actual placement and routing
• I/O bank characteristics and configurations
• Drive strength, slew rate, and capacitive loading
• The realistic timing behavior of your chosen I/O standard in context

For example, TimeQuest Timing Analyzer in Quartus reports Fmax and I/O timing margins based on your real design constraints. This offers far more design-specific, accurate insight than static datasheet numbers.

Regarding Table 19: yes, for LVDS and LVPECL, a larger differential voltage swing can help support frequencies above 500 Mbps — but whether your implementation can actually achieve that depends on the routing quality, board-level signal integrity, and internal FPGA timing, all of which Quartus can evaluate directly.

So instead of relying solely on theoretical values, we highly recommend validating your desired frequency in Quartus. This gives you results that are:

• Specific to your implementation
• Validated by actual timing analysis
• Reliable for real-world use cases

Thank you again.

But I can't help feel some contradiction regarding your last paragraph.
Since there is no way I can tell Quartus about which differential voltage swing I will apply to an LVDS input pin (or is there?), it will, in my case, give me the restricted Fmax based on table 20 and not from table 19.
So when you say that "whether your implementation can actually achieve [frequencies above 500 Mbps] depends on the routing quality, board-level signal integrity, and internal FPGA timing, all of which Quartus can evaluate directly", does it mean that I can ignore the restricted Fmax after all, and safely apply my 500 MHz clock, with a good voltage swing, to an LVDS input and use my design as is, since the Fmax reported is something like 900 MHz?

Sorry for this long thread...