DRS4 Forum
  DRS4 Discussion Forum, Page 9 of 45  Not logged in ELOG logo
ID Date Author Subjectup
  69   Sun May 2 18:36:14 2010 Ignacio Diéguez EstremeraDRS4 chip model

Hi all,

i'm an electronics engineering student at UCM (Madrid) working on my master's thesis within the CTA collaboration. I'm designing the readout electronics for the telescope's camera, and i'm focusing in using GAPDs instead of PMTs and using the domino chip for the sampling of the signal. I was wondering if there is a spice and/or RF model of the DRS4 chip available. It would be very useful to perform some simulations before deciding to use the chip as the sampling solution for our prototypes.

If the answer is negative, can you give me some advise for modelling the chip in spice? Have you done any simulations?

Thanks in advance,

Ignacio Diéguez Estremera.

  70   Mon May 3 11:09:12 2010 Stefan RittDRS4 chip model

Ignacio Diéguez Estremera wrote:

Hi all,

i'm an electronics engineering student at UCM (Madrid) working on my master's thesis within the CTA collaboration. I'm designing the readout electronics for the telescope's camera, and i'm focusing in using GAPDs instead of PMTs and using the domino chip for the sampling of the signal. I was wondering if there is a spice and/or RF model of the DRS4 chip available. It would be very useful to perform some simulations before deciding to use the chip as the sampling solution for our prototypes.

If the answer is negative, can you give me some advise for modelling the chip in spice? Have you done any simulations?

Thanks in advance,

Ignacio Diéguez Estremera.

Yes there is a transistor-level spice model, which I used to design the chip, but you won't be happy with it: Given the 500,000+ transistors on the chip, a 100 ns simulation takes a couple of weeks. We tried to make a simplified model just for the analog input using some measured S-parameters, but found that the RF behavior of the chip is almost impossible to describe to better than let's say 50%. In the end you have to fine-tune your analog front-end experimentally, to obtain optimal bandwidth. We are just working on a reference design with gives you 850 MHz bandwidth using an active input buffer.

  71   Mon May 3 17:06:02 2010 Ignacio Diéguez EstremeraDRS4 chip model

Stefan Ritt wrote:

Ignacio Diéguez Estremera wrote:

Hi all,

i'm an electronics engineering student at UCM (Madrid) working on my master's thesis within the CTA collaboration. I'm designing the readout electronics for the telescope's camera, and i'm focusing in using GAPDs instead of PMTs and using the domino chip for the sampling of the signal. I was wondering if there is a spice and/or RF model of the DRS4 chip available. It would be very useful to perform some simulations before deciding to use the chip as the sampling solution for our prototypes.

If the answer is negative, can you give me some advise for modelling the chip in spice? Have you done any simulations?

Thanks in advance,

Ignacio Diéguez Estremera.

Yes there is a transistor-level spice model, which I used to design the chip, but you won't be happy with it: Given the 500,000+ transistors on the chip, a 100 ns simulation takes a couple of weeks. We tried to make a simplified model just for the analog input using some measured S-parameters, but found that the RF behavior of the chip is almost impossible to describe to better than let's say 50%. In the end you have to fine-tune your analog front-end experimentally, to obtain optimal bandwidth. We are just working on a reference design with gives you 850 MHz bandwidth using an active input buffer.

 Thanks for the information.

I would like to try the huge :-) model. Can you send it to my email address? Since the input signal are pulses of a few nanoseconds at FHWM, the simulation time may be reduced. I will post some feedback in the forum once i give it a try.

Kind regards.

  72   Mon May 3 17:10:29 2010 Stefan RittDRS4 chip model

Ignacio Diéguez Estremera wrote:

Stefan Ritt wrote:

Ignacio Diéguez Estremera wrote:

Hi all,

i'm an electronics engineering student at UCM (Madrid) working on my master's thesis within the CTA collaboration. I'm designing the readout electronics for the telescope's camera, and i'm focusing in using GAPDs instead of PMTs and using the domino chip for the sampling of the signal. I was wondering if there is a spice and/or RF model of the DRS4 chip available. It would be very useful to perform some simulations before deciding to use the chip as the sampling solution for our prototypes.

If the answer is negative, can you give me some advise for modelling the chip in spice? Have you done any simulations?

Thanks in advance,

Ignacio Diéguez Estremera.

Yes there is a transistor-level spice model, which I used to design the chip, but you won't be happy with it: Given the 500,000+ transistors on the chip, a 100 ns simulation takes a couple of weeks. We tried to make a simplified model just for the analog input using some measured S-parameters, but found that the RF behavior of the chip is almost impossible to describe to better than let's say 50%. In the end you have to fine-tune your analog front-end experimentally, to obtain optimal bandwidth. We are just working on a reference design with gives you 850 MHz bandwidth using an active input buffer.

 Thanks for the information.

I would like to try the huge :-) model. Can you send it to my email address? Since the input signal are pulses of a few nanoseconds at FHWM, the simulation time may be reduced. I will post some feedback in the forum once i give it a try.

Kind regards.

I just checked and realized that we are not allowed to give out the "huge" model since it contains parameters from the chip manufacturer's library which are confidentially. 

  73   Mon May 3 23:21:55 2010 Ignacio Diéguez EstremeraDRS4 chip model

Stefan Ritt wrote:

Ignacio Diéguez Estremera wrote:

Stefan Ritt wrote:

Ignacio Diéguez Estremera wrote:

Hi all,

i'm an electronics engineering student at UCM (Madrid) working on my master's thesis within the CTA collaboration. I'm designing the readout electronics for the telescope's camera, and i'm focusing in using GAPDs instead of PMTs and using the domino chip for the sampling of the signal. I was wondering if there is a spice and/or RF model of the DRS4 chip available. It would be very useful to perform some simulations before deciding to use the chip as the sampling solution for our prototypes.

If the answer is negative, can you give me some advise for modelling the chip in spice? Have you done any simulations?

Thanks in advance,

Ignacio Diéguez Estremera.

Yes there is a transistor-level spice model, which I used to design the chip, but you won't be happy with it: Given the 500,000+ transistors on the chip, a 100 ns simulation takes a couple of weeks. We tried to make a simplified model just for the analog input using some measured S-parameters, but found that the RF behavior of the chip is almost impossible to describe to better than let's say 50%. In the end you have to fine-tune your analog front-end experimentally, to obtain optimal bandwidth. We are just working on a reference design with gives you 850 MHz bandwidth using an active input buffer.

 Thanks for the information.

I would like to try the huge :-) model. Can you send it to my email address? Since the input signal are pulses of a few nanoseconds at FHWM, the simulation time may be reduced. I will post some feedback in the forum once i give it a try.

Kind regards.

I just checked and realized that we are not allowed to give out the "huge" model since it contains parameters from the chip manufacturer's library which are confidentially. 

 Thank you for the effort anyway.

So i guess i won't be able to include drs4 in my simulations :-(. Any other suggestions? Maybe the S-params model you where working on? Anything is better than nothing :-)

  74   Tue May 4 11:26:21 2010 Stefan RittDRS4 chip model

Ignacio Diéguez Estremera wrote:

So i guess i won't be able to include drs4 in my simulations :-(. Any other suggestions? Maybe the S-params model you where working on? Anything is better than nothing :-)

Please find attached the S-parameters. 

Attachment 1: DRS4_S-Parameter.pdf
DRS4_S-Parameter.pdf DRS4_S-Parameter.pdf
  75   Tue May 4 16:23:16 2010 Ignacio Diéguez EstremeraDRS4 chip model

Stefan Ritt wrote:

Ignacio Diéguez Estremera wrote:

So i guess i won't be able to include drs4 in my simulations :-(. Any other suggestions? Maybe the S-params model you where working on? Anything is better than nothing :-)

Please find attached the S-parameters. 

 Thanks :-)

  78   Wed May 12 11:47:39 2010 Jinhong WangDRS4 chip model

Stefan Ritt wrote:

Ignacio Diéguez Estremera wrote:

So i guess i won't be able to include drs4 in my simulations :-(. Any other suggestions? Maybe the S-params model you where working on? Anything is better than nothing :-)

Please find attached the S-parameters. 

 Hi, we plan to do a time interpolating among the eight channels on a single chip to obtain a maximum 40 GSPS (or, maybe 30 GSPS ) sampling rate.  Hence RF behavior of the anlog input is very important for us.

Will you give us some advice on the modeling of  the anlog input circuit of the chip?  Perhaps just the Spice model of the analog input?

The attached S parameters I found  here is for fs =1 GSPS, what about fs=5GSPS?

thanks in advance,

                                                                               Jinhong Wang (wangjinh@mail.ustc.edu.cn  ;  alleyor.wang@gmail.com)

  79   Wed May 12 16:26:12 2010 Stefan RittDRS4 chip model

Jinhong Wang wrote:

Stefan Ritt wrote:

Ignacio Diéguez Estremera wrote:

So i guess i won't be able to include drs4 in my simulations :-(. Any other suggestions? Maybe the S-params model you where working on? Anything is better than nothing :-)

Please find attached the S-parameters. 

 Hi, we plan to do a time interpolating among the eight channels on a single chip to obtain a maximum 40 GSPS (or, maybe 30 GSPS ) sampling rate.  Hence RF behavior of the anlog input is very important for us.

Will you give us some advice on the modeling of  the anlog input circuit of the chip?  Perhaps just the Spice model of the analog input?

The attached S parameters I found  here is for fs =1 GSPS, what about fs=5GSPS?

thanks in advance,

                                                                               Jinhong Wang (wangjinh@mail.ustc.edu.cn  ;  alleyor.wang@gmail.com)

To be honest, we never really succeeded to do any good simulation above let's say 500 MHz. We carefully tried to simulate the bond wire of the chip, the parasitic capacitances of the traces of the chip etc. but we always were off by a factor or two or so. Other groups reported the same problems. Some even did some 3D simulation model, without success. So our conclusion is that if you are interested in anything precise above 500 MHz, do a measurement.

So our current best design is with the THS4508. There is an AC coupled version going to 600 MHz, and a DC coupled version (uses more power) going to 800 MHz (-3dB). If you use passive inputs with a transformer for example, you can't go above 220 MHz. Next week I will publish both designs in this forum.

  728   Wed Jan 30 06:51:37 2019 Saurabh NeemaDRS4 domino wave stability study

We have been using DRS4 IC in our design for quite some time and it is giving good performance.

Till now we were using Domino wave frequency as 1 GSPS by use of reference clock to DRS4 and internal PLL of DRS4. Recently we tried to use 4GSPS by modifying the reference clock.

What I have found that DRS4 domino wave is more stable at 4 GSPS as compared to 1 GSPS by doing the timing jitter analysis. I am not sure if it is the property of DRS4 IC to be having more stable domino wave at higher frequency (by design) or it is due to some external effects like PLL loop filter or any other on board parasitic effects.

Please share if anyone has done any study of DRS4 Domino wave stability at different sampling frequencies.

Thanks,

 

  729   Wed Jan 30 08:02:25 2019 Stefan RittDRS4 domino wave stability study

The Domino wave is most stable at 5 GSPS, slowly degrades down to 3-2 GSPS, and at 1GSPS gets some significant jitter. This is for internal reasons in the chip and cannot be compensated by the loop filter. It is therefore important to run it as fast as possible if you want to achieve best timing resolution. As a rule of thumb, the jitter at 5 GSPS is about 20-25 ps, and at 1 GSPS it is maybe 150 ps. If you require good timing resolution, you can use the 9th channel to sample a stable reference clock (100 MHz for example) and measure timing relative to that clock. This way you can bring down the resolution to a few ps at 5GSPS and to maybe 40 ps at 1 GSPS.

Stefan

Saurabh Neema wrote:

We have been using DRS4 IC in our design for quite some time and it is giving good performance.

Till now we were using Domino wave frequency as 1 GSPS by use of reference clock to DRS4 and internal PLL of DRS4. Recently we tried to use 4GSPS by modifying the reference clock.

What I have found that DRS4 domino wave is more stable at 4 GSPS as compared to 1 GSPS by doing the timing jitter analysis. I am not sure if it is the property of DRS4 IC to be having more stable domino wave at higher frequency (by design) or it is due to some external effects like PLL loop filter or any other on board parasitic effects.

Please share if anyone has done any study of DRS4 Domino wave stability at different sampling frequencies.

Thanks,

 

 

  592   Wed Apr 5 12:40:16 2017 Martin PetriskaDRS4 eval board v4 coincidence firmware changes for triger for short pulses

I would like to implement fpga firmware changes for DRS4 eval board v4 to put there posibility for standard coincidence (for example to get triger on two short (5ns pulses from Plastic scintilator) in 100ns coincidence window), Similar but more complex was done for eval v.5 boards ( https://forge.physik.rwth-aachen.de/projects/drs4-rwth ) Im beginner in state of FPGA design, but hope it will be not so dificult to implement same functionality in eval4 board. Is there any SVN server with firmware sources for evaluation board? Im litle bit confused with different firmware sources in linux and windows installation packages, For example whose are last eval4 board firmware souces ? (There are some eval4 sources in  5.0.6 files, but not sure if its workable)

May be didnt make same changes already?  

  594   Mon Apr 10 10:48:03 2017 Stefan RittDRS4 eval board v4 coincidence firmware changes for triger for short pulses

You have to download the package for your board, which then includes also the correct firmware for your board. If you have a V4 board, your firmware is in drs-4.0.2.tar.gz which you can download from Dropbox at https://www.dropbox.com/sh/clqo7ekr0ysbrip/AACoWJzrQAbf3WiBJHG89bGGa?dl=0

Martin Petriska wrote:

I would like to implement fpga firmware changes for DRS4 eval board v4 to put there posibility for standard coincidence (for example to get triger on two short (5ns pulses from Plastic scintilator) in 100ns coincidence window), Similar but more complex was done for eval v.5 boards ( https://forge.physik.rwth-aachen.de/projects/drs4-rwth ) Im beginner in state of FPGA design, but hope it will be not so dificult to implement same functionality in eval4 board. Is there any SVN server with firmware sources for evaluation board? Im litle bit confused with different firmware sources in linux and windows installation packages, For example whose are last eval4 board firmware souces ? (There are some eval4 sources in  5.0.6 files, but not sure if its workable)

May be didnt make same changes already?  

 

  132   Sat Oct 15 04:45:25 2011 Aurelien BouvierDRS4 eval board: readout rate

Hi,

Our setup uses a DRS4 evaluation board (version 2.0).

Although we trigger the board at a rate of ~4kHz (on channel2), readout through USB2 is only happening at a rate of ~125Hz.

After some investigation, we could pin down that it is due to the time it takes to complete the following commands: musb_write() and musb_read() which both take ~150 microsecond to complete. Because they are called multiple times, reading out 1 trigger takes ~8 millisecond which explains the 125Hz we're seeing.

Is ~150 us to complete a musb_read()/musb_write() command expected?

Is there any way we could speed up the readout rate of the DRS4 board so that data acquisition through USB2 is closer to our trigger rate of 4kHz?

Any feedback you might have on this topic would be greatly appreciated.

Many thanks,

Aurelien

  133   Sat Oct 22 00:40:02 2011 Stefan RittDRS4 eval board: readout rate

Aurelien Bouvier wrote:

Hi,

Our setup uses a DRS4 evaluation board (version 2.0).

Although we trigger the board at a rate of ~4kHz (on channel2), readout through USB2 is only happening at a rate of ~125Hz.

After some investigation, we could pin down that it is due to the time it takes to complete the following commands: musb_write() and musb_read() which both take ~150 microsecond to complete. Because they are called multiple times, reading out 1 trigger takes ~8 millisecond which explains the 125Hz we're seeing.

Is ~150 us to complete a musb_read()/musb_write() command expected?

Is there any way we could speed up the readout rate of the DRS4 board so that data acquisition through USB2 is closer to our trigger rate of 4kHz?

Any feedback you might have on this topic would be greatly appreciated.

Many thanks,

Aurelien

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

 

  186   Thu Nov 1 20:08:33 2012 hongwei yangDRS4 firmware

Hi,

    We are using drs4 board, but oscilloscope app will somehow stop to work if we config trigger into "or and", When I look into the drs4 firmware file drs4_eval3_app.vhd, I couldn't find the trigger_config value assignment which is mentioned at(#7 offset 0x1E from 31 downto 16) in manual_version 4.

could you help me find this trigger_config access point? Or is there any drs4_eval4_app.vhd missing in the source files?

 

thanks

 

Hongwei

  187   Thu Nov 1 20:17:42 2012 Stefan RittDRS4 firmware

hongwei yang wrote:

Hi,

    We are using drs4 board, but oscilloscope app will somehow stop to work if we config trigger into "or and", When I look into the drs4 firmware file drs4_eval3_app.vhd, I couldn't find the trigger_config value assignment which is mentioned at(#7 offset 0x1E from 31 downto 16) in manual_version 4.

could you help me find this trigger_config access point?

 

thanks

 

Hongwei

The "and" in the trigger section means now "coincidence". So the V4 board can trigger on a coincidence between two or more channels. If there is no pulse at the same time on the coincidence channels, the board will of course not trigger. The according firmware was introduced in V4, so please look at drs4_eval4_app.vhd (not eval3).

I just realized that the V4 firmware might be missing in the distribution, so I have attached it here. Look for drs_ctl_trigger_config.

 

Best regards,

Stefan

Attachment 1: drs4_eval4_app.vhd
--*************************************************************
-- Author   : Boris Keil, Stefan Ritt
-- Contents : Main file for DRS4 control and readout
-- $Id: drs4_eval4_app.vhd 15159 2010-04-29 10:12:25Z ritt $
-- $Revision: 15159 $
--*************************************************************

library ieee;
use ieee.std_logic_1164.all;
-- use ieee.std_logic_arith.all;
use ieee.std_logic_unsigned.all;
use ieee.numeric_std.all;
-- synopsys translate_off
library UNISIM;
use UNISIM.Vcomponents.ALL;
-- synopsys translate_on
use work.drs4_pack.all;

entity drs4_eval4_app is
  port (
    -- clocks
    I_CLK33                 : in std_logic;
    I_CLK66                 : in std_logic;
    I_CLK132                : in std_logic;
    I_CLK264                : in std_logic;
    O_CLK_PS_VALUE          : out std_logic_vector(7 downto 0);
    I_CLK_PS                : in std_logic;
    I_RESET                 : in std_logic; -- active high power-up reset

    -- analog triggers
    I_ANA_TRG               : in std_logic_vector(3 downto 0);
    
    -- external trigger
    IO_ETRG_IN              : inout std_logic;
    O_ETRG_IND              : out std_logic;

    IO_ETRG_OUT             : inout std_logic;
    O_ETRG_OUTD             : out std_logic;

    -- external (MMCX clock) clock
    IO_ECLK_OUT             : inout std_logic;
    IO_ECLK_IN              : inout std_logic;

    -- PMC
    P_IO_PMC_USR            : inout std_logic_vector(63 downto 0);

    -- Simple bus interface to DPRAM
    O_DPRAM_CLK             : out std_logic;
    O_DPRAM_ADDR            : out std_logic_vector(31 downto 0);
    O_DPRAM_D_WR            : out std_logic_vector(31 downto 0);
    O_DPRAM_WE              : out std_logic;
    I_DPRAM_D_RD            : in std_logic_vector(31 downto 0);

    -- Control & status registers from system FPGA interface
    I_CONTROL_REG_ARR       : in  type_control_reg_arr;
    O_STATUS_REG_ARR        : out type_status_reg_arr;
    I_CONTROL_TRIG_ARR      : in  type_control_trig_arr;
    I_CONTROL0_BIT_TRIG_ARR : in  std_logic_vector(31 downto 0);

    -- LEDs signals
    O_LED_RED               : out std_logic;
    O_LED_YELLOW            : out std_logic;
    
    -- Debug signals
    O_DEBUG1                : out std_logic;
    O_DEBUG2                : out std_logic
  );
end drs4_eval4_app;

--*************************************************************

architecture arch of drs4_eval4_app is

  attribute BOX_TYPE : string;

  component USR_LIB_VEC_FDC
    generic (
      width :     integer := 1
      );
    port (
      I_CLK  : in std_logic_vector (width-1 downto 0);
      I_CLR  : in std_logic_vector (width-1 downto 0);
      I      : in std_logic_vector (width-1 downto 0);
      O      : out std_logic_vector (width-1 downto 0)
      );
  end component;

  component USR_LIB_VEC_IOFD_CPE_NALL
    generic (
      width             :     integer := 1;
      init_val_to_pad   :     string  := "0";
      init_val_from_pad :     string  := "0"
      );
    port (
      O_C   : in  std_logic_vector (width-1 downto 0);
      O_CE  : in  std_logic_vector (width-1 downto 0);
      O_CLR : in  std_logic_vector (width-1 downto 0);
      O_PRE : in  std_logic_vector (width-1 downto 0);
      O     : out std_logic_vector (width-1 downto 0);

      I_C   : in std_logic_vector (width-1 downto 0);
      I_CE  : in std_logic_vector (width-1 downto 0);
      I_CLR : in std_logic_vector (width-1 downto 0);
      I_PRE : in std_logic_vector (width-1 downto 0);
      I     : in std_logic_vector (width-1 downto 0);

      IO : inout std_logic_vector (width-1 downto 0);
      T  : in    std_logic_vector (width-1 downto 0)
      );
  end component;

  component OFDDRTCPE
    port (
      O : out STD_ULOGIC;
      C0 : in STD_ULOGIC;
      C1 : in STD_ULOGIC;
      CE : in STD_ULOGIC;
      CLR : in STD_ULOGIC;
      D0 : in STD_ULOGIC;
      D1 : in STD_ULOGIC;
      PRE : in STD_ULOGIC;
      T : in STD_ULOGIC
    );
  end component;
  attribute BOX_TYPE of OFDDRTCPE : component is "PRIMITIVE";

  component IOBUFDS
    port (
      O : out STD_ULOGIC;
      IO : inout STD_ULOGIC;
      IOB : inout STD_ULOGIC;
      I : in STD_ULOGIC;
      T : in STD_ULOGIC
    );
  end component;
  
  component LUT1
    generic (
      INIT : bit_vector
    );
    port(
      O : out STD_ULOGIC;
      I0 : in STD_ULOGIC
    );
  end component;  
  
  signal GND  : std_logic;
  signal VCC  : std_logic;

  -- ADC
  signal i_drs_adc               : std_logic_vector(13 downto 0);
  signal o_drs_adc_clk           : std_logic;
  signal adc_clk_sr              : std_logic_vector(15 downto 0);
  -- Serial interface for DAC, EEPROM and Temp. Sensor
  signal o_drs_serial_data       : std_logic;
  signal o_drs_serial_clk        : std_logic;
  signal i_drs_serial_data       : std_logic;
  signal i_drs_eeprom_data       : std_logic;
  signal o_drs_dac_cs_n          : std_logic;
  signal o_drs_eeprom_cs_n       : std_logic;
  signal o_drs_tempsens_cs_n     : std_logic;
  -- Status LED
  signal drs_led_yellow          : std_logic;
  signal drs_led_trigger         : std_logic;
  signal drs_led_counter         : std_logic_vector(20 downto 0);
  type type_drs_led_state is (led_idle, led_on, led_off);
  signal drs_led_state           : type_drs_led_state;
  -- DRS Start/enable
  signal o_drs_enable            : std_logic;
  signal o_drs_write             : std_logic;
  -- Internal DRS shift registers
  signal o_drs_srin              : std_logic;
  signal o_drs_srclk             : std_logic;
  signal o_drs_rsrload           : std_logic;
  signal i_drs_srout             : std_logic;
  signal i_drs_wsrout            : std_logic;
  subtype type_sr_count is integer range 0 to 1024;
  signal drs_sr_count            : type_sr_count;
  signal drs_sr_reg              : std_logic_vector(7 downto 0);
  -- DRS address
  signal o_drs_addr              : std_logic_vector(3 downto 0);
  -- PLL refence clock signal
  signal drs_refclk              : std_logic;
  signal o_drs_refclk            : std_logic;
  signal drs_refclk_counter      : std_logic_vector(16 downto 0);
  signal i_drs_plllck            : std_logic;
  signal i_drs_dtap              : std_logic;
  -- 132/264 MHz calibration signal output
  signal o_drs_tcalib_sig        : std_logic;
  -- internal amplitude calibration via input multiplexers
  signal o_drs_aswitches         : std_logic;
  -- power signal for chip test board
  signal o_drs_on                : std_logic;
  
  -- Control registers
  signal drs_ctl_start_trig      : std_logic;
  signal drs_ctl_reinit_trig     : std_logic;  -- 1 sets drs_reinit_reqest to '1'
  signal drs_ctl_soft_trig       : std_logic;
  signal drs_ctl_eeprom_write_trig: std_logic;
  signal drs_ctl_eeprom_read_trig: std_logic;
  signal drs_ctl_autostart       : std_logic;
  signal drs_ctl_dmode           : std_logic;
  signal drs_ctl_dactive         : std_logic;
  signal drs_ctl_adc_active      : std_logic;
  signal drs_ctl_acalib          : std_logic;
  signal drs_ctl_led_red         : std_logic;
  signal drs_ctl_tcal_en         : std_logic;
  signal drs_ctl_tcal_source     : std_logic;
  signal drs_ctl_refclk_source   : std_logic;
  type type_drs_dac_val_arr is array (7 downto 0) of std_logic_vector(15 downto 0);
  signal drs_ctl_dac_arr         : type_drs_dac_val_arr;
  signal drs_ctl_first_chn       : std_logic_vector(3 downto 0);
  signal drs_ctl_last_chn        : std_logic_vector(3 downto 0);
  signal drs_ctl_config          : std_logic_vector(7 downto 0);
  signal drs_ctl_chn_config      : std_logic_vector(7 downto 0);
  signal drs_ctl_sampling_freq   : std_logic_vector(15 downto 0);
  signal drs_ctl_transp_mode     : std_logic;
  signal drs_ctl_standby_mode    : std_logic;
  signal drs_ctl_enable_trigger  : std_logic;
  signal drs_ctl_trigger_config  : std_logic_vector(15 downto 0);
  signal drs_ctl_neg_trigger     : std_logic;
  signal drs_ctl_readout_mode    : std_logic;
  signal drs_ctl_delay_sel       : std_logic_vector(7 downto 0);

  -- Status registers
  signal drs_stat_busy           : std_logic;
  signal drs_eeprom_busy         : std_logic;
  signal drs_stat_stop_cell      : std_logic_vector(9 downto 0);
  signal drs_stat_stop_wsr       : std_logic_vector(7 downto 0);
  signal drs_temperature         : std_logic_vector(15 downto 0);
  signal drs_trigger_bus         : std_logic_vector(15 downto 0);
  signal drs_serial_number       : std_logic_vector(15 downto 0);
  signal svn_revision            : std_logic_vector(15 downto 0);

  -- Misc. internal signals
  signal drs_reinit_request      : std_logic;
  signal drs_old_readout_mode    : std_logic;

  -- Trigger signals
  signal drs_trigger             : std_logic;
  signal drs_soft_trig           : std_logic;
  signal drs_trigger_syn         : std_logic;
  signal drs_write_set           : std_logic;
  signal drs_trig_ff             : std_logic;
  signal drs_write_ff            : std_logic;
  signal drs_hard_inp            : std_logic_vector(4 downto 0);
  signal drs_hard_or             : std_logic;
  signal drs_hard_and            : std_logic;
  signal drs_hard_trig           : std_logic;
  signal drs_arm_trig            : std_logic;
  signal drs_trg_delay           : std_logic_vector(2047 downto 0);
  -- Tell P&R to not optimize away the drs_trg_delay array
  attribute keep : string;
  attribute keep of drs_trg_delay : signal is "true";

  -- Serial bus internal signals
  type type_serial_bus_state is (idle, wait_serdes, eeprom_read, eeprom_write, done);
  signal serial_bus_state        : type_serial_bus_state;
  subtype type_serial_count is integer range 0 to 200;
  signal serial_count            : type_serial_count;
  signal serial_ret_addr         : type_serial_count;
  signal serial_start_flag1      : std_logic;
  signal serial_start_flag2      : std_logic;

  type type_serdes_state is (idle, busy, busy_temp);
  signal serdes_state            : type_serdes_state;
  subtype type_serdes_clk is integer range 0 to 10;
  signal serdes_clk              : type_serdes_clk;
  signal serdes_speed            : type_serdes_clk;
  subtype type_serdes_count is integer range 0 to 100;
  signal serdes_count            : type_serdes_count;
  subtype type_serdes_bit_count_m1 is integer range 0 to 32;
  signal serdes_bit_count_m1        : type_serdes_bit_count_m1;
  signal serdes_bit_no           : type_serdes_bit_count_m1;
  signal serdes_trig             : std_logic;
  signal serdes_trig_temp        : std_logic;
  signal serdes_wdata            : std_logic_vector(31 downto 0);
  signal serdes_rdata            : std_logic_vector(31 downto 0);

  type   type_drs_dac_reg is array (7 downto 0) of std_logic_vector(15 downto 0);
  signal drs_dac_reg             : type_drs_dac_reg;
  signal drs_dac_newval_flag     : std_logic_vector(7 downto 0);
  subtype type_dac_bit_count is integer range 0 to 31;

  signal temp                    : std_logic_vector(15 downto 0);
  signal temp_timer              : std_logic_vector(25 downto 0); -- once per second
  signal temp_cmd                : std_logic_vector(7 downto 0);

  subtype type_eeprom_count is integer range 0 to 100;
  signal drs_eeprom_write_trig   : std_logic;
  signal drs_eeprom_read_trig    : std_logic;
  signal drs_eeprom_sector       : std_logic_vector(15 downto 0);
  signal drs_eeprom_page         : std_logic_vector(7 downto 0);  
  signal drs_eeprom_byte         : std_logic_vector(7 downto 0);  
  signal drs_eeprom_cmd          : std_logic_vector(59 downto 0);

  -- PMC IO pin control signals
  signal pmc_clk_i : std_logic_vector(P_IO_PMC_USR'range);  -- input FF clock
  signal pmc_ce_i  : std_logic_vector(P_IO_PMC_USR'range);  -- input FF clock enable
  signal pmc_clr_i : std_logic_vector(P_IO_PMC_USR'range);  -- input FF async clear
... 1459 more lines ...
  188   Thu Nov 1 20:21:44 2012 hongwei yangDRS4 firmware

Stefan Ritt wrote:

hongwei yang wrote:

Hi,

    We are using drs4 board, but oscilloscope app will somehow stop to work if we config trigger into "or and", When I look into the drs4 firmware file drs4_eval3_app.vhd, I couldn't find the trigger_config value assignment which is mentioned at(#7 offset 0x1E from 31 downto 16) in manual_version 4.

could you help me find this trigger_config access point?

 

thanks

 

Hongwei

The "and" in the trigger section means now "coincidence". So the V4 board can trigger on a coincidence between two or more channels. If there is no pulse at the same time on the coincidence channels, the board will of course not trigger. The according firmware was introduced in V4, so please look at drs4_eval4_app.vhd (not eval3).

I just realized that the V4 firmware might be missing in the distribution, so I have attached it here. Look for drs_ctl_trigger_config.

 

Best regards,

Stefan

 Ah, great, that helps, Thank you!

 

Hongwei

  189   Thu Nov 1 20:25:53 2012 hongwei yangDRS4 firmware

hongwei yang wrote:

Stefan Ritt wrote:

hongwei yang wrote:

Hi,

    We are using drs4 board, but oscilloscope app will somehow stop to work if we config trigger into "or and", When I look into the drs4 firmware file drs4_eval3_app.vhd, I couldn't find the trigger_config value assignment which is mentioned at(#7 offset 0x1E from 31 downto 16) in manual_version 4.

could you help me find this trigger_config access point?

 

thanks

 

Hongwei

The "and" in the trigger section means now "coincidence". So the V4 board can trigger on a coincidence between two or more channels. If there is no pulse at the same time on the coincidence channels, the board will of course not trigger. The according firmware was introduced in V4, so please look at drs4_eval4_app.vhd (not eval3).

I just realized that the V4 firmware might be missing in the distribution, so I have attached it here. Look for drs_ctl_trigger_config.

 

Best regards,

Stefan

 Ah, great, that helps, Thank you!

 

Hongwei

 By the way, will there be a drs4_eval4.vhd as well?

  190   Thu Nov 1 20:32:03 2012 Stefan RittDRS4 firmware

hongwei yang wrote:

hongwei yang wrote:

Stefan Ritt wrote:

hongwei yang wrote:

Hi,

    We are using drs4 board, but oscilloscope app will somehow stop to work if we config trigger into "or and", When I look into the drs4 firmware file drs4_eval3_app.vhd, I couldn't find the trigger_config value assignment which is mentioned at(#7 offset 0x1E from 31 downto 16) in manual_version 4.

could you help me find this trigger_config access point?

 

thanks

 

Hongwei

The "and" in the trigger section means now "coincidence". So the V4 board can trigger on a coincidence between two or more channels. If there is no pulse at the same time on the coincidence channels, the board will of course not trigger. The according firmware was introduced in V4, so please look at drs4_eval4_app.vhd (not eval3).

I just realized that the V4 firmware might be missing in the distribution, so I have attached it here. Look for drs_ctl_trigger_config.

 

Best regards,

Stefan

 Ah, great, that helps, Thank you!

 

Hongwei

 By the way, will there be a drs4_eval4.vhd as well?

 Here it is.

Attachment 1: drs4_eval4.vhd
--#############################################################
-- Author   : Stefan Ritt
-- Contents : DRS4 Evaluation Board FPGA top level entity
-- $Id: drs4_eval4.vhd 13988 2009-08-03 15:28:19Z ritt $
--#############################################################

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
use work.drs4_pack.all;

entity drs4_eval4 is
  port (
    -- Quartz
    P_I_CLK33                  : in  std_logic;
    P_I_CLK66                  : in  std_logic;
    
    -- Test points
    P_IO_J45                   : inout std_logic; 
    P_IO_J46                   : inout std_logic; 
    P_I_J47                    : in std_logic; 
    P_IO_J48                   : inout std_logic; 
    P_IO_J49                   : inout std_logic; 
    
    -- analog triggers
    P_I_ATRG1                  : in std_logic;
    P_I_ATRG2                  : in std_logic;
    P_I_ATRG3                  : in std_logic;
    P_I_ATRG4                  : in std_logic;
    
    -- external trigger
    P_IO_ETRG_IN               : inout std_logic;
    P_O_ETRG_IND               : out std_logic;

    P_IO_ETRG_OUT              : inout std_logic;
    P_O_ETRG_OUTD              : out std_logic;

    -- external (MMCX clock) clock
    P_IO_ECLK_IN               : inout std_logic;
    P_O_ECLK_IND               : out std_logic;
    P_IO_ECLK_OUT              : inout std_logic;
    P_O_ECLK_OUTD              : out std_logic;

    -- LEDs
    P_O_LED0                   : out std_logic; 
    P_O_LED1                   : out std_logic; 

    -- Lines to/from Cy7C68013A microcontroller
    P_IO_UC_SLOE               : inout std_logic;
    P_IO_UC_SLRD               : inout std_logic;
    P_IO_UC_SLWR               : inout std_logic;
    P_IO_UC_SLCS               : inout std_logic;
    P_IO_UC_PKTEND             : inout std_logic;
    P_IO_UC_FIFOADR0           : inout std_logic;
    P_IO_UC_FIFOADR1           : inout std_logic;
    P_IO_UC_FLAGA              : inout std_logic;
    P_IO_UC_FLAGB              : inout std_logic;
    P_IO_UC_FLAGC              : inout std_logic;
    P_I_UC_PA0                 : in    std_logic;
    
    P_IO_UC_FD                 : inout std_logic_vector(15 downto 0);

    -- PMC connector
    P_IO_PMC_USR               : inout std_logic_vector(63 downto 0)
);
end drs4_eval4;

architecture arch of drs4_eval4 is

  component usr_clocks
    port (
      P_I_CLK33                : in  std_logic; 
      P_I_CLK66                : in  std_logic; 
      O_CLK33                  : out std_logic; 
      O_CLK33_NODLL            : out std_logic; 
      O_CLK66                  : out std_logic; 
      O_CLK132                 : out std_logic; 
      O_CLK264                 : out std_logic; 
      I_PS_VALUE               : in std_logic_vector(7 downto 0);
      O_CLK_PS                 : out std_logic; 
      O_LOCKED                 : out std_logic;
      
      O_DEBUG1                 : out std_logic;
      O_DEBUG2                 : out std_logic
    );
  end component;

  component usb2_racc is
    port (
      -- Clock signals
      -- ------------------------
      I_RESET                  : in std_logic;
      I_CLK33                  : in std_logic;
      
      -- Lines to/from Cy7C68013A microcontroller
      -- -----------------------------------
      P_IO_UC_SLOE             : inout std_logic;
      P_IO_UC_SLRD             : inout std_logic;
      P_IO_UC_SLWR             : inout std_logic;
      P_IO_UC_SLCS             : inout std_logic;
      P_IO_UC_PKTEND           : inout std_logic;
      P_IO_UC_FIFOADR0         : inout std_logic;
      P_IO_UC_FIFOADR1         : inout std_logic;
      P_IO_UC_FLAGA            : inout std_logic;
      P_IO_UC_FLAGB            : inout std_logic;
      P_IO_UC_FLAGC            : inout std_logic;
      P_IO_UC_FD               : inout std_logic_vector(15 downto 0);

      -- Simple bus interface to on-chip RAM
      -- --------------------------------------------------
      O_LOCBUS_ADDR            : out std_logic_vector(31 downto 0);
      I_LOCBUS_D_RD            : in  std_logic_vector(31 downto 0);
      O_LOCBUS_D_WR            : out std_logic_vector(31 downto 0);
      O_LOCBUS_WE              : out std_logic;

      -- Status & control registers
      -----------------------------
      O_CONTROL_REG_ARR        : out type_control_reg_arr;
      I_STATUS_REG_ARR         : in type_status_reg_arr;

      O_CONTROL_TRIG_ARR       : out type_control_trig_arr;
      O_CONTROL0_BIT_TRIG_ARR  : out std_logic_vector(31 downto 0);

      -- Debug signals
      -- -------------
      O_DEBUG                  : out std_logic
    );
  end component;

  component usb_dpram is
    port (
      I_RESET                  : in  std_logic;                       
                                                                     
      I_CLK_A                  : in  std_logic;                       
      I_ADDR_A                 : in  std_logic_vector(31 downto 0);  
      I_WE_A                   : in  std_logic;                      
      O_D_RD_A                 : out std_logic_vector(31 downto 0);  
      I_D_WR_A                 : in  std_logic_vector(31 downto 0);   
                                                                     
      I_CLK_B                  : in  std_logic;                       
      I_ADDR_B                 : in  std_logic_vector(31 downto 0);  
      I_WE_B                   : in  std_logic;                      
      O_D_RD_B                 : out std_logic_vector(31 downto 0);  
      I_D_WR_B                 : in  std_logic_vector(31 downto 0)    

    );
  end component;

  component drs4_eval4_app is
    port (
    
      I_CLK33                  : in std_logic; -- 33 MHz, sychronised to clk33_nodll
      I_CLK66                  : in std_logic; -- 66 MHz, same phase as clk33
      I_CLK132                 : in std_logic; -- 132 MHz, random phase in respect to clk33
      I_CLK264                 : in std_logic; -- 264 MHz, random phase in respect to clk33
      O_CLK_PS_VALUE           : out std_logic_vector(7 downto 0); -- value for phase shift
      I_CLK_PS                 : in std_logic; -- phase shifted in respect to clk33
      I_RESET                  : in std_logic; -- active high power-up reset
  
      -- analog triggers
      I_ANA_TRG                : in std_logic_vector(3 downto 0);
    
      -- external trigger
      IO_ETRG_IN               : inout std_logic;
      O_ETRG_IND               : out std_logic;

      IO_ETRG_OUT              : inout std_logic;
      O_ETRG_OUTD              : out std_logic;

      -- external (MMCX clock) clock
      IO_ECLK_OUT              : inout std_logic;
      IO_ECLK_IN               : inout std_logic;
  
      -- PMC
      P_IO_PMC_USR             : inout std_logic_vector(63 downto 0);

      -- Simple bus interface to DPRAM
      O_DPRAM_CLK              : out std_logic;
      O_DPRAM_ADDR             : out std_logic_vector(31 downto 0);
      O_DPRAM_D_WR             : out std_logic_vector(31 downto 0);
      O_DPRAM_WE               : out std_logic;
      I_DPRAM_D_RD             : in std_logic_vector(31 downto 0);

      -- Control & status registers from system FPGA interface
      I_CONTROL_REG_ARR        : in  type_control_reg_arr;
      O_STATUS_REG_ARR         : out type_status_reg_arr;
      I_CONTROL_TRIG_ARR       : in  type_control_trig_arr;
      I_CONTROL0_BIT_TRIG_ARR  : in  std_logic_vector(31 downto 0);

      -- LEDs signals
      O_LED_RED                : out std_logic;
      O_LED_YELLOW             : out std_logic;
      
      -- Debug signals
      O_DEBUG1                 : out std_logic;
      O_DEBUG2                 : out std_logic
    );
  end component;

  signal VCC: std_logic;
  signal GND: std_logic;

  -- reset signal
  -- -------------
  signal global_reset          : std_logic;  -- active high power-up reset
  
  -- clocks & related signals
  -- ------------------------
  signal clk33_nodll           : std_logic; -- external 33 MHz clock (global clock net)
  signal clk33                 : std_logic; -- 33 MHz DLL output
  signal clk66                 : std_logic;
  signal clk132                : std_logic;
  signal clk264                : std_logic;
  signal clk_ps_value          : std_logic_vector(7 downto 0);
  signal clk_ps                : std_logic; -- special phase shifted clock
  signal usr_clks_dlls_locked  : std_logic; -- high if clock DLLs for clkxx have locked

  -- user application signals for Locbus interface
  -- ---------------------------------------------
  signal locbus_addr           : std_logic_vector(31 downto 0);
  signal locbus_d_rd           : std_logic_vector(31 downto 0);
  signal locbus_d_wr           : std_logic_vector(31 downto 0);
  signal locbus_we             : std_logic;

  -- user application signals for DPRAM interface
  -- --------------------------------------------
  signal dpram_clk             : std_logic;
  signal dpram_addr            : std_logic_vector(31 downto 0);
  signal dpram_we              : std_logic;
  signal dpram_d_wr            : std_logic_vector(31 downto 0);
  signal dpram_d_rd            : std_logic_vector(31 downto 0);

  -- register signals for data exchange with microcontroller
  -- -------------------------------------------------------
  signal control_reg_arr       : type_control_reg_arr;
  signal status_reg_arr        : type_status_reg_arr;

  signal control_trig_arr: type_control_trig_arr;
  signal control0_bit_trig_arr : std_logic_vector(31 downto 0);

  -- LEDs
  -- ----
  signal o_led_red             : std_logic;
  signal o_led_yellow          : std_logic;

  -- Trigger
  -- -------
  signal io_etrg_in            : std_logic;
  signal o_etrg_ind            : std_logic;
  signal io_etrg_out           : std_logic;
  signal o_etrg_outd           : std_logic;
  signal i_ana_trg             : std_logic_vector(3 downto 0);
  signal io_eclk_out           : std_logic;
  signal io_eclk_in            : std_logic;
  
  -- Debugging signals
  -- -----------------
  signal o_racc_debug          : std_logic;
  signal o_debug1              : std_logic;
  signal o_debug2              : std_logic;

begin
  VCC <= '1';
  GND <= '0';

  -- map LEDs
  P_O_LED0       <= o_led_yellow;
  P_O_LED1       <= o_led_red;
  
  -- debug outputs
  P_IO_J45       <= GND;
  P_IO_J46       <= GND;
  P_IO_J48       <= o_debug1;
  P_IO_J49       <= o_debug2;

  -- triggers
  i_ana_trg(0)   <= P_I_ATRG1;
  i_ana_trg(1)   <= P_I_ATRG2;
  i_ana_trg(2)   <= P_I_ATRG3;
  i_ana_trg(3)   <= P_I_ATRG4;

  io_etrg_in     <= P_IO_ETRG_IN;
  P_O_ETRG_IND   <= o_etrg_ind;
  P_IO_ETRG_OUT  <= io_etrg_out;
  P_O_ETRG_OUTD  <= o_etrg_outd;

  -- external clock
  P_IO_ECLK_OUT  <= io_eclk_out;
  P_O_ECLK_OUTD  <= '1';
  io_eclk_in     <= P_IO_ECLK_IN;
  P_O_ECLK_IND   <= '0';

  clocks : usr_clocks port map (
    P_I_CLK33                  => P_I_CLK33,
    P_I_CLK66                  => P_I_CLK66,
    O_CLK33                    => clk33,              
    O_CLK33_NODLL              => clk33_nodll,        
    O_CLK66                    => clk66,              
    O_CLK132                   => clk132,             
... 121 more lines ...
ELOG V3.1.5-fe60aaf