- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have created a simple project with a 500 MHz clock fed into a clock pin set for LVDS. This clock goes only to a divide-by-4 block (two flip-flops) and the resulting 125 MHz is fed to an output pin.
If I compile this for a Cyclone10LP (10CL006YE144) with speed grade C8, the timing analyzer says that Fmax is 866.5 MHz but restricted Fmax is 402.09 MHz (due to minimum period restriction), for Slow 1200mV 100C Model. This somewhat correlates to table 20 about clock tree performance, in the Cyclone 10 LP device datasheet, which specifies max 402 MHz. I cannot find any definition about this "clock tree performance" so I guess it is just a "stay safe and keep below"-value used by Quartus for max frequency regardless of calculated setup and hold times.
Changing to a device with speed grade A7, I get Fmax at 939.85 MHz and restricted Fmax at 402.09 MHz. I don't understand why the first value now is higher, but the latter still correlates with table 20 that states 402 MHz for A7.
Changing to speed grade I7, I get Fmax at 961.54 MHz and restricted Fmax at 403.06 MHz. Now this does not correlate with table 20, that states 437.5 MHz max for I7.
And for C6, I get Fmax at 1112.35 MHz and restricted Fmax at 438.02 - not the 500 MHz stated in table 20.
How should this be understood?
Link Copied
- « Previous
-
- 1
- 2
- Next »
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I attached the same design used above. If you change the I/O standard to 1.8V, you'll see the restricted Fmax aligns more closely with the clock tree performance numbers. For the LVDS I/O standard, we don’t document its maximum clock frequency — we only specify 500 Mbps, which corresponds to a 250 MHz clock for double data rate operation.
The 500 Mbps limit is for data transmission — with DDR input registers capturing data on both edges of a 250 MHz clock. If you’re feeding a 500 MHz clock into an LVDS pin (single-ended clock), this exceeds the intended use case and specification — unless Quartus timing and board SI confirm it's safe.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Ok, thanks again Kenny.
I am still not convinced about the rationale for the minimum period restriction, and hence the restricted Fmax that is reported to me, since the bench tests I did with my simple clock divider showed a maximum frequency possible (for this particular sample, in this particular environment) that was clearly higher than the reported Fmax = 1071 MHz, while the restricted Fmax was reported only at 402 MHz.
But we might have reached the end of this discussion here, which sorted out some misunderstandings. I am grateful for all help and comments.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks,
The restricted Fmax reported by Quartus is always based on worst-case silicon, voltage, and temperature corners. It’s a safe, guaranteed number to ensure reliable, repeatable operation across any production device, over temperature, process variations, and voltage shifts. Your specific part on the bench might be a very fast sample at room temperature, with clean power rails and excellent signal integrity — which is why you're seeing it exceed the spec.
But Altera (and any FPGA vendor) has to spec for the slowest, hottest, lowest-voltage corner case device — not the best-case one on your desk.
The minimum period restriction is often tied to internal clock tree delay balance, LE register switching performance, and clock pulse width requirements. Even if your simple clock divider logic is fine, the global clock network and clock control blocks are spec’d to a conservative value to avoid marginal operation in less ideal scenarios.
You’re right — your testing showed impressive margins. But production designs, especially in safety-critical or industrial environments, need to lean on the datasheet limits for reliable, field-safe operation.
You’ve really helped clarify and close the loop on a tricky subject — and it was a pleasure following your methodical, evidence-backed investigation!
Per your request, I now transition this thread to community support. If you have a new question, Please login to ‘https://supporttickets.intel.com/s/?language=en_US’, view details of the desire request, and post a feed/response within the next 15 days to allow me to continue to support you. After 15 days, this thread will be transitioned to community support. The community users will be able to help you on your follow-up questions.

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- « Previous
-
- 1
- 2
- Next »