3.2 Digital Implementation
69
bit constants, providing the possibility to have 36 Huffman values of length 12-bits,
which was deemed sufficient and could provide a compression better than 2.5 required
by the TPC for their initial specification [12]. If more constants are needed, it would
be better to add a dedicated register table for the Huffman, but as it was not guaranteed
to be used, this method avoids increasing the device area by having more registers.
3.2.5 Event Management
The event management’s primary task is to notify each module of the data channel
part when to enable processing of input data. An event lasts from when a trigger
is received, until a programmable number of cycles, referred to as a time window,
have been completed. The event management supports receiving the trigger to start
the event, either from an externally pulsed pin, a command sent through the slow
control interface, or by generating it internally whenever the current event is completed, commonly referred to as continuous operational mode. The device supports
suppressing a given number of samples in the beginning and at the end of an event,
which could be useful if the detector knows there is unwanted signalling at the start or
at the end of an event. Suppression at the end can also enable detectors that normally
would need to run in triggered mode, like for instance MWPC based detectors due
to their need for gating to suppress ion-backflow, to use the continuous mode as the
unwanted data during the gating is removed from the transmitted event.
As there are delays between a sample arriving at the different modules of the data
pipeline, the event signals to each module in the pipeline must also be delayed. The
current implementation is based on sending the event signals through a pipeline with
the same length as in the data pipeline, with the signal for each module tapped at the
appropriate delay. In the previous devices this was done by using a counter that was
started at the start of an event and activated each module at the specific count. Any
trigger that was closer than 20 cycles from the previous would not be detected. When
the device is running in continuous mode, there is generally the need to synchronize
the start of acquisition across all devices in the detector. The synchronization is done
by sending an external trigger pulse to all devices at the same time. The devices then
stop the current event and start a new one. As this could happen within the first 20
cycles of an existing event, the device needs to support spacing of triggers down to
one cycle, which is solved by sending the signals through a pipeline. In case a new
trigger is received during an event, this is marked in the header of the packet for the
current event to indicate to the reviving system that the event was terminated early.
The event management also captures the bunch crossing number for the time when
the trigger was received and puts it in a pipeline for inclusion in the header.
A drawback of the pipe-lining method is that it requires more resources, particularly in case of the 20-bit bunch crossing counter. An improvement on the current
implementation would be to delay all control signals to the bunch crossing counter
module by the length of the pipeline, instead of delaying the values themselves.
69
bit constants, providing the possibility to have 36 Huffman values of length 12-bits,
which was deemed sufficient and could provide a compression better than 2.5 required
by the TPC for their initial specification [12]. If more constants are needed, it would
be better to add a dedicated register table for the Huffman, but as it was not guaranteed
to be used, this method avoids increasing the device area by having more registers.
3.2.5 Event Management
The event management’s primary task is to notify each module of the data channel
part when to enable processing of input data. An event lasts from when a trigger
is received, until a programmable number of cycles, referred to as a time window,
have been completed. The event management supports receiving the trigger to start
the event, either from an externally pulsed pin, a command sent through the slow
control interface, or by generating it internally whenever the current event is completed, commonly referred to as continuous operational mode. The device supports
suppressing a given number of samples in the beginning and at the end of an event,
which could be useful if the detector knows there is unwanted signalling at the start or
at the end of an event. Suppression at the end can also enable detectors that normally
would need to run in triggered mode, like for instance MWPC based detectors due
to their need for gating to suppress ion-backflow, to use the continuous mode as the
unwanted data during the gating is removed from the transmitted event.
As there are delays between a sample arriving at the different modules of the data
pipeline, the event signals to each module in the pipeline must also be delayed. The
current implementation is based on sending the event signals through a pipeline with
the same length as in the data pipeline, with the signal for each module tapped at the
appropriate delay. In the previous devices this was done by using a counter that was
started at the start of an event and activated each module at the specific count. Any
trigger that was closer than 20 cycles from the previous would not be detected. When
the device is running in continuous mode, there is generally the need to synchronize
the start of acquisition across all devices in the detector. The synchronization is done
by sending an external trigger pulse to all devices at the same time. The devices then
stop the current event and start a new one. As this could happen within the first 20
cycles of an existing event, the device needs to support spacing of triggers down to
one cycle, which is solved by sending the signals through a pipeline. In case a new
trigger is received during an event, this is marked in the header of the packet for the
current event to indicate to the reviving system that the event was terminated early.
The event management also captures the bunch crossing number for the time when
the trigger was received and puts it in a pipeline for inclusion in the header.
A drawback of the pipe-lining method is that it requires more resources, particularly in case of the 20-bit bunch crossing counter. An improvement on the current
implementation would be to delay all control signals to the bunch crossing counter
module by the length of the pipeline, instead of delaying the values themselves.