DCLK and DATA0 connected to LVDS output instead of floating

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.

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

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

So what I'll do now is skip the LVDS on the FPGA and simply use LVTTL to/from the buffers.

--- Quote End ---

A much more safe solution, I think.

--- Quote Start ---

Part of this can be solved (in my case) by instructing the installer not to powerup the main unit until the remote unit has been plugged in.

--- Quote End ---

Simply consider that people (and particularly hasty service guys) use to hot-plug any connector, that you won't even think of. Unfortunately, they don't confess, just return a device "defective on arrival". It can be really reassuring to make the device hot-plug capable, if ever possible.

--- Quote Start ---

One (curious) question: how many circuits are you going to build? Tens or thousands?

--- Quote End ---

A production run of 1000 to 4000 (depending on how well they perform).

--- Quote Start ---

If you insert a 'live' RJ45 connector into its mating socket the sequence of making contact is undefined. Sometimes the Vcc makes and some signals make contact before the Gnd finally gets there. Some circuits do not survive this 'game of Russian roulette'.

--- Quote End ---

Good point. Part of this can be solved (in my case) by instructing the installer not to powerup the main unit until the remote unit has been plugged in.

--- Quote Start ---

The termination could be the Achilles' Heel. The slow slew on the TTL outputs may not be enough to get rid of reflections on the Dclk and Data0. If it turns out to be enough they represent a significant resistance of 50 ohm (or more). These resistances in combination with the mandatory 100 ohm termination to receive LVDS later will eat heavily into the signal swing of the TTL outputs. To quote Einstein: "Everything should be made as simple as possible, but not simpler."

Do you need 32 MHz signalling rate towards FPGAremote?

--- Quote End ---

Well, I need 8MHz datarate, 32MHz is a tad bit higher than the minimum. So lowering that would still be an option (a bit).

However, I shopped around for some LVDS drivers/receivers, and eventually found: SN65LVDS391 and SN65LVDT390 from Texas Instruments. They offer >15kV ESD protection, which is significantly higher than the 1kV of the standard Cyclone II protection.

So what I'll do now is skip the LVDS on the FPGA and simply use LVTTL to/from the buffers. This automatically solves the DATA0/DCLK/nCONFIG issues, since I connect them over three pairs, through LVDS, through the buffers.

One (curious) question: how many circuits are you going to build? Tens or thousands?

A construction on a roof is exposed to more 'lightning' than one thinks.

If you insert a 'live' RJ45 connector into its mating socket the sequence of making contact is undefined. Sometimes the Vcc makes and some signals make contact before the Gnd finally gets there. Some circuits do not survive this 'game of Russian roulette'.

The termination could be the Achilles' Heel. The slow slew on the TTL outputs may not be enough to get rid of reflections on the Dclk and Data0. If it turns out to be enough they represent a significant resistance of 50 ohm (or more). These resistances in combination with the mandatory 100 ohm termination to receive LVDS later will eat heavily into the signal swing of the TTL outputs. To quote Einstein: "Everything should be made as simple as possible, but not simpler."

Do you need 32 MHz signalling rate towards FPGAremote?

--- Quote Start ---

I'm not sure whether the external LVDS chips will be stronger, and as you are using the smallest EP2C devices you may as well give it a try.

--- Quote End ---

I digged into it some further, and it appears that the Cyclone II is capable of taking a 1kV discharge by human touch. Comparing that to some of the dedicated buffers which are typically 2kV/4kV/8kV, I'm wondering if it will make a large difference in my case. The equipment is usually installed once, the main part will be indoors, the remote part will be outdoors on the roof in an isolated plastic box connected to just this single RJ45 which also supplies power. The 1kV provided by the Cyclone II might be enough.

--- Quote Start ---

To reduce the chance of breaking things you have to add additional protection devices as well.

--- Quote End ---

Like? The circuit does not have to survive a direct lightning hit.

--- Quote Start ---

Also you must protect the circuit from false cureent supply loops while hotplugging the system (this if you are using RJ45 connectors, or in fact almost any connector).

--- Quote End ---

I understand what you mean, but I have to admit that I lack the experience to readily know where it would apply to my RJ45 signals. Could you give an example?

--- Quote Start ---

Did you think about the termination of the mixed LVDS-LVCMOS pair? You may run into an incompatibility there.

--- Quote End ---

Well, that basically is solved (I think), because I use the LVDS termination and simply make sure that the slewrate for the configuration signals is slow enough and low frequency enough to survive the wrong termination.

--- Quote Start ---

Is a Cyclone II more likely to break due to spikes than some kind of dedicated LVDS driverchip?

--- Quote End ---

I think it is. A lot of LVDS interface chips have specified ESD strength in contrast to the FPGA.

I personally prefer isolation by ethernet transformers for external LVDS interfaces, but it's involving additional effort for a DC balanced physical layer.

I'm not sure whether the external LVDS chips will be stronger, and as you are using the smallest EP2C devices you may as well give it a try.

To reduce the chance of breaking things you have to add additional protection devices as well.

Also you must protect the circuit from false cureent supply loops while hotplugging the system (this if you are using RJ45 connectors, or in fact almost any connector).

Did you think about the termination of the mixed LVDS-LVCMOS pair? You may run into an incompatibility there.

--- Quote Start ---

I personally wouldn't connect a cable directly to a FPGA. Any disturbance on the cable could kill off the FPGA(s).

The direct connection to config_n may/will be vulnerable to disturbances as well.

--- Quote End ---

Is a Cyclone II more likely to break due to spikes than some kind of dedicated LVDS driverchip?

Meaning: since I'm using the cheapest Cyclone II chips (EP2C5), there is no concern that an expensive chip might break. The only concern is that something breaks. So if the probabilty that something breaks can be significantly reduced by using driverchips between the FPGA and the CAT5, then that is what I'll do.

As for vulnerability of the nCONFIG line, I was meaning to put a pull-up resistor on it to 3.3V at both ends of the line, to make sure that it never spikes down to zero and causes a spurious reconfig.

[Addition]

I already looked it up, and notice that the ESD protection offered by dedicated LVDS buffer chips is a lot higher than that what the FPGA offers (if any). I'll redesign and use LVDS buffers/converters, which kind of automatically solves my problem with the LVDS connected to the FPGA (it won't be, anymore).

100 m over CAT5 is different ballgame than what I had visualised.

I personally wouldn't connect a cable directly to a FPGA. Any disturbance on the cable could kill off the FPGA(s).

The direct connection to config_n may/will be vulnerable to disturbances as well.

My suggestion is to do everything in LVDS using external drivers/receivers. To make up for the missing signals you could add a MAXII to (safely) decode the configuration from the 2nd incoming LVDS line.

--- Quote Start ---

One more observation is that at the end of the configuration of FPGAremote this may possibly start sending data on the LVDS outputs before you can tristate the TTL outputs on FPGA main, possibly disrupting the configuration.

Why not use 2 more wires between FPGAmain and FPGAremote?

Or use LVCMOS differential signalling instead of LVDS (saving 2 pins on FPGAmain as well)?

--- Quote End ---

Well, for one, I know exactly in FPGAmain when the config data is complete, so I can switch to tristate well before FPGAremote has finished its boot-process.

As for two more wires, yes, I wish...

The connection that I have between main and remote is a CAT-5 cable with 4 wirepairs.

One wirepair is used for GND/18V (the powerlines).

One wirepair is used for LVDS communication from FPGAmain to FPGAremote.

One wirepair is used for LVDS communication from FPGAremote to FPGAmain (and doubles as DCLK/DATA0 during the configuration stage).

One wire is used for nCONFIG to FPGAremote.

One wire is unused (but will probably be connected to GND).

So, in short, I don't have the two extra wires (I have one, but that doesn't solve the problem). Unless someone has a clever idea on how to solve this differently given the CAT5 constraint.

As for using LVCMOS hand-made differential signaling. That would be an option, I guess. But I'd like to communicate over CAT5 wires up to a 100m with 32MHz, so real LVDS would be better, I think.