ID |
Date |
Author |
Subject |
329
|
Wed Jan 15 17:37:21 2014 |
Stefan Ritt | DRS4 installation on Windows 8 issues |
Andrey Kuznetsov wrote: |
I'm also having trouble installing drivers and running DRSOsc program on another computer running Windows 8.
The issue with the driver is that it's not digitally signed.
The issue with the DRSOsc is that it's failing to find libusb0.dll. libusb-win32 seemed to have installed upon DRS4 software install, however the supplied version is Windows 7/8 incompatible, so on Windows 7 computer I had to download libusb_win32 v1.2.6.0 from the official website and install it directly, then everything worked fine. However in Windows 8, I am unable to install libusb-win32 because in libusb-win32 Inf Wizard installation program when you select for which device the libusb should be used, it asks to install a driver, but when I point to DRS' driver, it says "Unknown Error: 1" and that's that. One way around the libusb issue is to copy the required dll and sys file directly where the .exe is stored.
I will attempt to disable signed driver signature requirement, and see if the driver installs then, but this should really be fixed instead.
|
Did you have any progress with that? Unfortunately I don't have a Windows 8 machine here at our institute, so I cannot reproduce your problem. At least I put the 1.2.6 libusb driver into the V5 software package. |
421
|
Tue May 19 14:14:45 2015 |
Ilja Bekman | DRS4 firmware UCF constraints | Hello, I'm using two DRS4 rev.5 boards for 8ch readout and triggering.
I needed to modify the trigger logic and implement some tweaks in the firmware, and noticed that
the firmware source in drs-5.0.2 (and 5.0.3, SVN:5339) while still compiling fine with Xilinx ISE 10, stops
doing so in the ISE 14.7 (also already in 13.2)
While the Synthesis is running through (in the new ISE it complains about using more than 100% of resources.)
The Mapping fails due to constraints (firmware/ucf/drs4_eval5.ucf) complaining about an illegal IOSTANDARD
for P_IO_PMC_USR<55> (LVDS_25).
In the newer version the wild-cards (lines 67..69 ) are not properly dealt with, it seems, and if I move the
property by hand to all the wild-carded NETs it start to recognise the LVDS_25.
But after that Place&Route fails with messages about locked Banks due to incompatible VCCO.
I'm trying to adapt the ucf file and am reading about the changes in the ISE software and constraints files, but
want to ask if some of you guys have seen the same issue and resolved it out "officially". |
422
|
Fri May 22 14:25:45 2015 |
Stefan Ritt | DRS4 firmware UCF constraints | > Hello, I'm using two DRS4 rev.5 boards for 8ch readout and triggering.
>
> I needed to modify the trigger logic and implement some tweaks in the firmware, and noticed that
> the firmware source in drs-5.0.2 (and 5.0.3, SVN:5339) while still compiling fine with Xilinx ISE 10, stops
> doing so in the ISE 14.7 (also already in 13.2)
>
> While the Synthesis is running through (in the new ISE it complains about using more than 100% of resources.)
> The Mapping fails due to constraints (firmware/ucf/drs4_eval5.ucf) complaining about an illegal IOSTANDARD
> for P_IO_PMC_USR<55> (LVDS_25).
>
> In the newer version the wild-cards (lines 67..69 ) are not properly dealt with, it seems, and if I move the
> property by hand to all the wild-carded NETs it start to recognise the LVDS_25.
> But after that Place&Route fails with messages about locked Banks due to incompatible VCCO.
>
> I'm trying to adapt the ucf file and am reading about the changes in the ISE software and constraints files, but
> want to ask if some of you guys have seen the same issue and resolved it out "officially".
The current firmware compiles nicely under 14.7. I attached it. It also has one modification which you probably need:
When the board triggers, the TRG OUT goes high and stays high until the board has been read out and restarted. So it can be used as a "busy" signal for an external trigger logic.
Best regards,
Stefan |
Attachment 1: firmware.zip
|
425
|
Tue May 26 11:27:27 2015 |
Felix Bachmair | DRS4 firmware UCF constraints | > > Hello, I'm using two DRS4 rev.5 boards for 8ch readout and triggering.
> >
> > I needed to modify the trigger logic and implement some tweaks in the firmware, and noticed that
> > the firmware source in drs-5.0.2 (and 5.0.3, SVN:5339) while still compiling fine with Xilinx ISE 10, stops
> > doing so in the ISE 14.7 (also already in 13.2)
> >
> > While the Synthesis is running through (in the new ISE it complains about using more than 100% of resources.)
> > The Mapping fails due to constraints (firmware/ucf/drs4_eval5.ucf) complaining about an illegal IOSTANDARD
> > for P_IO_PMC_USR<55> (LVDS_25).
> >
> > In the newer version the wild-cards (lines 67..69 ) are not properly dealt with, it seems, and if I move the
> > property by hand to all the wild-carded NETs it start to recognise the LVDS_25.
> > But after that Place&Route fails with messages about locked Banks due to incompatible VCCO.
> >
> > I'm trying to adapt the ucf file and am reading about the changes in the ISE software and constraints files, but
> > want to ask if some of you guys have seen the same issue and resolved it out "officially".
>
> The current firmware compiles nicely under 14.7. I attached it. It also has one modification which you probably need:
>
> When the board triggers, the TRG OUT goes high and stays high until the board has been read out and restarted. So it can be used as a "busy" signal for an external trigger logic.
>
> Best regards,
> Stefan
Hi Stefan,
Thanks a lot for the new firmware. We are testing it at the moment in a beam test at PSI (PiM1) and we realized that this doesn't seem to work 100%.
We need to extend the death time after a trigger by approx. 200 mus in order to not loose triggers.
It seems that under certain circumstances a trigger within that window is ignored.
We do a handshake after each trigger so we are able to recognize such ignored events. This can happen quite often (within the first few hundered events) when we do not increase the deadtime.
Do you have any idea what could be the reason for that issue?
Best regardds
Felix |
427
|
Fri Jun 5 12:07:38 2015 |
Stefan Ritt | DRS4 firmware UCF constraints | I presume you have several evaluation boards and want to run them in sync, right?
This can be either made in daisy-chain mode (see manual page 25). In this case only the master board can trigger the slave boards. If you need to trigger on SEVERAL boards (like a coincidence between two boards), you have to do this with an external trigger and busy logic. This is rather
complicated and needs detailed explanations. So come to my office and I will teach you.
Best,
Stefan |
428
|
Fri Jun 5 13:15:35 2015 |
Felix Bachmair | DRS4 firmware UCF constraints | Hi Stefan,
No we only use one evaluation board. We use the evaluation board as a part of our beam test setup. It includes a telescope based on the current PSI46V2.1 CMS Pixel chip and a trigger logic board for triggering the telescope and the evaluation board. This includes a
handshake between every device and the tlu
e.g. the tlu expects an answer for each trigger.
If the trigger comes within this first 200 mus it seems that not every trigger is accepted.
In this moment our readout would 'die' since the tlu is waiting for the handshake.
Cheers
Felix
> I presume you have several evaluation boards and want to run them in sync, right?
>
> This can be either made in daisy-chain mode (see manual page 25). In this case only the master board can trigger the slave boards. If you need to trigger on SEVERAL boards (like a coincidence between two boards), you have to do this with an external trigger and
busy logic. This is rather
> complicated and needs detailed explanations. So come to my office and I will teach you.
>
> Best,
> Stefan |
429
|
Fri Jun 5 13:29:55 2015 |
Stefan Ritt | DRS4 firmware UCF constraints | Do the following:
Use the TRG OUT of the evaluation board as a "busy". Only if this signal goes low (meaning that the readout of the board is complete and the board has been restarted), then re-enable triggers in your trigger logic.
/Stefan
> Hi Stefan,
> No we only use one evaluation board. We use the evaluation board as a part of our beam test setup. It includes a telescope based on the current PSI46V2.1 CMS Pixel chip and a trigger logic board for triggering the telescope and the evaluation board. This includes a
> handshake between every device and the tlu
> e.g. the tlu expects an answer for each trigger.
> If the trigger comes within this first 200 mus it seems that not every trigger is accepted.
> In this moment our readout would 'die' since the tlu is waiting for the handshake. |
430
|
Fri Jun 5 13:32:03 2015 |
Stefan Ritt | DRS4 firmware UCF constraints | Actually we should take this offline not to pester other DRS users which are not interested in this topic. Please call me directly (3728) at PSI.
/Stefan |
186
|
Thu Nov 1 20:08:33 2012 |
hongwei yang | DRS4 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 Ritt | DRS4 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 yang | DRS4 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 yang | DRS4 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 Ritt | DRS4 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 ...
|
191
|
Thu Nov 1 20:46:53 2012 |
hongwei yang | DRS4 firmware |
Stefan Ritt wrote: |
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.
|
Thanks. have a good day |
132
|
Sat Oct 15 04:45:25 2011 |
Aurelien Bouvier | DRS4 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 Ritt | DRS4 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
|
592
|
Wed Apr 5 12:40:16 2017 |
Martin Petriska | DRS4 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 Ritt | DRS4 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?
|
|
728
|
Wed Jan 30 06:51:37 2019 |
Saurabh Neema | DRS4 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 Ritt | DRS4 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,
|
|
|