DVCS Trigger System: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
No edit summary |
||
Line 5: | Line 5: | ||
First approach (September 2007) ([http://clonweb/wiki/clondocs/DVCS_Trigger/DVCS_Calorimeter_Trigger.ppt PowerPoint], | First approach (September 2007) ([http://clonweb/wiki/clondocs/DVCS_Trigger/DVCS_Calorimeter_Trigger.ppt PowerPoint], | ||
[http://clonweb/wiki/clondocs/DVCS_Trigger/DVCS_Calorimeter_Trigger.htm HTML]). | [http://clonweb/wiki/clondocs/DVCS_Trigger/DVCS_Calorimeter_Trigger.htm HTML]). | ||
'''Project in progress''' | |||
Ben reported on CLON meeting 3-Oct-2007, preliminary design: [http://clonweb/wiki/clondocs/DVCS_Trigger/PreliminaryDesign.ppt PowerPoint]. | Ben reported on CLON meeting 3-Oct-2007, preliminary design: [http://clonweb/wiki/clondocs/DVCS_Trigger/PreliminaryDesign.ppt PowerPoint]. |
Revision as of 15:01, 8 October 2007
Current section contains DVCS Calorimeter Trigger System development materials.
System Requirements
First approach (September 2007) (PowerPoint, HTML).
Project in progress
Ben reported on CLON meeting 3-Oct-2007, preliminary design: PowerPoint.
Ben (8-Oct-2007):
Attached are some images of the program that interfaces to the V1495 module. This let me make a pattern, send it to the V1495, and retrieves the processed information from the V1495 that would be used for generating the trigger. Trigger_Regular is the algorithm as described in the specification document that I received. It looks at all possible 3x3 windows and determines if there are more hit towers than the programmed threshold (here the threshold was set to 4 - there had to be more than 4 hits in a 3x3 window to define a cluster). As you can see 4 clusters were found in the sample image (the cluster count is also reported by the V1495 unit). The one in the bottom left has overlapping 3x3 windows that meet the cluster definition criteria. In this case, some logic could be used to determine that a neighboring cluster has fewer hits than the other neighber and so it could supress that report. Next, I played around a little more and wrote a simple algorithm that just just ran in my program (on my PC, not the V1495) that took the same data and caused adjacent hit towers (Up/down/left/right/all diagonals) to attract to each other. So if more hits were on the left side of a cluster, that cluster value would hop left if the weight was larger than its own (or any other direction if the weight were arragned so). I took the same data set as in the last image, and ran 3 iterations through this algorithm (fig1 fig2 fig3) and you can see the hits clump together and increase in count when two hits go to the same cell. The idea here would be to run this algorithm, and then apply a threshold to each cell to determine if it is a cluster or not. Anyway, you can see now the bottom left cell clumps together to a single point where the "center of mass" would have been for those original hits. So does the upper left. The upper right fails to clump into a single point because there is not bias to move either way because there is equal pull in both directions (this would be something that can be overcome by forcing them to always go a particular direction when pulls are equal). For the heck of it I sythesized this algorithm on the FPGA and found it will need about 3 times the available resources (not really a surprise)! This, or something of similar complexity could work if spread over more that one board. I've got some ideas for dealing with that if it is of interest. Determining the X/Y location of the clusters is actually a bit more difficult (especially if the latency needs to be kept low). This should be feasible, but it will take several more, at least, clock cycles beyond when a trigger has been determined. This is because all 424 potential clusters will have to be looked at and probably sorted. Just a guess is that it could take about 40ns beyond the assertion of the ASYNC trigger. If there is any flexibility here it may be of some use. I'll certainly find out more when I get around to implementing this feature. Currently, I'm planning to focus on "properly" finding clusters. I'm interested in seeing what some real data looks like. There's probably no need to format it because I can just read it in with some standard file I/O in c++. I need clarification on how to deal with adjacent cluster hits (whether to count them individually or not, or if we need to do further processing).
Useful documentation
CAEN V895 Discriminator Manual Revision 2, September 2002, pdf.
CAEN V1495 Logic Unit Manual Revision 4, January 2007, pdf.
V1495-related software downloaded from CAEN site on September 25, 2007 (check CAEN for newer versions !):
Our materials:
- CLAS version of V1495 Firmware Upgrade Program - CAEN version slightly modified by Sergey Boyarinov, see usage example inside; runs from VxWorks prompt