DRS4 Forum
  DRS4 Discussion Forum, Page 21 of 46  Not logged in ELOG logo
ID Date Author Subjectdown
  731   Sat Feb 2 00:13:12 2019 Hans SteigerSaving Rate (only 15Acq/s)

Dear All,

 

when I use my Evaluation Board with some PMTs I can digitize 450 Acq/s or so. But when I want to save the waveforms the rate goes down. The Acqu. rate with saving is in the range of 14Hz up to 24 Hz.

I normally use the .txt file. I try to use the 5GS/s but also with much lower sampling rate the saving rate is not getting much better. 

Is this a problem of my McBook connected to the Evaluation Board?

 

All the best,

 

Hans 

  732   Sat Feb 2 10:10:22 2019 Stefan RittSaving Rate (only 15Acq/s)

The reduction of rate is because you save in XML format, which is an ASCII format, so human readable, but takes long to write. If you switch to binary format and write on a decent fast hard disk, you should get back to 450 Acq/s.

Stefan

Hans Steiger wrote:

Dear All,

 

when I use my Evaluation Board with some PMTs I can digitize 450 Acq/s or so. But when I want to save the waveforms the rate goes down. The Acqu. rate with saving is in the range of 14Hz up to 24 Hz.

I normally use the .txt file. I try to use the 5GS/s but also with much lower sampling rate the saving rate is not getting much better. 

Is this a problem of my McBook connected to the Evaluation Board?

 

All the best,

 

Hans 

 

  360   Wed Jul 30 11:38:58 2014 Tsutomu NagayoshiSampling speed of DRS4 Board ver4

 Hello!

I have a question concerning the sampling speed of the DRS4 evaluation board.

It is written in the manual that the sampling speed of  DRS4 Evaluation Board is supported above 0.7 GHz.

However I was able to set the sampling speed to be 0.5 GHz with the function DRSBpard::SetFrequency(0.5)  and realized that DRSBoard::GetTime function fills time array in every 2 ns.

I am wondering if the data taken with 0.5 GHz sampling is reliable or not.

 

Best regards,

Tsutomu Nagayoshi

 

 

  294   Mon Sep 23 09:22:52 2013 Andrzej RychterSampling Frequency: DRS4 eval board

Is it possible to set sampling frequency at 100 MHz in DRS4 eval board? Trying to set 0.1GHz in Osci program results in around 0.7 GHz. In drscl.exe i'm able to set freq at 0.1GHz but calibration is impossible.

Thank For Help!

Andrzej Rychter

  295   Mon Sep 23 09:26:56 2013 Stefan RittSampling Frequency: DRS4 eval board

Andrzej Rychter wrote:

Is it possible to set sampling frequency at 100 MHz in DRS4 eval board? Trying to set 0.1GHz in Osci program results in around 0.7 GHz. In drscl.exe i'm able to set freq at 0.1GHz but calibration is impossible.

Thank For Help!

Andrzej Rychter

700 MHz is the minimal sampling frequency. If you need 100 MHz, just buy a "normal" commercial ADC.

 

Best regards,

Stefan 

  296   Mon Sep 23 09:51:48 2013 Andrzej RychterSampling Frequency: DRS4 eval board

Stefan Ritt wrote:

Andrzej Rychter wrote:

Is it possible to set sampling frequency at 100 MHz in DRS4 eval board? Trying to set 0.1GHz in Osci program results in around 0.7 GHz. In drscl.exe i'm able to set freq at 0.1GHz but calibration is impossible.

Thank For Help!

Andrzej Rychter

700 MHz is the minimal sampling frequency. If you need 100 MHz, just buy a "normal" commercial ADC.

 

Best regards,

Stefan 

 OK!

Thanks for fast reply.

Andrzej

  666   Wed Mar 7 22:49:38 2018 Rodrigo Trindade de MenezesRunning drs_example.cpp

Hello,

We have been using the DRS4 evaluation board (S/N 2636) that works with the scope application. However we are trying to run the DRS4 evaluation board remotely by modifying the drs_exam.cpp to acquire and store data continuously.

We compiled the DRS_example.cpp without the wxWidgets but when we try to run the program, it appears to trigger on nonsense.  The program appears to not be sensitive to the trigger threshold (although for very large trigger threshold it gets stuck in a waiting mode).  Is there a way to ensure that the "normal" trigger mode is set?  We are worried that the auto mode is running.  Otherwise, not sure why the program is triggering on nonsense.  By the way, it does not work with the wxWidgets compiled either so we are worried that there is an additional flag that needs to be set. The routine does not appear to conduct a calibration -- is this not necessary?

Another issue that we are having is with the data set stored on the .txt file looks incorrect.  The time channel stops at 200 (but we think it should go up to 1024). In addition, the voltage channel appears to hover around small values near zero (as if triggering on noise).  The output file appears this way even when we change the threshold to much higher values.  It suggests that the trigger threshold is not actually being set? There are events where the output voltage appears to oscillate through huge negative and positive values too.  So not sure what's going on. 

Thanks!

Rodrigo

Attachment 1: drs_exam.cpp
/********************************************************************\

  Name:         drs_exam.cpp
  Created by:   Stefan Ritt

  Contents:     Simple example application to read out a DRS4
                evaluation board

  $Id: drs_exam.cpp 21308 2014-04-11 14:50:16Z ritt $

\********************************************************************/

#include <math.h>

#ifdef _MSC_VER

#include <windows.h>

#elif defined(OS_LINUX)

#define O_BINARY 0

#include <unistd.h>
#include <ctype.h>
#include <sys/ioctl.h>
#include <errno.h>

#define DIR_SEPARATOR '/'

#endif

#include <stdio.h>
#include <string.h>
#include <stdlib.h>

#include "strlcpy.h"
#include "DRS.h"

/*------------------------------------------------------------------*/

int main()
{
   int i, j, nBoards;
   DRS *drs;
   DRSBoard *b;
   float time_array[8][1024];
   float wave_array[8][1024];
   FILE  *f;

   /* do initial scan */
   drs = new DRS();

   /* show any found board(s) */
   for (i=0 ; i<drs->GetNumberOfBoards() ; i++) {
      b = drs->GetBoard(i);
      printf("Found DRS4 evaluation board, serial #%d, firmware revision %d\n", 
         b->GetBoardSerialNumber(), b->GetFirmwareVersion());
   }

   /* exit if no board found */
   nBoards = drs->GetNumberOfBoards();
   if (nBoards == 0) {
      printf("No DRS4 evaluation board found\n");
      return 0;
   }

   /* continue working with first board only */
   b = drs->GetBoard(0);

   /* initialize board */
   b->Init();

   /* set sampling frequency */
   b->SetFrequency(5, true);

   /* enable transparent mode needed for analog trigger */
   b->SetTranspMode(1);

   /* set input range to -0.5V ... +0.5V */
   b->SetInputRange(0);

   /* use following line to set range to 0..1V */
   //b->SetInputRange(0.5);
   
   /* use following line to turn on the internal 100 MHz clock connected to all channels  */
   b->EnableTcal(1);

   /* use following lines to enable hardware trigger on CH1 at 50 mV positive edge */
   if (b->GetBoardType() >= 8) {        // Evaluaiton Board V4&5
      b->EnableTrigger(1, 0);           // enable hardware trigger
      b->SetTriggerSource(1<<0);        // set CH1 as source
   } else if (b->GetBoardType() == 7) { // Evaluation Board V3
      b->EnableTrigger(0, 1);           // lemo off, analog trigger on
      b->SetTriggerSource(0);           // use CH1 as source
   }
   b->SetTriggerLevel(0.3);            // 0.05 V
   printf("Trigger Level CHNN1: 100mV\n");
   b->SetTriggerPolarity(false);        // positive edge
   
   /* use following lines to set individual trigger elvels */
   //b->SetIndividualTriggerLevel(1, 0.1);
   //b->SetIndividualTriggerLevel(2, 0.2);
   //b->SetIndividualTriggerLevel(3, 0.3);
   //b->SetIndividualTriggerLevel(4, 0.4);
   //b->SetTriggerSource(15);
   
   b->SetTriggerDelayNs(0);             // zero ns trigger delay
   
   /* use following lines to enable the external trigger */
   //if (b->GetBoardType() == 8) {     // Evaluaiton Board V4
   //   b->EnableTrigger(1, 0);           // enable hardware trigger
   //   b->SetTriggerSource(1<<4);        // set external trigger as source
   //} else {                          // Evaluation Board V3
   //   b->EnableTrigger(1, 0);           // lemo on, analog trigger off
   // }

   /* open file to save waveforms */
   f = fopen("data.txt", "w");
   if (f == NULL) {
      perror("ERROR: Cannot open file \"data.txt\"");
      return 1;
   }
   
   /* repeat ten times */
   for (j=0 ; j<1000 ; j++) {

      /* start board (activate domino wave) */
      b->StartDomino();

      /* wait for trigger */
      printf("Waiting for trigger...");
      
      fflush(stdout);
      while (b->IsBusy());

      /* read all waveforms */
      b->TransferWaves(0, 8);

      /* read time (X) array of first channel in ns */
      b->GetTime(0, 0, b->GetTriggerCell(0), time_array[0]);

      /* decode waveform (Y) array of first channel in mV */
      b->GetWave(0, 0, wave_array[0]);

      /* read time (X) array of second channel in ns
       Note: On the evaluation board input #1 is connected to channel 0 and 1 of
       the DRS chip, input #2 is connected to channel 2 and 3 and so on. So to
       get the input #2 we have to read DRS channel #2, not #1. */
      b->GetTime(0, 2, b->GetTriggerCell(0), time_array[1]);

      /* decode waveform (Y) array of second channel in mV */
      b->GetWave(0, 2, wave_array[1]);

      /* Save waveform: X=time_array[i], Yn=wave_array[n][i] */
      fprintf(f, "Event #%d ----------------------\n  t1[ns]  u1[mV]  t2[ns] u2[mV]\n", j);
      for (i=0 ; i<1024 ; i++)
         fprintf(f, "%7.3f %7.1f %7.3f %7.1f\n", time_array[0][i], wave_array[0][i], time_array[1][i], wave_array[1][i]);

      /* print some progress indication */
      printf("\rEvent #%d read successfully\n", j);
   }

   fclose(f);
   
   /* delete DRS object -> close USB connection */
   delete drs;
}
  667   Thu Mar 8 22:54:20 2018 Rodrigo Trindade de MenezesRunning drs_example.cpp

We found a way to solve the previous problem, but right now when we try to set the input range only -0.5 to 0.5 is working. When we set the function "SetInputRange(0.5)" for 0 to 1V the output is all zeros and with  "SetInputRange(0.45)" we just get all the outputs -49.9mV. What does that means? How to fix?

odrigo Trindade de Menezes wrote:

Hello,

We have been using the DRS4 evaluation board (S/N 2636) that works with the scope application. However we are trying to run the DRS4 evaluation board remotely by modifying the drs_exam.cpp to acquire and store data continuously.

We compiled the DRS_example.cpp without the wxWidgets but when we try to run the program, it appears to trigger on nonsense.  The program appears to not be sensitive to the trigger threshold (although for very large trigger threshold it gets stuck in a waiting mode).  Is there a way to ensure that the "normal" trigger mode is set?  We are worried that the auto mode is running.  Otherwise, not sure why the program is triggering on nonsense.  By the way, it does not work with the wxWidgets compiled either so we are worried that there is an additional flag that needs to be set. The routine does not appear to conduct a calibration -- is this not necessary?

Another issue that we are having is with the data set stored on the .txt file looks incorrect.  The time channel stops at 200 (but we think it should go up to 1024). In addition, the voltage channel appears to hover around small values near zero (as if triggering on noise).  The output file appears this way even when we change the threshold to much higher values.  It suggests that the trigger threshold is not actually being set? There are events where the output voltage appears to oscillate through huge negative and positive values too.  So not sure what's going on. 

Thanks!

Rodrigo

 

  674   Mon Mar 19 15:12:02 2018 Stefan RittRunning drs_example.cpp

The time channel is already calibrated in ns. So for 5 GSPS, the time scale goes from zero to 200. Concerning your other issues I will come back to you later.

Stefan

Rodrigo Trindade de Menezes wrote:

Another issue that we are having is with the data set stored on the .txt file looks incorrect.  The time channel stops at 200 (but we think it should go up to 1024). In addition, the voltage channel appears to hover around small values near zero (as if triggering on noise).  The output file appears this way even when we change the threshold to much higher values.  It suggests that the trigger threshold is not actually being set? There are events where the output voltage appears to oscillate through huge negative and positive values too.  So not sure what's going on. 

  688   Fri May 4 12:11:57 2018 Stefan RittRunning drs_example.cpp

And here is the second part of your answer: When you change the input range, you have to redo the voltage calibration. Best is if you do that in the DRSOsc program, then you see that it's working. Then start your custom program and use the same range.

Stefan

Rodrigo Trindade de Menezes wrote:

We found a way to solve the previous problem, but right now when we try to set the input range only -0.5 to 0.5 is working. When we set the function "SetInputRange(0.5)" for 0 to 1V the output is all zeros and with  "SetInputRange(0.45)" we just get all the outputs -49.9mV. What does that means? How to fix?

odrigo Trindade de Menezes wrote:

Hello,

We have been using the DRS4 evaluation board (S/N 2636) that works with the scope application. However we are trying to run the DRS4 evaluation board remotely by modifying the drs_exam.cpp to acquire and store data continuously.

We compiled the DRS_example.cpp without the wxWidgets but when we try to run the program, it appears to trigger on nonsense.  The program appears to not be sensitive to the trigger threshold (although for very large trigger threshold it gets stuck in a waiting mode).  Is there a way to ensure that the "normal" trigger mode is set?  We are worried that the auto mode is running.  Otherwise, not sure why the program is triggering on nonsense.  By the way, it does not work with the wxWidgets compiled either so we are worried that there is an additional flag that needs to be set. The routine does not appear to conduct a calibration -- is this not necessary?

Another issue that we are having is with the data set stored on the .txt file looks incorrect.  The time channel stops at 200 (but we think it should go up to 1024). In addition, the voltage channel appears to hover around small values near zero (as if triggering on noise).  The output file appears this way even when we change the threshold to much higher values.  It suggests that the trigger threshold is not actually being set? There are events where the output voltage appears to oscillate through huge negative and positive values too.  So not sure what's going on. 

Thanks!

Rodrigo

 

 

  759   Wed Jun 26 15:17:51 2019 Si XieRunning drs_example.cpp

Hi Rodrigo, I'm wondering how you solved your original triggering problem. We are also having trouble with collecting data continously using the example. Thanks.

Rodrigo Trindade de Menezes wrote:

We found a way to solve the previous problem, but right now when we try to set the input range only -0.5 to 0.5 is working. When we set the function "SetInputRange(0.5)" for 0 to 1V the output is all zeros and with  "SetInputRange(0.45)" we just get all the outputs -49.9mV. What does that means? How to fix?

odrigo Trindade de Menezes wrote:

Hello,

We have been using the DRS4 evaluation board (S/N 2636) that works with the scope application. However we are trying to run the DRS4 evaluation board remotely by modifying the drs_exam.cpp to acquire and store data continuously.

We compiled the DRS_example.cpp without the wxWidgets but when we try to run the program, it appears to trigger on nonsense.  The program appears to not be sensitive to the trigger threshold (although for very large trigger threshold it gets stuck in a waiting mode).  Is there a way to ensure that the "normal" trigger mode is set?  We are worried that the auto mode is running.  Otherwise, not sure why the program is triggering on nonsense.  By the way, it does not work with the wxWidgets compiled either so we are worried that there is an additional flag that needs to be set. The routine does not appear to conduct a calibration -- is this not necessary?

Another issue that we are having is with the data set stored on the .txt file looks incorrect.  The time channel stops at 200 (but we think it should go up to 1024). In addition, the voltage channel appears to hover around small values near zero (as if triggering on noise).  The output file appears this way even when we change the threshold to much higher values.  It suggests that the trigger threshold is not actually being set? There are events where the output voltage appears to oscillate through huge negative and positive values too.  So not sure what's going on. 

Thanks!

Rodrigo

 

 

  398   Mon Mar 16 16:07:39 2015 Hermann-Josef MathesRunning 2 instances of a DRS DAQ program

Hi,

we want to run two instances of our little DRS DAQ program but obviously the first instance started always claims all DRS boards for itself and the other one exits with an error. The 2 boards used in the example below have the serial number # 2413 and #2414 and are v5 boards.

The first one:

mathes@ikauger5:~/src/DRS4/Cpp> ./drsdaq -b 2413
DRSController: found board with serial number #2413
DRSController: found board with serial number #2414
DRSController: using board with serial number #2413
CalibratedFrequency= 1.00721
====================================
DRS type:            DRS4
Board type:          9
Serial number:       2413
Firmware revision:   21260

...
And the second one:

mathes@ikauger5:~/src/DRS4/Cpp> ./drsdaq -b 2414
musb_open: usb_set_configuration() error -6
musb_open: Found USB device 0x04b4:0x1175 instance 0, but cannot initialize it: please check permissions on "/proc/bus/usb/1/7" and "/dev/bus/usb/1/7"
USB successfully scanned, but no boards found
...


How can our goal be achieved?

Thanks

Hermann-Josef

  399   Tue Mar 17 02:53:26 2015 Stefan RittRunning 2 instances of a DRS DAQ program

I never had in mind running two systems in parallel, that's why the code claims all interfaces when started. You have to dig into the usb code which is located in musbstd.c at function musb_open(). There you will find a line libusb_claim_interface() which requests exclusive access to the usb subsystem. The code is there because I copied it from some standard example for the libusb library. You have to read the documentation for libusb (http://libusb.sourceforge.net/api-1.0/) and see if you can get rid of that. Probaby you have to claim/release the interface on each access, but I never tried that.

Stefan

Hermann-Josef Mathes wrote:

Hi,

we want to run two instances of our little DRS DAQ program but obviously the first instance started always claims all DRS boards for itself and the other one exits with an error. The 2 boards used in the example below have the serial number # 2413 and #2414 and are v5 boards.

The first one:

mathes@ikauger5:~/src/DRS4/Cpp> ./drsdaq -b 2413
DRSController: found board with serial number #2413
DRSController: found board with serial number #2414
DRSController: using board with serial number #2413
CalibratedFrequency= 1.00721
====================================
DRS type:            DRS4
Board type:          9
Serial number:       2413
Firmware revision:   21260

...
And the second one:

mathes@ikauger5:~/src/DRS4/Cpp> ./drsdaq -b 2414
musb_open: usb_set_configuration() error -6
musb_open: Found USB device 0x04b4:0x1175 instance 0, but cannot initialize it: please check permissions on "/proc/bus/usb/1/7" and "/dev/bus/usb/1/7"
USB successfully scanned, but no boards found
...


How can our goal be achieved?

Thanks

Hermann-Josef

 

  400   Thu Mar 19 07:37:52 2015 Daniel Stricker-ShaverRunning 2 instances of a DRS DAQ program

I don't know if it helps, but we measured the time resolution between two independendly running v3 boards using a single PC (latest software) in Linux. (http://arxiv.org/abs/1405.4975)

You start the DRS DAQ program with only one USB board connected, first. Afterwards connect the second board and start another session. If you externally trigger (global) both boards with less than 1 Hz, you can garantee that both programs save the same events independently (from two individual DRS boards).

Daniel

Stefan Ritt wrote:

I never had in mind running two systems in parallel, that's why the code claims all interfaces when started. You have to dig into the usb code which is located in musbstd.c at function musb_open(). There you will find a line libusb_claim_interface() which requests exclusive access to the usb subsystem. The code is there because I copied it from some standard example for the libusb library. You have to read the documentation for libusb (http://libusb.sourceforge.net/api-1.0/) and see if you can get rid of that. Probaby you have to claim/release the interface on each access, but I never tried that.

Stefan

Hermann-Josef Mathes wrote:

Hi,

we want to run two instances of our little DRS DAQ program but obviously the first instance started always claims all DRS boards for itself and the other one exits with an error. The 2 boards used in the example below have the serial number # 2413 and #2414 and are v5 boards.

The first one:

mathes@ikauger5:~/src/DRS4/Cpp> ./drsdaq -b 2413
DRSController: found board with serial number #2413
DRSController: found board with serial number #2414
DRSController: using board with serial number #2413
CalibratedFrequency= 1.00721
====================================
DRS type:            DRS4
Board type:          9
Serial number:       2413
Firmware revision:   21260

...
And the second one:

mathes@ikauger5:~/src/DRS4/Cpp> ./drsdaq -b 2414
musb_open: usb_set_configuration() error -6
musb_open: Found USB device 0x04b4:0x1175 instance 0, but cannot initialize it: please check permissions on "/proc/bus/usb/1/7" and "/dev/bus/usb/1/7"
USB successfully scanned, but no boards found
...


How can our goal be achieved?

Thanks

Hermann-Josef

 

 

  5   Mon Feb 23 09:24:24 2009 Stefan RittRise-time measurements

Many applications using the DRS4 need to measure fast rising signals, like for PMTs or MCPs. This short note shows the minimal rise-times which can be measured with different input signal conditioning.

Evaluation Board

The evaluation board contains four passive transformers ADT1-1WT from Mini-Circuits to convert the single-ended input signal into a differential signal. Although these parts are rated 800 MHz bandwidth (-3dB), they have hard time to drive the DRS4 inputs. This is because at high frequencies the input impedance of DRS4 becomes pretty small (~20 Ohm at 500 MHz) due to its capacitive nature. Furthermore, each transformer drives two DRS4 inputs (channel cascading) which enhances this problem by a factor of two. We made a quick test sending a signal to the evaluation board with a rise time of 277ps and a fall time of 280ps. The result measured with the evaluation board is seen here:

image001.jpg

The measured rise-time (10%-90%) is only about 2ns. Disconnecting the second channel from each transformer improves this situation a bit:

single.jpg

so the rise-time comes down to ~1.6ns.

Active ADA4937 driver

We tested the behavior using an active buffer ADA4937 to replace the passive transformer. Without the DRS4 connected to this buffer, we measured with the oscilloscope a rise time of 408ps and a fall time of 644ps. When we connect the DRS4 (single channel), this values increase to 702ps (rise) and 1400ps (fall), all measured with a differential oscilloscope probe (WL300 4 GHz Bandwidth, LeCroy 7300A, 3 GHz Bandwidth). In this case the rise time seen by the DRS4 is wieth ~700ps accordingly shorter:

image003.jpg

(The signal was not properly terminated and therefore we have a small overswing). 

Conclusion

To obtain an optimal rise-time measurement, the design of the input stage is rather important. A fast active driver seems to do a better job than a passive transformer (which was used on the evaluation board for power reasons). Connecting only one DRS4 channel to the input improves the rise-time measurement significantly. If channel cascading is still needed, a design should use one driver for each channel, and not driver two or more DRS4 inputs from a single buffer.

If anybody comes up with an even better input driver, I'm happy to publish the results here.

  94   Tue Jun 22 10:50:19 2010 Jinhong WangReset of DRS4

 Hi Stefan, 

      I found DRS draw a lot of current when applied Reset after power on,  and the PLL does not work properly. I believe there was something that I misunderstood. So,  what will happen when Reset is applied more than once after power on? . Though the chip worked well without a Reset,   i want to try to find out what was wrong, for a better understanding of DRS. 

     best regards!

           Jinhong

  95   Tue Jun 22 11:02:30 2010 Stefan RittReset of DRS4

Jinhong Wang wrote:

 Hi Stefan, 

      I found DRS draw a lot of current when applied Reset after power on,  and the PLL does not work properly. I believe there was something that I misunderstood. So,  what will happen when Reset is applied more than once after power on? . Though the chip worked well without a Reset,   i want to try to find out what was wrong, for a better understanding of DRS. 

     best regards!

           Jinhong

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

  96   Tue Jun 22 11:29:26 2010 Jinhong WangReset of DRS4

Stefan Ritt wrote:

Jinhong Wang wrote:

 Hi Stefan, 

      I found DRS draw a lot of current when applied Reset after power on,  and the PLL does not work properly. I believe there was something that I misunderstood. So,  what will happen when Reset is applied more than once after power on? . Though the chip worked well without a Reset,   i want to try to find out what was wrong, for a better understanding of DRS. 

     best regards!

           Jinhong

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

 Yes, they are stay low until Reset goes high. the process is as following

   Step1: Reset ='1', DEnable ='0', DWrite ='0', Reg_addr ="1111", Rsload='0', Srin ='0'

  Step2: Reset='0', the others do not change, the low of the pulse is longer than 10 ns.

  Step3: Reset='1', the others do not change, wait for some time

  Step4:  DEnable ='1' to start the domino.

  97   Tue Jun 22 11:35:18 2010 Stefan RittReset of DRS4

Jinhong Wang wrote:

Stefan Ritt wrote:

Jinhong Wang wrote:

 Hi Stefan, 

      I found DRS draw a lot of current when applied Reset after power on,  and the PLL does not work properly. I believe there was something that I misunderstood. So,  what will happen when Reset is applied more than once after power on? . Though the chip worked well without a Reset,   i want to try to find out what was wrong, for a better understanding of DRS. 

     best regards!

           Jinhong

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

 Yes, they are stay low until Reset goes high. the process is as following

   Step1: Reset ='1', DEnable ='0', DWrite ='0', Reg_addr ="1111", Rsload='0', Srin ='0'

  Step2: Reset='0', the others do not change, the low of the pulse is longer than 10 ns.

  Step3: Reset='1', the others do not change, wait for some time

  Step4:  DEnable ='1' to start the domino.

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... 

  98   Tue Jun 22 11:37:42 2010 Jinhong WangReset of DRS4

Stefan Ritt wrote:

Jinhong Wang wrote:

Stefan Ritt wrote:

Jinhong Wang wrote:

 Hi Stefan, 

      I found DRS draw a lot of current when applied Reset after power on,  and the PLL does not work properly. I believe there was something that I misunderstood. So,  what will happen when Reset is applied more than once after power on? . Though the chip worked well without a Reset,   i want to try to find out what was wrong, for a better understanding of DRS. 

     best regards!

           Jinhong

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

 Yes, they are stay low until Reset goes high. the process is as following

   Step1: Reset ='1', DEnable ='0', DWrite ='0', Reg_addr ="1111", Rsload='0', Srin ='0'

  Step2: Reset='0', the others do not change, the low of the pulse is longer than 10 ns.

  Step3: Reset='1', the others do not change, wait for some time

  Step4:  DEnable ='1' to start the domino.

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... 

    Ok ,thank you. 

ELOG V3.1.5-3fb85fa6