DCLK and DATA0 connected to LVDS output instead of floating

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

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

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

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.

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

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

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.

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

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

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