Introduction

This is a requirements and design document for the planned, new Trigger Clock Distribution (TCD) board.
The main purpose of the redesign is to alleviate the problems which come from the current
need to have all TCDs in one VME crate. Specifically:

the very dense and unmanageable cable connections at the back of the current TCD crate
electrical problems with bussed signals received via the TCU, particulalry the RHIC clock
the limited number of TCD boards which can fit in a single VME crate
the need to have an expensive 9U VME crate with a VME CPU when using a TCD to
debug detectors in a lab

Requirements

Form Factor

1) The new TCD shall be housed in a standalone compact form factor (box) powered by an
inexpensive external power supply.

This allows the TCDs to be placed far away from each other making the cable management
problem local to a specific detector (Problem 1 above) and unties the signaling and power from a
VME crate (Problems 2, 3 & 4 above).

TCU Interface

1) The Trigger-to-TCD interface (the interface to the TCU) shall be designed to allow the TCD
to be placed up to 100(?)m away from the TCU.

This is a crucial implementation question. If the TCD does not need to be so far away
one can implement the TCU-TCD interface in copper which makes it easier to deal with.
So what number should one put there???

2) The TCD will receive a stable & precise RHIC clock from the TCU.

This shall be the reference clock which will be later sent to the detectors.

The duty factor should be 50+-1 % and the clock should always be phase adjusted at the TCU to the
accelerator clock within 0.5ns.

The jitter should be less than 0.5ns.

This is really a requirement of the TCU.

3) The TCD will receive 20 bits of trigger data from the TCU: 4 bits trigger command, 4 bits DAQ command,
12 bits token.

This data could potentially be sent on every RHIC clock.
The arrival of this information must be fixed in time in relation to the collision at least within
1 RHIC clock.

This is really a requirement of the TCU.

4) The TCD will send 1 BUSY signal back to the TCU.

The TCD might send a BUSY signal back to the TCU within 5 RHIC clocks from the time it receives
the trigger information. Note that one must additionally take into account the propagation delay
due to the length of the TCU-TCD interconnect!

Detector Interface

1) The current detector electrical interface (PECL on a ribbon cable with all the
signals) will be kept.

We need to maintain backward compatibility with all detectors.

2) The TCD will provide a precise RHIC clock to the detectors.

This clock will be referenced to the input clock received from the TCU and
the TCD will provide a phase difference relative to the input clock of less than
0.5 ns.

The jitter of this output clock will be less than 0.5 ns.

The duty factor shall be 50+-1 %.

3) The TCD will provide a user adjustable RHIC clock phase in steps of 1 ns.

4) The TCD will provide all 20 bits of the trigger data to the detector.

This information must have a constant latency with regard to the input data
and this latency should be kept as low as possible (<= 2 RHIC clocks).

5) The TCD will accept 2 additional bits of information from the detector:
1 bit signalling RDO BUSY and 1 bit for future extension.

6) The TCD will maintain the current TTL front panel Lemo I/O.

The Lemo I/O is necessary for various features of specific detectors
and this function shall be retained.

Design

TCU-TCD Interface Proposal

Because of the need for simple interfaces in terms of amount of cable
as well as the distances involved we propose a serial interface which can
either be physically based on copper or fiber.

Since this is a point-to-point interface from the TCU to the
TCD note that NO detector ID coding is assumed to be
necessary!
I.e. if the TCU decides to send trigger commands on _this_
interconnect the corresponding detector will fire.

Note that this is a proposal so please feel free to comment as much as
you want.

Copper Interface

a) 1 RJ-45 ("ethernet") connector on each end
b) CAT6 cable ("ethernet")
c) LVDS long-haul drivers (i.e. with pre-emphasis)
d) 8b/10b encoding for the data

Fiber interface

a) 3 LC connectors on each end
b) 3 multimode fibers
c) 3 specific optical transceivers (TBD)
d) 8b/10b encoding for the data

Due to the strong need to maintain strict deterministic
phases or latencies on both the RHIC clock as well as the trigger data
we feel that no commercial SerDes chip can be used and that
the communication needs to be hand designed.

We also feel that we should reuse the industry's standard
best practice designs such as LVDS & 8b/10b encoding since
they are widespread and support chips (or VHDL code) are easily and cheaply
available.

The protocol will be the same whether one uses the optical path
or the copper path so one only needs to replace the LVDS drivers with
optical transceivers.

The copper interface can be used if the TCD is less than 10(30?50?)m
away from the TCU as well as for local debugging of the TCD.

Signals

1) RHIC clock is sent from the TCU to TCD with 1 twisted-pair/fiber

Since this is a 50% duty factor clock there is no additional need to
zero balance the signal.

2) Trigger data is sent from the TCU to TCD serialized onto 1 twisted-pair/fiber.

The 20 bits of data are sent as 3 octets (24 bits total) at a 5x RHIC clock rate
to the 8b10b encoder.

The 8b/10b encoder exists for zero balancing as well as framing (and some error
detection).

The 10 bit data from the encoder is then serialized onto the interconnect.

The serialization must complete within 1 RHIC clock which drives the
requirements for the clocking rates.

For the 5X RHIC choice above the serial baud rate would be 500 Mbps.

Note the possibility of adding 4 more bits of trigger information.

3) BUSY signal is sent from the TCD to TCU serialized into 1 twisted-pair/fiber.

Since the BUSY is essentially steady-state one must also zero balance the signal
which means the signal will be sent as 1 octet to the 8b10b decoder.

Bit 0 of the data will represent the BUSY while the other 7 bits can be used for
anything else.

It would be easiest if we use the same 5X RHIC clock to send the data which
would then require the same baud rate of 500 Mbps.