Problem with floating inputs on LVDS ports

Well, what do you expect them to give you? If they are not connected, and neither pulled to ground nor to VCC, you get something in between, and that depends on the temperature, humidity, moon phase, your karma, whatever... That's why it's called "floating", because the input floats somewhere in between. Most of the time somewhere around the middle exactly where the decision threshold between 0 and 1 is, so sometimes you get 0, other times you get 1, which translates to garbage.

As the warning states, if you do attach PULLUP or PULLDOWN primitives, this might affect signal integrity. You might be OK with that, or it might screw up your data, that's for you to decide. As you know, the differential termination won't resolve the issue with the floating inputs. So, pullups/-downs might be a solution, but only if it doesn't affect signal integrity too much, which it seems to do in yout case (since you still get garbage sometimes despite of the pullups).

Yes, ignore everything you get from floating inputs.

HTH, Sean

--
My email address is only valid until the end of the month.
Try figuring out what the address is going to be after that...

Sorry, inaccurate information from my part. When I leave all ports unconnected (no cables attached) 1 out of 8 channels still receives garbage. When I connect cables from one port to another data-transmission seems to be in order (2 of to 2 words received, 100% signal integrity :) I need more statistics on this).

Easier said then done. The final design will have 120 serial channels. Received data words from each channel will be stored in a shared memory so I need to filter out the garbage words before I store them.

I am well aware of the problem that a floating input acts like an antenna. (At least I am now :) Since pullups and pulldowns are not an ideal solution, I was hoping there might be a way to detect an unconnected port/input and disable this channel. I see that in my original post, I left out some vital information; The lvds lines are used for serial data transmission over cat5 TP cables. Non-Return-to-Zero encoding with 4 cycles per bit, 32 bit words, 2 start bits, one parity bit and one stop bit. When the lines are idle the transmitters should hold the lines high (when looking at the single-ended signals from my IBUFDS/OBUFDS). The situation now is that, if by chance, a floating input stays low for

4 cycles and high for the 4 next, I start sampling for data bits. Of course I can discard words with stop bit error and/or parity errors but this method is not bullet-proof. Maybe I should try to make a more demanding/critical start condition? I will try to experiment a bit or two. As you say, these are design considerations I will have to make myself. I was thinking that this might be a common problem with a good solution but I can't find any discussions/articles about it on the Xilinx website. Thats why I made this thread. If anyone have some experience to share with me I'd be grateful.

It may be possible to fix this inside the FPGA if you can add a pullup to the positive input and a pulldown to the negative input of each pair. Even then, I wouldn't count on this arrangement working well due to the relatively low value of the differential termination resistor and the resulting very low voltage created by the weak pullup/pulldown pair (assuming the P&R tools really place these components).

Another approach is to add external pullup/pulldown resistors to bias the signals when disconnected (also not optimal). There are LVDS receiver devices that have guaranteed outputs when the inputs are floating. They do this by sensing that the common mode input voltage is above the high limit (there is an internal pullup to create this CM voltage when the inputs float). The FPGA could do this with an additional I/O attached to one of the LVDS pair, but if you're trying to run too fast you'll have issues with the unbalanced capacitive loading.

So probably the best way to avoid this mess is to use a protocol with guaranteed AC and DC characteristics like 8B-10B. You can then easily detect error conditions and disable the disconnected links.

Regards, Gabor

Xilinx's pullups/pulldowns are quite high impedance, and with the receiver terminated at low impedance, they won't change the differential voltage beyond the transition region. You'll only get a millivolt or so difference with the pullup/pulldown turned on. You will need to install EXTERNAL pullups and pulldowns of low enough resistance to pull the lines well enough away from differential zero to keep the level translator from switching. It will take at least half a mA, I think.

Jon

Thanks Gabor. I've looked into the 8B-10B encoding that you suggested. It is not likely I will have time to implement this but I would like to say something about it in my master thesis. You say that it is easy to detect error conditions and I have tried to figure out how this can be done. When you mention AC and DC characteristics I assume you are thinking of that each encoded 10-bit word would contain 5 zeroes and 5 ones. So if I count the number of ones and zeroes over an interval and see a signicant difference in numbers then this would indicate a floating input? Or should I simply look for invalid 10-bit words? Words that would not be part of the alphabet for this encoding scheme. Can you please let me know if I got this right?

Valid words have no more than 6 1's or 0's. That is DC is maintained

+/- 1 count. In addition, any word that is not 5 1's and 5 0's has two versions, one with 6 1's, the other with 6 0's. Thus any long- term DC unbalance is avoided by using the appropriate version of the word to prevent the DC component from going more negative or positive than +/- 1. This is something you can check for validity.

AC component of the input signal is also maintained. Other than the escape codes, you should never get more than 4 1's or 0's in a row. Thus if your inputs oscillate much slower than your bit rate, you can detect code errors by counting adjacent 1's or 0's.

Invalid 10-bit words is an easy starting point. Typically you'd use a state machine that detects lock when it receives a particular code, usually K28.5 if memory serves me correctly. Then you might allow 1 or 2 bad codes before deciding you've lost lock and wait for the next escape character. You never mentioned your bit rate. If you're not running too fast you may have other options, like detecting non- integral bit periods, etc. If you're running as fast as the I/O can go, you get another benefit from the 8b-10b code of carrying the clock information on your data pair. However clock recovery in an FPGA is not easy if you need to use fabric resources rather than built-in SERDES I/O blocks.