30
2 Front-End Electronics
only beneficial if there is need for better granularity in compensating for propagation
delay of the optical links.
The number of active serial data links is configurable so that the detectors can
choose the number of links needed to adapt to their needed bandwidth. Data from a
neighbouring device can be routed through a device to further lower the number of
used links. This requires an additional busy input and output signal to limit the data
flow between the devices as a transmitting device will always have more memory
for output buffering than a device that receives has for the input buffering.
2.4.3 Serial Link Data Protocol
As the GBTx forwards data without regard of the underlying protocol, there is no
need to make the data protocol conform to any specific format. The data sent from
the SAMPA over the serial links consists of a fixed length header and a variable
length data payload, collectively referred to as a packet, see Fig. 2.7. Each packet
corresponds to the event of one channel. The header is always 50 bits long, whereas
the length of the payload for a given packet is given in the header of the packet as the
number of 10-bit words. The format and specifications of the header field is given
in Fig. 2.8 and Table 2.5. Each packet is identified by the type of packet (special or
channel data, see Table 2.6), the device number of the originating device, the channel
number of the originating channel and a bunch crossing identifier for when the event
started. The device number could normally be deduced from the link number that
the data originates from on the CRU, but not in the case of using daisy chaining as
several devices can share the same link.
As the payload has a variable size, due to the compression employed, and since
that size is given in the header, it is important to protect the header from errors to
avoid that the receiving system loses synchronization when an error occurs in the
payload size field. The header is thus protected with Single Error Correction, Double
Error Detection (SECDED), which can correct for one error and detect two errors in
the header. A parity bit for the payload data is also provided.
The channel buffers of the SAMPA might overflow if the collective output bandwidth is not greater than the amount of data produced. The channel buffers are split
into a separate header and payload buffer so that if the payload buffer overflows it
is possible to discard the payload for that packet and mark it in the header that the
payload was discarded. In this way, the header can still be transmitted for the event
to indicate to the receiver upstream that the data was lost.
The device has no busy output signal to indicate that its buffers are full, instead the
CRU will monitor the received packet headers for indication of buffer overflows and
forward the information to the Central Trigger Processor (CTP), which will throttle
or stop the triggers.
Two special types of packages exists:
Heartbeat packet A specially crafted packet that contains a header with no payload, see Fig. 2.9. The header has its packet type marked as heartbeat, all the other
2 Front-End Electronics
only beneficial if there is need for better granularity in compensating for propagation
delay of the optical links.
The number of active serial data links is configurable so that the detectors can
choose the number of links needed to adapt to their needed bandwidth. Data from a
neighbouring device can be routed through a device to further lower the number of
used links. This requires an additional busy input and output signal to limit the data
flow between the devices as a transmitting device will always have more memory
for output buffering than a device that receives has for the input buffering.
2.4.3 Serial Link Data Protocol
As the GBTx forwards data without regard of the underlying protocol, there is no
need to make the data protocol conform to any specific format. The data sent from
the SAMPA over the serial links consists of a fixed length header and a variable
length data payload, collectively referred to as a packet, see Fig. 2.7. Each packet
corresponds to the event of one channel. The header is always 50 bits long, whereas
the length of the payload for a given packet is given in the header of the packet as the
number of 10-bit words. The format and specifications of the header field is given
in Fig. 2.8 and Table 2.5. Each packet is identified by the type of packet (special or
channel data, see Table 2.6), the device number of the originating device, the channel
number of the originating channel and a bunch crossing identifier for when the event
started. The device number could normally be deduced from the link number that
the data originates from on the CRU, but not in the case of using daisy chaining as
several devices can share the same link.
As the payload has a variable size, due to the compression employed, and since
that size is given in the header, it is important to protect the header from errors to
avoid that the receiving system loses synchronization when an error occurs in the
payload size field. The header is thus protected with Single Error Correction, Double
Error Detection (SECDED), which can correct for one error and detect two errors in
the header. A parity bit for the payload data is also provided.
The channel buffers of the SAMPA might overflow if the collective output bandwidth is not greater than the amount of data produced. The channel buffers are split
into a separate header and payload buffer so that if the payload buffer overflows it
is possible to discard the payload for that packet and mark it in the header that the
payload was discarded. In this way, the header can still be transmitted for the event
to indicate to the receiver upstream that the data was lost.
The device has no busy output signal to indicate that its buffers are full, instead the
CRU will monitor the received packet headers for indication of buffer overflows and
forward the information to the Central Trigger Processor (CTP), which will throttle
or stop the triggers.
Two special types of packages exists:
Heartbeat packet A specially crafted packet that contains a header with no payload, see Fig. 2.9. The header has its packet type marked as heartbeat, all the other