It has turned out that the stability of the AVDD and DVDD power supplies for the DRS4 are very critical. On the evaluation board I use a REG1117-2.5, on our VME board I use a ADP3338-2.5 for the DVDD power supply. When the domino wave is started, the power consumption of the DRS4 chip jumps up by ~40 mA, which has to be compensated by the linear regulator. Following screen shot shows what happens:

The blue trace is the DWRITE signal indicating the sampling phase when high. The yellow is the SRCLK showing when the readout takes place. The pink is now the DVDD power. It can be clearly seen that there is a dip of ~50 mV when the domino wave starts, a positive dip when it stops and another smaller dip when the readout starts. This causes strange effects: If the trigger arrives during the first dip, the actual sampling takes place when the DVDD is ~50 mV smaller, which leads to a baseline shift of a sampled 0V DC input voltage of about the same amount (-50 mV).

The obvious improvement is to put a huge capacitor on the power supply, but that does not help much:

The dip gets a bit smaller, but it's still there. So a better solution would be to use a faster LDO regulator. Please take care of this if you plan a new design.

Furthermore, I believe that the chip internally has some "warmup" phase, where the die heats up a bit when the additional 40 mA are drawn. So a "good" solution is to wait some time after starting the domino wave until one allows for triggers. Tests showed that a few milliseconds are necessary to keep the baseline shifts below a few millivolts. This of course decreases the dead time of the system significantly, so one has to choose the proper balance between increase dead time and increased base line shift. On some applications where a baseline shift is not an issue, one could opt for the minimum dead time.

It turned out that the VDD switch off speed plays some important role. On our VME board, we have a linear regulator, then a 4.7 uF capacitor, then the DRS4 chip (DVDD and AVDD). When switching off the VME power, it takes quite some time to discharge the 4.7 uF capacitor, since the DRS4 chip goes into a high impedance mode if VDD < ~1V. This gives following VDD trace:

Rising edge is power on, falling edge is power off. Note the horizontal time scale of 2 s/div. So to get below 0.3 V or so, it takes up to 30 seconds. If the power is switched back on when AVDD is above 0.3V, the DRS4 chip can get into a weird state, where probably many domino waves are started and the chip draws an enormous amount of current. Typically the linear regulator limits the current, so the 2.5V drops to ~1.5V, and the board is not working. If people are aware of this and always wait >30sec. before turning the power on again, this is fine, but people might forget.

So the solution is to put a resistor (typically 100 Ohm to 1 kOhm) parallel to the 4.7 uF capacitor in order to have some resistive current load of a few mA. The discharge then looks like this:

Note the horizontal scale of 10ms/div. So after 30 ms AVDD is discharged and powering on the chip again does not do any harm. The same should be done to DVDD.

The clock-to-output delay is the same if one uses the multiplexer or not. I found however that in most cases the delay of 38 ns needs some fine tuning to get optimal performance. So I typically use a shifted clock generated by the FPGA clock manager with a programmable delay (+-5 ns for Xilinx) and optimize this in the running system.

"internal buffers" are all internal operational amplifiers in the DRS4 chip. Every OPAMP needs a bias (just look it up in any electronics textbook), which determines the linearity and the speed of the OPAMP. When designing DRS4, I was not sure if the required BIAS voltage changes over time, or between chips, so I made it available at a pin, which is a common technique in chip design. But it turns out now that this voltage is not very critical, so just keeping the pin open will work in most cases. 

No. It shifts about ROFS-0.25V. So only if ROFS=1.55V, the shift will be 1.3V.

Just read the datasheet under "ANALOG OUTPUTS". I'm sorry if I did not describe this clearly, but the U+ voltage is fixed (only dependent on ROFS), and U- can be calculated using Uofs as written in the datasheet. 

OUT+ is 0.8V~1.8V, OUT- is 2*Uofs-OUT+. So you can only change the OUT- level, not the OUT+ level. 

Please find attached the complete dimensions.

Indeed you have to make an external trigger. The evaluation board uses the "transparent mode" of the DRS4 to "mirror" the input signal at the output, then puts a comparator there. The schematics of the evaluation board is in the manual. This does then not degrate the analog performance. You can of course also split the signal at the input, this will only add a minor additional load to the input signal, since the load of the DRS4 chips itself is much bigger than that of any comparator.

An alternative is to turn on the transparent mode and continuously digitize all 8 outputs with your AD9252. Then you make the trigger purely digital in your FPGA. You can put there a comparator, or even more complex logic like multiplicity etc. Note however that this causes some latency, since the ADC has a pipeline which is quite long, so you have to buffer the latency of your trigger in the analog window of the DRS4 sampling cells. Like if you run the DRS4 at 1 GSPS, you can accomodate 1024 ns of sampling depth, which is good for maybe 500 ns of trigger latency plus 500 ns of the waveform of interest.

The amplitude of the analog signal is not degraded by the transparent mode, since the signal is buffered on the chip, and the output of this buffer is send off the chip. The waveform digitizing of course requires quite some current to charge up all capacitors, so there is  maximum current of ~1mA for 5 GSPS. If you only have a weak signal source, your bandwidth might be limited by that. On the evaluation board for example we use passive transformers to produce the differential input signal from a single-ended signal. Although the transformers are rated 1 GHz Bandwidth, we only achieve 200 MHz with the passive transformers. By using active high speed differential drivers, you can get about 700 MHz right now.

If you have two channels with 500 ns and 510 ns trigger latency, there is no difference in the "domino stop position" since there is only one domino circuit per chip which can be stopped. So the stop position is the same for all eight channels on a chip. 

There is one analog buffer per channel at the output, as indicated on the FUNCTIONAL BLOCK DIAGRAM of the datasheet. The section ANALOG INPUTS clearly states that the input signal has to load directly the sampling capacitors.

All other people using the chip so far correctly understood these things so far, so I believe more information beyond the datasheet is not necessary. I believe you have a principal problem of understanding, which can hardly be clarified by email. Best would be if you directly call me, I can then explain things to you.

Please note that SetTriggerLevel(level, polarity) needs "level" in volts, not millivolts, so you need SetTriggerLevel(-0.3, true). The trigger mode is not specified with any library call, but depends on what your program does. If you always poll on IsBusy(), then you are already in "normal" mode. The auto mode can only be achieved on the user application level by doing an "artifical" trigger by calling SoftTrigger() if there are no hardware triggers for a certain time. 

A firmware update requires a power cycle of the evaluation board. Have you tried that? I attached for you reference the current drs_eval1.mcs file, which is meant to go into the XCF02S PROM. There were recent changes also in the DRS library, and I'm not sure if yous if recent enough. So I put also the current C files which go with the firmware. They contain also some improvements which should reduce the intrinsic noise of the board.  

There is no built-in possibility to open waveform files, you have to write your own programs to do that. 

Yes, but you have to recompile the oscilloscope application. Find following line in the source file DOFrame.cpp:

            m_WFfd = open(filename.char_str(), O_RDWR | O_CREAT | O_TRUNC | O_TEXT, 0644);

and replace it with

            m_WFfd = open(filename.char_str(), O_RDWR | O_CREAT | O_TRUNC | O_BINARY, 0644);

 that fixes the problem. To compile the program, you need MS Visual C++ and you have to install the vxWidgets library. Let me know if you have any problem with that.

Anyhow I plan a major software update soon (weeks), which not only fixes this problem, but also reduces the noise considerably by doing a kind of two-fold calibration.

- Stefan

The locking time is typically 20-30 cycles of the external reference clock, I will update the numbers in the datasheet soon. I attached a screenshot of the chip when starting up at 1 GHz (0.5 MHz REFCLK), so you can see the behaviour. The upper curver is the DTAP signal, the lower curve the PLLLCK signal. As you can see, the PLLLCK signal is not purely digital. Actually it's a simple XOR between the REFCLK and the DTAP signal, so you need an external 4.7nF capacitor to "integrate" this signal. Without this capacitor, you would see small negative spikes whenever there is s small phase shift between the DTAP and the REFCLK signal. Have a look at your DTAP signal, is it in phase with the REFCLK? 

Hello,

may I draw your attention to the upcoming Real Time Conference 2010, taking place in Lisbon, Portugal, May 23rd to May 28th, 2010.

http://rt2010.ipfn.ist.utl.pt/

Several groups which are developing DRS4 electronics will come to this conference and present their work, so it will be a good opportunity to exchange ideas and experiences. There will also be a short course on digital pulse shape processing, which is highly relevant for our field.

Looking forward to see you in Lisbon,

    Stefan 

Actually the XOR is followed by an inverter, so it will integrate to high if the two clocks are in phase. 

If the WSRin is fed internally to WSROUT, then the level of the WSRIN pin does not matter, it's just disconnected. You can leave the pin open without problem. WSROUT is however active, so you can observe the internal state of the write shift register. In the default configuration (8x1024 sampling cells), all 8 channels are active all the time, so the WSR is loaded with ones. The inverter at the output then makes all zeros from this. If you configure the chip as 4x2048 cells, then you will observe switching bits at WSROUT. 

Actually I double checked the schematics, WSROUT has NO inverter at the output. So the output should be always one in a 8x1024 channel configuration.

Concerning the read/write you are right. On each clock cycle, SRIN will be shifted into the first bit, and the last bit will be visible at SROUT.

The start/stop requirement is obsolete and has been replaced by  elog:10. I need to update this in the datasheet. The delay between the RSRLOAD and the SRCLK has the following reason: On the RSRLOAD the first sampling cell is output to the chip and to the ADC. This can sometimes be a rather high swing, which needs some time to settle, and some warm-up for the output driver. But actually I never really measured it, so it's there just as a safety margin. But I would encourage you to try to reduce this time and see it the first few bins of the readout change in offset.

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.