Yes it's possible, but I have to find time for that. The software of the evaluation board takes care of the spikes ("remove spikes"), so I thought it's not so urgent to fix that in the FPGA (which takes me some time).
Is it possible to fix it by FPGA changes? I see readout cycle (proc_drs_reedout) in drs4_eval(4)5_app.vhd, but not sure where to exactly put this three commands. Could you please attach app.vhd file for eval board with example how to fix ?
Good news for all DRS4 users. After many years, I finally understand where the "symmetric spikes" come from and how to fix them.
The "symmetric spikes" are small spikes of 17-18mV, which randomly happen at 1-2 cells. They alwas come in groups of 2 in each channel, symmetric around sampling cell #512. See first attachment.
The reason for the spikes is the previous readout cycle. On each readout cycle, the "read bit" is clocked through all 1024 cells to switch one cell contents to the DRS4 output. At the end of the 1024 cycles, the read bit stays at its last position. The bit is carried by a metal line on the chip, which crosses all 9 channels (second attachment). This bit now influences the sampling cells below the metal line capacitively, so their contents is "pushed up" by a few mV, just like the ROFS offset does. Since the DRS sampling channels are in a snake layout, going 0-512 from left, then 512-1023 back again, the line crosses two cells in each channel, and thus the symmetric spikes.
Previously, there was a software solution for that. In the evaluation board software DRSOsc there is a button "Remove spikes" which tries to fix this in software. Although this works most of the time, it's annoying and not 100% safe. Like when the spike sits on top of a noise signal, it might not be recognized. Fixing this in hardware is however straight forwar. After the readout cycle ends, push the read bit out of the chip:
This shifts the bit out of the chip, so that the next event is not affected by the read bit. The third attachment show the effect of this. The "clear cycle" increases the readout time a little bit, but depending on the application this might be worth it.