DRS4 Forum
  DRS4 Discussion Forum  Not logged in ELOG logo
Entry  Tue May 19 14:14:45 2015, Ilja Bekman, DRS4 firmware UCF constraints  
    Reply  Fri May 22 14:25:45 2015, Stefan Ritt, DRS4 firmware UCF constraints  firmware.zip
       Reply  Tue May 26 11:27:27 2015, Felix Bachmair, DRS4 firmware UCF constraints  
          Reply  Fri Jun 5 12:07:38 2015, Stefan Ritt, DRS4 firmware UCF constraints  
             Reply  Fri Jun 5 13:15:35 2015, Felix Bachmair, DRS4 firmware UCF constraints  
                Reply  Fri Jun 5 13:29:55 2015, Stefan Ritt, DRS4 firmware UCF constraints  
                   Reply  Fri Jun 5 13:32:03 2015, Stefan Ritt, DRS4 firmware UCF constraints  
Message ID: 425     Entry time: Tue May 26 11:27:27 2015     In reply to: 422     Reply to this: 427
Author: Felix Bachmair 
Subject: 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 
ELOG V3.1.5-fe60aaf