Restricted Fmax due to minimum period

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

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

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.

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.

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?

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!

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

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.

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.

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.