Have you made sure that DENABLE and DWRITE stays low during the reset? 

Ok, then I have no idea. I never tried several reset pulses (actually this is not needed), so I have to reproduce the problem myself and investigate it. Actually in all my designs the reset input is just left open, since the internal initial reset is enough, so I have to modify my design first... 

Dear DRS4 users,

a new version of the evaluation board has been designed and is in production now. The main difference is that it uses active input amplifiers, which result in an analog bandwidth of 700 MHz (as compared with the 220 MHz of the previous board) at moderate power consumption, so the board can still be powered by the USB port. New orders will receive boards V3, the old V2 boards are not available any more.

It is mandatory to use the software revision 3.0.0 or later with the new board. This software has also many new features in the oscilloscope application, and together with the new firmware it reduces the noise of the board below 0.5 mV RMS. Although the software can be used with old V2 boards, some limitations might apply due to the old firmware of the boards. People having a Xilinx download cable can flash the firmware contained in the 3.0.0 revision to their V2 board to get all features of the new software.

The evaluation board manual V3 contains the new schematics of the analog inputs using the THS4508 differential amplifier, so people doing their own design can use this schematics as and example.

Best regards,

   Stefan Ritt

I will prepare some more detailed description of how to do this in the near future, but we are still learning ourselves constantly how to do that better. 

So for the moment I only can recommend you to read the function DRSBoard::CalibrateTiming() and AnalyzeWF(). What you basically do is to define an array of "effective" bin widths t[i]. You start with the nominal bin width (let's say 500ps at 2 GSPS). Now you measure a periodic signal, and look for the zero crossings. If you have a 100 MHz clock, the time between two positive transitions (low-to-high) is 10.000ns. Now you measure the width as seen by the DRS chip, assuming the effective bin widths. The exact zero crossing you interpolate between two samples to improve the accuracy. Now you measure something different, let's say 10.1ns. So you know the ~20 bins between the zero crossings are "too wide", but you don't know which one of them is too wide. So you distribute the "too wide" equally between all bins, that is you decrease the effective width of these bins from 500ps to 500-0.1ns/20=499.995 ps. Then you do this iteratively, that is for all cycles in the waveform, and for many (1000's) of recorded waveforms. It is important that the phase of you measured clock is random, so that all bins are covered equally. Then you realize that the solution oscillates, which you can reduce by using a damping factor (called "damping" in my C code). So you do not correct to 499.995ps, but maybe to 499.999ps. If you iterate often enough, the solution kind of stabilizes.

The attached picture shows the result of such a calibration. Green is the effective bin width which in the end only slightly deviates from 500ps. But the "integral temporal nonlinearity" shows a typical shape for the DRS chip. It's defined as

          n
 Ti[n] = Sum (t[i]-500ps)
         i=0

where t[i] is the effective bin width. So Ti[0] is zero by definition, but the deviation around bin 450 can go up to 1ns at 2 GSPS.

Now you can test you calibration, by measuring again the period of your clock. If you do everything correctly and have a low jitter external clock and no noise on your DRS4 power supply voltages, you should see a residual jitter of about 40ps.

Hope this explanation helps a bit. Let me know if I was not clear enough at some points. 

- Stefan

The expression ENOB for 1Vpp/0.35mV(RMS) is wrong, but I learned this later. Now I call it SNR. The ENOB is calculated in a more complicated way, see for example http://en.wikipedia.org/wiki/ENOB. If you measure the ENOB without timing correction, it's pretty poor (in the order of 7-8 bits). This is because without timing calibration, a sine input has huge side bands, and the ENOB involves the power of your signal over the power of the side bands. If you do a proper timing calibration, you spectrum gets "sharper", and hence the ENOB increases. But I have to admit that I never measured it carefully, since we are still optimizing the timing calibration. Once we have a perfect timing calibration, I will do it and update the data sheet. 

No you are right about that. The THS4508 has a gain of +2, and by using the resistor pairs we do

1) Reduce the gain back to unity

2) Reduce the input DC level from 1.8V to 0.9V to match the input range

3) Terminate the signals at the input of the DRS chip to minimize reflections

I know this is not so obvious from the schematic, so thanks for asking.

- Stefan 

No, not in this version. We plan a future version of the evaluation board with clock synchronization, but that board will not be ready before 2-3 months. Anyhow the board is more meant as an evaluation board, to test the chip and develop own electronics, and not to build a complete DAQ system. Note that CAEN distributes now a VME board containing the four DRS4 chips and 32 channels on a board. 

Well, one thing you can do is to generate an external trigger and send it to the external trigger input of both cards. Then you can determine the time in respect to the trigger point in both boards. But since the trigger cell jitters by 2-3 cells in each chip, the accuracy is limited to about 1-2 ns when running at 2 GS/s. 

Dear colleague,

if you live not so far from Zurich, you might be interested in this workshop:

http://www.xtronix.ch/hep/psi_workshop.htm

This is a combined PSI-CAEN presentation of digitizer hardware including the new V1742 board based on the DRS4 chip. The workshop will also show how digital pulse processing can be used to effectively extract time and energy from detector signals, and thus replace more and more traditional analog electronics. Please register at the above site if you are interested.

Best regards,

    Stefan Ritt

> Hello,
> 
> I was just building version 3.1.0 and ran into some problems in DOScreen.cpp.  Basically the conversions from
> char* to wxString were generating "ambiguous overload" errors (in gcc 4.4.3, wx-2.8)
> 
> The simple fix is given in  the following diff output.
> 
> Cheers,
> 
> Bob
> 
> diff drs-3.1.0_o/src/DOScreen.cpp drs-3.1.0/src
> 237c237
> <      wxst = wxString(m_frame->GetOsci()->GetDebugMsg(),wxConvUTF8);  //BH
> ---
> >       wxst = m_frame->GetOsci()->GetDebugMsg();
> 246c246
> <       wxst = wxString(m_debugMsg,wxConvUTF8);  //BH
> ---
> >       wxst = m_debugMsg;
> 477c477
> <     wxst = wxString("AUTO",wxConvUTF8); //BH
> ---
> >          wxst = "AUTO";
> 479c479
> <     wxst = wxString("TRIG?",wxConvUTF8);  //BH
> ---
> >          wxst = "TRIG?";
>  

Thanks for mentioning this. I always overlook this because I develop under Windows where this warning does not show 
up. I fixed that in the current version. Usually I just use _T() instead wxString() because this is shorter and 
recommended by the developers.

Cheers, Stefan.

Indeed that's what I had before. If you don't need the 9th channels, you can use it to identify the spikes. But we have applications where we need all 9 channels. That's why I made Osc::RemoveSpikes a bit more complicated, so it will still work when all 9 channels are used. This new version is release 3.1.0. If you just blindly subtract the 9th channel, your noise could increase by a sqrt(2). 

One obvious problem in your method is your statistics. If you have n hits in a bin of the histogram, the error of n is sqrt(n). So if you measure 100 hits, this is more like 100+-10 hits. If you want a better precision, you need much higher statistics. I myself never used this method, but I attach a typical nonlinearity curve running at 2 GSPS, sot hat you know what you should expect. I do some smoothing between neighbor bins so that they do not scatter too much. As you can see, the integral nonlinearity goes almost up to +-2 ns. This value is smaller at higher sampling speeds.

 - Stefan 

The length of the segments is a combination of the sampling jitter and the voltage noise. If you signal contains some noise (and all signals do) it will translate to timing jitter. The DNL of the DRS sampling interval shows a variation from the mean of typically 30%. After you correct for it, it will of course become much smaller. As I said, some people measured 10 ps timing with the DRS4 after careful timing calibration. 

I'm not so sure about the temperature stability of the default (DRS4 internal O-OFS) value, that's why I used a precision DAC in my design. But actually I never tried without. Probably the default internal value is good enough if you calibrate each chip (which you do anyhow).

Most designs use no filter between DRS4 and AD9222. Since the DRS4 output is BW limited at around 50 MHz, there is not much you win if you put a 32.5 MHz low pass there. And the PCS gets just so much simpler.

You are right with the latency of the AD9222, this is an issue. From the remaining 81 ns you loose a few going out of the FPGA, you need one or two FPGA clock cycles to make the decision, the DRS4 has also some stopping latency (maybe 10 ns). So you are at the edge. Some people use hardware comparators which are faster than the AD9222, one guy uses even directly an LVDS input of the FPGA "mis-used" as a comparator, where the comparator level (=LVDS negative input) comes from a DAC.

- Stefan

Yes. Just have a look at the schematics of the evaluation board. This is exactly what is done there.

Actually in the newest version we went one step further and put the comparator at the input of the DRS chip. This way it is active even during the readout of the DRS4 chip and we can use this as a counter to count the overall hit rate at the input.

- Stefan

Thanks. I added your fix to the current 4.0.0 distribution.

- Stefan 

With version 4 of the DRSOsc program and a decent computer, you should be able to achieve something close to 500 Hz, but that's the limit. The board is for evaluation purposes of the chip, not for production data acquisition. The main limit comes from USB2, which is limited to ~25 MB/sec. We are in the process of designing a new board with Gigabit Ethernet readout, with which you should be able to get your 4 kHz. But this board will not be ready before spring. There is also a VME board by CAEN in Italy which sits in a VME crate. This board is also much faster than the USB board. Here is the link:

http://www.caen.it/csite/CaenProfList.jsp?parent=13&Type=WOCateg&prodsupp=home

Good questions. I looked myself in the code and found:

  drs_readout_clk       <= I_CLK33;

  drs_readout_clk_ps    <= I_CLK33; -- phase shifted clock for FADC

  drs_serial_clk        <= I_CLK33;

which is apparently wrong (should be drs_readout_clk_ps <= I_CLK33_PS;) . But apparently the board is working with the unshifted clock. Could be that the PCB traces to the DRS and the ADC have different lengths, and by accident, they have just the right value.

The way to find that out is to keep the ADC clock phase variable (most FPGAs allow a +-5 ns phase adjustment inside their clock blocks), and then try different values. If the phase shift is wrong, you will see spikes every 32 samples in the readout. The spikes are always there (from some internal switching of bus segments), and you can see them with a differential probe at the DRS output. The ADC phase must then be made such that the sampling point of the ADC comes after that spike, just at the end of the settling time, barely before the next analog value shows up at the DRS output. This is a bit tricky and can be made best just by trying out different values.

The evaluation board has a 50 Ohm termination resistor, which already converts your current into a voltage signal. If the resulting signal is too low (<20 mV) you can put in an amplifier or raise the HV of your PMT (inside the valid range given by its datasheet of course).

- Stefan 

In the attachement you will find a working DC-coupled input stage to the DRS4 chip. The bandwidth of this design is about 700 MHz, the gain is 1.

The upper version does not have an additional input buffer. This is not a very "clean" design, since the differential driver has an input impedance of 150 Ohm, which together with the 75 Ohm termination resistor gives about 50 Ohm termination. 

The lover version has an additional input buffer, which nicely decouples the input from the differential driver, so a proper 50 Ohm termination can be used at the cost of additional power for that buffer.

The COM common mode voltage and the OFS voltage have to be set according to the required input range, so that ranges such as 0V...1V, -0.5V...+0.5V, -1V...0V can be used. The COM voltage can be high impedance (simple resistor divider), while the OFS voltage needs to be low impedance (fast active buffer). The analog switch ADG918 can be used to digitize a precise calibration voltage CAL+, which can then be used for precise gain calibration of the DRS4 sampling cells.