DRS4 Forum
  DRS4 Discussion Forum  Not logged in ELOG logo
Entry  Tue Mar 9 23:28:45 2010, Hao Huan, Serial Interface Frequency of the DRS Chip 
    Reply  Wed Mar 10 10:07:28 2010, Stefan Ritt, Serial Interface Frequency of the DRS Chip 
       Reply  Thu Mar 18 21:38:10 2010, Hao Huan, Serial Interface Frequency of the DRS Chip 
          Reply  Thu Mar 18 22:10:41 2010, Stefan Ritt, Serial Interface Frequency of the DRS Chip 
Message ID: 55     Entry time: Thu Mar 18 21:38:10 2010     In reply to: 51     Reply to this: 56
Author: Hao Huan 
Subject: Serial Interface Frequency of the DRS Chip 

Stefan Ritt wrote:

Hao Huan wrote:

in the DRS4 datasheet I read that the optimal frequency for SRCLK is 33MHz. However in the evaluation board firmware SRCLK is toggled at rising edges of the internal 33MHz clock, i.e. the frequency of SRCLK itself is 16.5MHz instead. Is that frequency better than 33MHz?

The reason for the 16.5 MHz is the following:

After each block of 32 bins, the DRS4 chip switches an internal segment, which causes some small spike at the analog output of the chip. This spike is a bit wider than 30ns, so if everything is digitized with 33 MHz, then you see small spiked each 32 cells. The appropriate solution would be to modify the firmware to digitize all cells with 30ns (33 MHz) and all cells with the spike with ~50 ns (20 MHz). If you do the ROI readout mode, you don't know for the first 10 cells if one of them belong to this class, since the cell address takes 10 cycles to be read out. So you would first have to read 10 cells, and then if you realize that one of them is one of the problematic ones (cell number modulo 32 is zero), you have to re-read the first 10 cells, and digitize the problematic cell with a longer settling time. Now this is a bit complicated to implement in the firmware, so I was just too lazy to do it and decided to digitize everything with 16.5 MHz. But if you are worried about the dead time, you should consider implementing the mentioned algorithm. 

 Thanks! The suggested algorithm looks promising. However, if the spikes take place only for those specific cells, is it possible to absorb them into the offset calibration?

ELOG V3.1.5-fe60aaf