DCLK and DATA0 connected to LVDS output instead of floating

[Altera_Forum]

The Cyclone II handbook says that after programming, the DCLK and DATA0 inputs should not be left floating and should therefore be connected to a logic high or low. 

However, it also states that the inputs are Schmitt-trigger gated.  So, what if, after programming, I connect the DCLK and DATA0 inputs to the respectively positive and negative output of an LVDS line? That does keep them from floating, but it also doesn't present a clear low or high; then again, the schmitt-trigger input should be happy with this; or is it?

[Altera_Forum]

Well, as long as remote FPGA can handle unexpected behavior on the cable it's fine. Using a configuration flash for remote FPGA side is a valid idea. 

 The thing with LVDS is that it's not a panacea for nCONFIG, it's better than LVTTL but it still will pickup poise on 100 m cable. The problem is that just a single spike on it will invalidate current remote FPGA configuration.

[Altera_Forum]

--- Quote Start ---  The thing with LVDS is that it's not a panacea for nCONFIG, it's better than LVTTL but it still will pickup poise on 100 m cable. The problem is that just a single spike on it will invalidate current remote FPGA configuration.  --- Quote End ---   Ok, I indeed had hoped that LVDS would be the panacea; but as I understand, even LVDS is susceptible to occasional misreads. Reconsidering, then the best alternative would seem to be the remote flashrom, and on the UTP cable, to reuse the former nCONFIG pair as an extra GND and PWR pair (although that makes me wonder if I then don't make myself vulnerable to unpaired currents through the powerlines).

[Altera_Forum]

After reconsidering my options, I conclude that I've almost come full circle. The best solution seems to be the extra flashrom on FPGAremote, and to ditch the Ti buffer chips, instead connect the (now) two LVDS pairs of the FPGA directly to the RJ-45, but add a Cooper Bussman 41206ESDA for surge protection (reactiontime <1ns), which is cheaper to boot (the buffer chips were more expensive).

[Altera_Forum]

Well, I'd still recommend keeping buffers, but if the price is of greater concern then at least make sure FPGA LVDS buffers can drive 100 m UTP cable.

[Altera_Forum]

--- Quote Start ---  at least make sure FPGA LVDS buffers can drive 100 m UTP cable  --- Quote End ---   They surely can as long the cable is correctly terminated. The more interesting question is however, if the data can be received correctly at the other end. "Long distance" cable drivers are partly using preemphasis to precompensate for the cable losses, also the ability of a dedicated LVDS receiver to decode attenuated signals has been improved with some types.  Did you try a test setup with 100m CAT5 cable? The nominal CAT5 - CAT7 attenuation is 13 dB/100m @ 16 MHz and 18 dB @ 32 MHz, making it unlikely to operate a 32 MBPS LVDS link successfully without additional signal gain and an equalizer compensating the cable loss.

[Altera_Forum]

There is a valid reason why some components are called 'interface circuits' and others just 'logic'. Going over a cable definitely is an 'interface' job. 

You could add a small MAXII to decode configuration messages giving you remote configuration back.

[Altera_Forum]

--- Quote Start ---  They surely can as long the cable is correctly terminated. The more interesting question is however, if the data can be received correctly at the other end. "Long distance" cable drivers are partly using preemphasis to precompensate for the cable losses, also the ability of a dedicated LVDS receiver to decode attenuated signals has been improved with some types.  --- Quote End ---   Valid point(s). The upside here is that I can still change the spec of the product. I.e. looking at a page like http://www.interfacebus.com/design_connector_lvds.html I notice that they figure that the maximum length for 32Mbps seems to be something like 70m.   --- Quote Start ---   Did you try a test setup with 100m CAT5 cable? The nominal CAT5 - CAT7 attenuation is 13 dB/100m @ 16 MHz and 18 dB @ 32 MHz, making it unlikely to operate a 32 MBPS LVDS link successfully without additional signal gain and an equalizer compensating the cable loss.  --- Quote End ---   Pondering... 32Mbps means a maximum line-toggling rate of 16MHz block-wave (1010 pattern). So the line attenuation I need to consider most likely is 13dB/100m as opposed to 18dB. In my case it probably is admissible to simply connect the FPGAs directly (with external 1ns delay-150V clamp surge protector) and then determine the specs afterward by measuring the results. If it is 100m, it's fine, if it's 50m it's still ok, but most likely it will be somewhere around 70m. Except for possibly some extra meters, using extra external buffers does not seem to be to buying me extra reliability/advantages (keep in mind: I don't care what breaks, I only care about the (un)likelihood that something breaks).

[Altera_Forum]

--- Quote Start ---  There is a valid reason why some components are called 'interface circuits' and others just 'logic'. Going over a cable definitely is an 'interface' job.  --- Quote End ---   It all depends on electrical specs, and it doesn't seem that builtin Cyclone II's LVDS buffers are so bad after all (except for the too low ESD values).   --- Quote Start ---   You could add a small MAXII to decode configuration messages giving you remote configuration back.  --- Quote End ---   The MAXII doesn't do LVDS, so I'd need buffers again, besides the MAXII is a considerable extra cost. I still have remote reconfiguration, albeit indirectly by reprogramming the flashrom through the same active/booted FPGAremote.

[Altera_Forum]

It would definitely be useful to perform a test before implementing it into device. Or perform a signal integrity simulation (e.g. in HyperLynx)