DCLK and DATA0 connected to LVDS output instead of floating

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

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

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.

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

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

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.

--- Quote Start ---

The whole hardware design approach here is not going to work :)

First thing that you'll experience is sporadic remote FPGA reconfigurations due to noise pickup on 100 m nCONFIG line.

--- Quote End ---

This is likely, even if nCONFIG is a dedicated LVDS twisted pair?

--- Quote Start ---

As to ESD then "human body model" is just one of the several ESD model. There is a "machine model" and most important for you - "cable discharge model" (http://www.national.com/an/an/an-1511.pdf). They differ greatly in the ESD power they can apply to you circuit (e.g 15kV "human" is not equivalent to 15 kV "cable").

--- Quote End ---

I realise(d) that already, however, AFAICS the ESD specs for buffers seem to increase for both values when the human body model value increases. I figured, that the best I could do, was find a buffer IC that has the highest values for the human body model, and that will automatically make it the most robust for the machine model (albeit with lower absolute values than for the human body model). And considering that, the best buffer ICs I could find offer 15kV human body model of ESD protection, which translates into a lot less in the machine model, but since they're the best I can find, what else can I do? Hmmm, I see that the reference you provided outlines some of the other protective measures I can take. Interesting read, thanks.

--- Quote Start ---

You'd need a reliable way to configure remote FPGA. You might add a small flash-based micricontroller on the remote side with LVDS-to-LVTTL buffers, send FPGA configuration data to MCU over LVDS with some CRC. And then MCU configures FPGA.

--- Quote End ---

If a 100m LVDS driven nCONFIG twisted pair is going to be prone to occasional transients which are going to cause it to misread as a spurious undesired low level, then the most likely alternative is that I use a flashrom for FGPAremote as well, and then program the flashrom from inside the FPGAremote if I need to adjust the programming/logic (yes, I know that makes me vulnerable to powerloss during reprogramming, but that is an acceptable risk).