Camera Link - FPGA I/O protection

IMHO, a sacrificial buffer is the wrong way to go. Yes, you protect the FPGA but then you'll be replacing your buffer often too..

If ESD is important, you should implement proper ESD protection instead.

As jvov suggested, there are ESD protection devices for popular protocols which may fit your needs.

If that doesn't work out, you can just add in your own ESD protection circuitry, using discrete diodes.

Regardless wether you use ESD protection or not:

I would never ever interface the Higher-Level-System directly from the FPGA.

You'll never know what you've to handle with.

Just my 2 cents...

--- Quote Start ---

Regardless wether you use ESD protection or not:

I would never ever interface the Higher-Level-System directly from the FPGA.

You'll never know what you've to handle with.

Just my 2 cents...

--- Quote End ---

I have the exact same concerns about driving the Cameralink directly from FPGA. First, from an ESD point of view and second, for driver strength.

ESD can be managed but buffering requires expansive components with high current consumption so avoiding this would be ideal...

So I'm curious, what did you finally do?

--- Quote Start ---

For a new desing I am planning to implement the Deserializer for CamerLink in the FPGA to replace the Deserializer chip. To protect the FPGA I/O's (ESD) I thought to place a "sacrificial" LVDS buffer between CameraLink connector and FPGA. But the "sacrificial" buffers need more space on the board and they are more expensive then the Deserializer.

Another option is to do it without the "sacrificial" buffer. What is your opinion about this? How well are the FPGA (Cyclone IV) I/O's protect against ESD damage. Is there any other way to protect the FPGA I/O's for damage?

Your opinion is highly appriciated.

--- Quote End ---

I have an issue with Cyclone IV directly driving a Cameralink video, it is extremely vulnerable, the failure rate is very high. My previous board was based on Cyclone II and it NEVER failed!