Restricted Fmax due to minimum period

[Daniel99]

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?

[Kenny_Tan]

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.

[Daniel99]

Thank you very much.

But it still leaves my question about why I do not see the 500 MHz listed in clock tree table for the C6 device.

In any case, my design uses nothing but an LVDS input pin, a CMOS output (at lower frequency) and two LEs with ordinary flip-flop logic. Restricted Fmax is reported due to  "minimum period restriction" and the "Timing Closure Recommendation" presents an empty list of "Top Failing Paths".

Would I then, in this case, be safe to ignore the restricted Fmax and clock at 500 MHz (or higher)?

[Kenny_Tan]

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

[Daniel99]

Of course. It is a very simple design just to test this. Hereby attached.

I can add that my main goal is to be able to feed a 500 MHz clock into the FPGA and directly divide it down to a lower frequency. I don't really intend to clock anything else than a divider at this high rate.

Thanks.

[Kenny_Tan]

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.

[Kenny_Tan]

Design is attached

[Kenny_Tan]

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.

[Daniel99]

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!

[Daniel99]

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?

[Daniel99]

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(?)

[Kenny_Tan]

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

[Daniel99]

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...

[FvM]

Hi,
there seems to be a misunderstanding in your comparison of Cyclone 10 LP datasheet table 19 (max. LVDS data rate) and table 20 (clock tree performance). Table 19 specifies data rate in Mbps, table 20 clock frequency in MHz. Date rate of a LVDS signal is however double the signal frequency. E.g. a LVDS (double data rate) signal with 500 Mbps maximal toggle rate appears as 250 MHz square wave.

Clock tree performance and specifically minimal clock pulse width has nothing to do with IO speed, it's ruled by LE register switching behaviour. You might be able to clock your design above restricted Fmax, but it's not guaranteed to work.

Regards

Frank

Additional comment. Timing analysis tells you if restricted Fmax is caused by I/O "(max IO toggle rate)" or core logic speed "(tmin)".

[Daniel99]

Sorry, my mistake, I meant to say:

"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 29 and not from table 19."

But if table 19 assumes double-data-rate for LVDS and LVPECL it is a pity that this is not mentioned.

Frank, you say "Timing analysis tells you if restricted Fmax is caused by I/O "(max IO toggle rate)" or core logic speed "(tmin)" but for my design it is reported as "Restricted Fmax due to minimum period (tmin)" and not I/O toggle rate, and from Kennys comments it is clear that the restricted Fmax I get is in fact due to LVDS frequency limitations as stated in table 29, and not from table 20 about Clock tree performance, even though reported as (tmin).

[FvM]

Hi,
restricted Fmax (tmin) refers to core clock limitation as far as I see. You can check by testwise selecting C6 speed grade, timing analysis reports  I/O related Fmax then.

There is no voltage swing dependance specified in table 19, just common voltage depedendance.

Table 19 doesn't specifically assume double data rate, you however need double data rate input registers to process data rates up to 700 Mbps.

[Kenny_Tan]

Apologize for the confusion earlier!

Regarding the clock tree and restricted Fmax:

Frank absolutely right that restricted Fmax is tied to the clock pulse width limitations, and this is primarily influenced by the LE register switching behavior (how fast the FPGA can reliably process and latch clock signals, not the IO performance).

So, the timing constraint you see (due to restricted Fmax) is actually an issue of how fast the registers can be reliably triggered by the clock signal, not the speed of the IO signal itself.

Frank is also right on: restricted Fmax (tmin) refers to the core logic's clock pulse width limitation and not the I/O path. It’s about the minimum period required for registers, not the I/O toggle rate. Running a timing analysis with the C6 speed grade will reveal I/O-related Fmax separately.

Table 19 provides maximum data rates for I/O standards like LVDS but doesn’t consider voltage swing. The voltage swing does not directly affect the max data rate; it’s more about signal integrity and ensuring compliance with the I/O standard.

For LVDS data rates up to 700 Mbps, you need DDR input registers to process both rising and falling clock edges, which is crucial for double-data-rate signaling.

[Kenny_Tan]

Probably, some sample of verilog code will help:

module lvds_ddr_in (

  input wire lvds_clk,  // 250 MHz clock

  input wire lvds_data,  // 500 Mbps LVDS data

  output reg data_rise,  // Data sampled on rising edge

  output reg data_fall  // Data sampled on falling edge

);

  always @(posedge lvds_clk)

    data_rise <= lvds_data;

  always @(negedge lvds_clk)

    data_fall <= lvds_data;

endmodule

lvds_data must be assigned to a pin with IOSTANDARD "LVDS" in your .qsf:

set_location_assignment PIN_A1 -to lvds_data

set_instance_assignment -name IO_STANDARD "LVDS" -to lvds_data

lvds_clk should be the recovered clock or forwarded clock — also through an LVDS pair if needed.

To combine data_rise and data_fall into a parallel word (deserialization), shift them into a register array at the system clock domain.

1:4 Deserializer Example

module lvds_ddr_4bit_in (

  input wire lvds_clk,   // 250 MHz clock

  input wire lvds_data,

  output reg [3:0] parallel_data

);

  reg [3:0] shift_reg;

  always @(posedge lvds_clk) begin

    shift_reg[3:2] <= {shift_reg[1:0]};

    shift_reg[1]  <= lvds_data;

  end

  always @(negedge lvds_clk) begin

    shift_reg[0]  <= lvds_data;

    parallel_data <= shift_reg;

  end

endmodule

• parallel_data will now hold 4 bits of deserialized data every clock cycle.

[Daniel99]

Thank you again Kenny and Frank.

There is definitely some confusion here and I also realize I have misunderstood table 19.

But if we are now back to that the restricted Fmax I see with my 500 MHz clock is not due to LVDS speed limitation but due to a minimum period for the LE blocks, I would like to revert to my first question: Why do I get 438 MHz for C6 and not the 500 MHz stated in table 20?

What is the definition of Clock tree performance, in table 20?

[Daniel99]

I felt it was time to do some tests on the bench.

I hooked up an RF signal generator and a spectrum analyzer to a 10CL006 in C8 grade that I had on a PCB from an earlier project. By first using an LVCMOS (clock) input pin for my design with a divide by four block and an LVCMOS output, I could give it my 500 MHz and see a nice 125 MHz coming out.

In fact, I could go above 1.2 GHz (!), and still see it dividing by four without any problems. The limitation here mostly seemed to be the CMOS input sensitivity since I could not get a nice CMOS square wave but had an AC coupled sine biased at 1.2V.

When changing the input to LVDS it got much more sensitive and I could now give it almost exactly 2000 MHz before the logic failed and started to give me a frequency out that differed from the input divided by four.

Really impressing!

[Kenny_Tan]

I don't think you can refer to the table for restricted fmax.

Here is the definition:

Restricted Fmax considers hold timing in addition to setup timing, as

well as minimum pulse and minimum period restrictions. Similar to

unrestricted Fmax, the restricted Fmax is computed as if the rising

and falling edges of the clock are scaled along with Fmax, such that

the duty cycle (in terms of a percentage) is maintained. Refer to

hold timing reports (e.g., report_timing with the -hold option) or

minimum pulse width reports (report_min_pulse_width) for details about

specific paths, registers, or ports.

The report still doesn't show which nodes are causing the violation, but the help says to use

report_timing -hold

or

report_min_pulse_width