# Transceivers in the field of FPGAs: When and why will we use them?

I am recently getting myself into the field of FPGA design and development, and lately I've found myself hearing a lot about transceivers. I tried searching the net for some answers about these components and learn their role in the world of FPGAs but could not find much information but a few articles related to serial communications and Ser/Des's...

I wanted to ask, why, when, and most importantly how will I use transceivers on FPGAs? What are their alternatives (if any exist)? Is there some kind of a thumb rule for transceivers usage? And how can I "harness" all of that transceiving good to my advantage?

• what's the good of a super fast FPGA, able to crunch logic like a boss, without being able to tell the world outside about it's results? Transceivers sound like communications of various types, either parallel or serial, maybe with differential drivers or ethernet etc. Could be any numerous things, and people perhaps refer to them broadly as transceivers.. – KyranF Oct 7 '14 at 8:05
• @KyranF The asker probably means "high-speed serial transceivers". – mng Oct 7 '14 at 21:18
• @mng transceivers do not need to be serial at all, and the asker themself did not know what it was – KyranF Oct 7 '14 at 21:29
• But in the context of features advertised by FPGA manufacturers, 'transceiver' almost invariably means dedicated hardware for high speed (multiple Gbps) serial comms supporting a variety of wire-level protocols and [de]serialization schemes. – pericynthion Oct 7 '14 at 22:08

You need to use a transceiver when you want to bring out high speed signals from inside the FPGA and interface with the real world.

Typical examples are to communicate with other high speed parts on the same board (for example another FPGA or ADC) or to interface off board (for example using PCI, HDMI or ethernet).

In order to send these high speed signals correctly there are a number of encoding and electrical considerations. Perhaps it is necessary to remove DC bias, for example using some form of symbol encoding (e.g. 8b/10b). Maybe the communication channel uses differential pairs to accurately send high speed data across a wire. FPGA manufacturers build in flexible transceivers to do this work, saving you the effort.

For example, the Spartan 6 LXT contains what Xilinx call a "3.2Gbps GTP transceiver". Their literature says:

• Implement serial protocols at lowest power
• Devices contain up to 8 gigabit transceiver circuits
• Up to 3.2Gbps performance
• High speed interfaces: Serial ATA, Aurora, 1G Ethernet, PCI Express, OBSAI, CPRI, EPON, GPON, DisplayPort, and XAUI
• Lower power consumption: < 150mW (typical) at 3.2Gbps

That's a lot of high speed interfaces which can be achieved using the transceivers.

You could implement a lot of this on your own and in older/smaller/cheaper FPGAs this is often the only way. However you soon run into problems designing logic that will run fast enough to keep up and you will require a lot of external components for the electrical interface.

Unfortunately with many modern interfaces the normal FPGA I/O pins simply don't run fast enough to achieve the high data rates required.

So in summary, the benefits of internal transceivers are:

• Encoding mechanisms don't take up FPGA resources and can run at a guaranteed high speed (no need to compromise other parts of your design to keep timing constraints).
• Electrical interfaces are handled for you with minimum external parts.
• Implementation of extremely complicated interfaces (e.g. PCI Express) is done for you and (if appropriate) certified.
• Dedicated silicon will (probably) use lower power than other blocks within the FPGA.

• You could implement a lot of this on your own  - that's not really true in most practical cases these days, as the data rates that the hard transceivers run at are well beyond what the normal pins of the device can achieve. Admittedly, the logic functions can potentially be achieved in the fabric but the "slow" (merely 100s of Mbps :) pins will stop it being much use... – Martin Thompson Oct 7 '14 at 12:23