Assistance Required: Persistent Oscillation Issues on MAX10 LVDS Receiver Inputs

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

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

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.

Hi,

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

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