Assistance Required: Persistent Oscillation Issues on MAX10 LVDS Receiver Inputs

[Sungjin]

Hello,

I'm currently working with an Intel MAX10 device configured with a 10-lane LVDS interface.
However, I’ve been struggling with persistent oscillations occurring at the LVDS receiver inputs.

As you may know, LVDS interfaces are expected to incorporate fail-safe mechanisms to ensure a stable logic state, especially during initial power-up or when the bus is undriven. Ideally, the fail-safe design should suppress undefined behavior due to floating inputs.

In theory, a small differential voltage should be interpreted as a logic low (e.g., below 100–150 mV), which helps prevent oscillations. This type of fail-safe behavior seems appropriate for the MAX10 device, particularly when the input buffer treats minor voltage fluctuations as logical '0'. And My current design is configured to follow this fail-safe behavior, where small differential voltages (under ~150 mV) are treated as logic low by the LVDS input buffer.

Despite applying various I/O standard and pin-related configurations, the unwanted oscillations persist. I suspect that either the fail-safe circuit isn't behaving as expected, or the receiver termination and common-mode bias conditions may not be optimal.

Could you provide guidance or recommendations on how to eliminate these oscillations? Any insight into proper LVDS input configuration or related Quartus settings would be greatly appreciated.

Thank you.

[FvM]

Hi,
I'm not aware of a any kind of fail-safe mechanism specified for LVDS inputs of Altera FPGA neither MAX10 nor other types.

MAX10 Table 25. Differential I/O Standards Specifications for Intel MAX 10 Devices specifies a minimal differential voltage Vid of 100 mV and a common mode range. Receiver state for Vid between +/- 100 mV is undefined.

According to TIA PN-4584, failsafe operation means are optional and not covered by the standard:

4.4.2 Failsafe operation
Other standards and specifications using the electrical characteristics of the LVDS interface circuit may require that specific interchange circuits be made failsafe to certain fault conditions. Such fault conditions may include one or more of the following:
1) generator in power-off condition
2) receiver not connected with the generator
3) open-circuited interconnecting cable
4) short-circuited interconnecting cable
5) input signal to the load remaining within the transition region (±100 mV) for an abnormal period of time (application dependent)
When detection of one or more of the above fault conditions is required by specified applications, additional provisions are required in the load and the following items must be determined and specified:
1) which interchange circuits require fault detection
2) what faults must be detected
3) what action must be taken when a fault is detected; the binary state that the receiver assumes
4) what is done does not violate this Standard
The method of detection of fault conditions is application dependent and is therefore not further specified as it is beyond the scope of this Standard.

Please correct me if you know different specifications for Altera FPGA.

Fail safe behaviour is implemented with some RS485 receivers on the market, but it typically doesn't work for terminated inputs. In case of LVDS, we usually implement detection of floating/unconnected inputs on higher protocol levels.

Regards
Frank

[Sungjin]

Thank you, Frank.

It was my mistake to assume that the MAX 10 device includes an internal fail-safe function.

I apologize for the incorrect information.

That said, I still have a practical issue to resolve.

According to the MAX 10 documentation, floating LVDS inputs require biasing,

but aside from the standard 100-ohm termination resistor, no specific bias resistor values are given.

As a rule of thumb, a <10kΩ – 100Ω – 10kΩ> biasing network can often be used to provide fail-safe behavior in many cases.

And using pull-up or pull-down resistors below 10kΩ is generally not recommended, as it may result in excessive current flow.

So, In our setup, this network creates only about a 10 mV voltage difference between the positive and negative LVDS inputs,

which may not be sufficient to establish a clear logic state.

Conclusion : When designing a practical fail-safe circuit, we must consider the risk of malfunction, even after fail-safe biasing.

Is this resonable conclusion? Please correct me if I'm misunderstood.

[FvM · Accepted solution]

Hi,
I believe the answer is implementation dependent. Adding a DC bias to enforce a 0 or 1 level for floating LVDS inputs would reduce performance, e.g. increase minimal signal level and add an asymmetrical time shift of input signal, reducing effective skew margin. Both effects reduce maximal cable length. Common mode bias is required in AC coupled input circuit, but differential bias is rarely applicable for high speed differential signaling.

When receiving an open LVDS input signal with 10b8b decoder, we still get a certain rate of false correct frames. An additional time filter detects stable input signal.

[JohnT_Intel]

Hi,

May I know what is the LVDS speed are you running and the oscillation noise that is observed in your design?

[Sungjin]

Thank you for your follow-up.

I have configured the interface as a bidirectional LVDS bus operating at 80 MHz. To support this, the design includes termination resistors at both ends of the bus for proper signal integrity.

As for the oscillation observed:
It manifests as white noise-like behavior on the LVDS receiver inputs. Importantly, this oscillation only occurs before the LVDS driver becomes active—specifically, during the idle state prior to any valid signal transmission.

The protocol implemented includes a synchronization code at the start of each packet, and the receiver performs multiple checks to detect it. However, due to the random timing introduced by this pre-driver oscillation, the sync code is often missed or misaligned, affecting packet recognition and initial link stability.

Please let me know if any further clarification is needed. I would appreciate any guidance or recommendations to mitigate this behavior.

Best regards, Sung-jin

[FvM]

Hi,
the problem description is pretty clear, I think. There's however no general solution, it has to be taylored to your system.

As already stated, there's no fail-safe feature for LVDS receivers. For relative low speed of 80 MSPS, dc bias to a defined idle state (LVDS as such has no defined idle state) can be a solution. If communication time budget allows, a longer preamble can also help.

Regards

Frank