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.