Gigabit Transmitter and Receiver ICs
for use in LHC front-end link applications

Manufacturer Transmitter
AMCC S3017 - SONET/SDH/ATM OC-12 Transmitter
Cypress CY7B923 - HOTLink Transmitter
Gennum GS9022 - Digital Video Serialiser
Hewlett Packard HDMP-1022 - G-LINK, Gigabit Rate Transmitter
National Semiconductor DS92LV1021 - 10-bit Bus LVDS Serializer
Texas Instruments SN75LVDS83 - Flatlink Transmitter
Vitesse VSC7115 - Fibre Channel Transmitter
Vitesse VSC7214 - Multi-Gigabit Interconnect Chip
 
For a table with a complete overview, see the Gigabit Transmitter Overview. 
(doesn't contain National Semiconductor)
 

Not by vendors supported components

 Manufacturer Transmitter
INFN MATCH
Motorola MC100SX1451FI100 - AutoBahn Spanceiver
 

SCOPE

This document describes different transmitter and receiver ICs that possibly can be used in LHC front-end link applications. The focus of the document is on the transmitter side, as it is inside the particle detectors where most problems such as power consumption, complexity of use and radiation hardness are expected. Currently, this document considers only links that can send data at rates faster than 330 Mbps.

This page gives an introduction to the functions of the transmitter and receiver ICs in general. At the top of this page you find a table which contains pointers to pages describing specific transmitter and receiver ICs.

Those component pages in turn contain the following sections:

The information given under the Description and Issues headings is a personal engineering view of the components and provides only a guide to certain features and problems relevant to the LHC front-end link applications.

While there is in all front-end links some form of radiation, there is currently no knowledge at all on the radiation hardness of any of the components described. Therefore I believe top priority should be given to test at least a few types as soon as possible.

Comments to this document and suggestions for other components are welcomed and may be sent to Erik Van der Bij.
 

INTRODUCTION

Link components

A link exists of a:

Transmitter

The transmitter chip has the following functions: You can't just use a crystal oscillator on the receiving side to sample the incoming bits as the frequencies are too high and the tolerances of oscillators are not tight enough. Therefore the receiver should be able to extract the receive clock out of the incoming data stream, which is only possible if there are enough bit changes in the data stream. By performing some coding scheme, this can be guaranteed.

The second reason for the coding is that on average the same amount of 0's and of 1's have to be sent. This will give a DC-balance, which prevents drivers and receivers from running against one of the power rails and which allows AC-coupling. Also, the lack of DC-balance can potentially result in data-dependent heating of lasers due to a transmitter sending more 1s than 0s, resulting in higher error rates.

Not all transmitter chips have a coder integrated, in which case the user must ensure some form of coding.

In all cases the transmitter chip will have an integrated Phase-Locked Loop (PLL), which multiplies the clock that comes at the rate of the parallel data into the frequency used for the serialiser.

Cable driver, cable and cable receiver

One can choose to drive an electrical cable or a fibre-optic cable. For speeds up to roughly 400 Mbps, it is  possible to use electrical transmission up to distances of around 100 meter. This is dependent on the type of cable and of the choice of equaliser circuitry used. In many cases the transmitter chips can drive directly a copper cable, without the need of an extra cable driver IC. Sometimes some passive coupling circuitry is needed.

For serial link speeds above 400 Mbps, transmission over fibre-optic cabling is the only feasible way to send data over a distance more than several tens of meters. Complete fibre-optic transmitter and receiver modules exist from many vendors. Those modules have integrated laser drivers and laser components (transmitter) and PIN-diodes and associated electronics (receiver) and have either a piggy-tail fibre coming out, or have an integrated fibre-optic connector. Also transceivers exist that have both a transmitter and a receiver in one package. Those modules cost in the order of $200 (Jan-1998). Of course one may build the fibre-optic drivers and receivers out of separate components, but this requires a high degree of knowledge about analog high-frequency electronics.

Receiver

The receiver chip has the following functions: The receiver recovers the clock out of the coded data. To reduce synchronisation times, in most cases the receiver still has a clock input which must be connected to a free-running oscillator. Also the receiver has a PLL built in, which is needed for the de-serialisation. It is not possible to just use a crystal oscillator on the receiving side to sample the incoming bits as the frequencies are too high and the tolerances of oscillators are not tight enough.
 
If the data was coded, it will be decoded in the receiver. With some of the coding methods, the receiver chip will be able to detect that there was a transmission error.

Byte synchronisation makes sure that the receiver will synchronise on the datastream so that when the data is given out as a parallel word, that bit 0 which was sent out by the transmitter will also be received as bit 0 and for example not as bit 1 or bit 5. Different solutions for this exist and are for gigabit serialiser ICs much more complicated than added start and stop bits like is done for simple and slow protocols such as RS-232. In most cases the transmitter will have to send some special synchronisation characters which the receiver will use to align the data. After this synchronisation is done, in principle no other synchronisations have to be made. However, errors on the link may cause loss of synchronisation.

Parameters

The following are the main parameters that influence the usability of a transmitter for a particular purpose.

CERN - High Speed Interconnect
Erik Van der Bij - 13 April 1999 - Disclaimer