70
3 SAMPA Chip Implementation
3.2.5.1 Ring Buffer
The ring buffers that hold the event data is, as previously mentioned, split in two,
where one memory holds the payload for an event, while the other holds the header.
Due to the varying size of an event payload and the limited buffer space to hold the
event payloads, this presents the possibility to voluntarily drop the payload data in
case the buffer for payload becomes full, while retaining the header, possibly freeing
enough space to store the next event payload. In case of lost payload, the header
will be altered to mark that the payload was dropped. As long as the occurrence of
overflow is low, this should provide more complete payloads then if the packet was
terminated whenever the buffer got full.
The header is only written to the buffer once the event is completed. The writing to
the header buffer, in turn, signals to the buffer readout section that it can start reading
out a new event. In this way, the readout part never reads out from the data buffer
until an event is completed and so it is safe to move the pointers in the data memory
about. The number of samples to read from the payload memory is indicated in the
header.
Since the buffer, due to the new implementation of the zero suppression, needs
to sometimes write two words to the buffer in one sample cycle, the payload buffer
writing always operates at half the serial clock cycle to give the possibility to write
two words in one sample cycle, regardless of the sample speed. In hindsight this
could probably have operated at the bunch crossing clock speed, since the maximum
sampling clock speed is 20 MHz which is half the bunch crossing clock speed and
this in turn would save a little bit of power consumption. With some optimization
it would also have been possible to provide a second clock domain at two times the
sampling speed, though this would require some extra work in the back-end due to
the new clock domain. As the module that receives the data from the output of the
buffer also operates at half the serialization speed, the synchronization logic between
the input and output could in principle have been greatly simplified, but since the
change to the faster clock domain was changed late in the development process, this
was not done. For SAMPA v1 there was a buffer in between the module that sent
data to the buffer and the buffer itself, but this in-between-buffer had the potential
for overflow if the data rate was higher than the sample rate, even though the output
serialization could handle the higher flow.
The addresses for accessing the buffer are Gray encoded which should reduce
the switching in the memory when it is writing in sequential access. The buffers
are implemented close to what is described in [13]. Another technique as described
in [14] was originally used for v1 of the device, but was deemed too risqué to be
used for further development due to its asynchronous method of passing pointers for
buffer full and empty checking.
3 SAMPA Chip Implementation
3.2.5.1 Ring Buffer
The ring buffers that hold the event data is, as previously mentioned, split in two,
where one memory holds the payload for an event, while the other holds the header.
Due to the varying size of an event payload and the limited buffer space to hold the
event payloads, this presents the possibility to voluntarily drop the payload data in
case the buffer for payload becomes full, while retaining the header, possibly freeing
enough space to store the next event payload. In case of lost payload, the header
will be altered to mark that the payload was dropped. As long as the occurrence of
overflow is low, this should provide more complete payloads then if the packet was
terminated whenever the buffer got full.
The header is only written to the buffer once the event is completed. The writing to
the header buffer, in turn, signals to the buffer readout section that it can start reading
out a new event. In this way, the readout part never reads out from the data buffer
until an event is completed and so it is safe to move the pointers in the data memory
about. The number of samples to read from the payload memory is indicated in the
header.
Since the buffer, due to the new implementation of the zero suppression, needs
to sometimes write two words to the buffer in one sample cycle, the payload buffer
writing always operates at half the serial clock cycle to give the possibility to write
two words in one sample cycle, regardless of the sample speed. In hindsight this
could probably have operated at the bunch crossing clock speed, since the maximum
sampling clock speed is 20 MHz which is half the bunch crossing clock speed and
this in turn would save a little bit of power consumption. With some optimization
it would also have been possible to provide a second clock domain at two times the
sampling speed, though this would require some extra work in the back-end due to
the new clock domain. As the module that receives the data from the output of the
buffer also operates at half the serialization speed, the synchronization logic between
the input and output could in principle have been greatly simplified, but since the
change to the faster clock domain was changed late in the development process, this
was not done. For SAMPA v1 there was a buffer in between the module that sent
data to the buffer and the buffer itself, but this in-between-buffer had the potential
for overflow if the data rate was higher than the sample rate, even though the output
serialization could handle the higher flow.
The addresses for accessing the buffer are Gray encoded which should reduce
the switching in the memory when it is writing in sequential access. The buffers
are implemented close to what is described in [13]. Another technique as described
in [14] was originally used for v1 of the device, but was deemed too risqué to be
used for further development due to its asynchronous method of passing pointers for
buffer full and empty checking.