CLAS12 Trigger System Design: Difference between revisions
No edit summary |
m Text replacement - "clonwiki.jlab.org" to "clonwiki0.jlab.org" |
||
(37 intermediate revisions by 3 users not shown) | |||
Line 1: | Line 1: | ||
== Development History == | |||
Leader: Sergey Boyarinov | Leader: Sergey Boyarinov | ||
Support: David Doughty, Chris Cuevas, Ed Jastrzembski | Support: Ben Raydo, David Doughty, Chris Cuevas, Ed Jastrzembski, Konstantin Mikhailov, Alex Vlassov | ||
Goal: CLAS12 Trigger System Design | Goal: CLAS12 Trigger System Design | ||
Line 7: | Line 9: | ||
Status: in progress | Status: in progress | ||
Project was planned in June 2006 | Project was planned in June 2006 to be completed during FY07. Actual job started in November 2006. | ||
We had several meetings discussing existing CLAS trigger, what can be improved | We had several meetings discussing existing CLAS trigger, what can be improved | ||
in CLAS12 desing, and new technologies available today. First very preliminary | in CLAS12 desing, and new technologies available today. Our work plan was summarized on Wednesday CLON | ||
CLAS12 Trigger System design was presented and discussed on upgrade meeting | meeting December 13, 2006 (see [[December 13, 2006 online meeting minutes]]). | ||
First very preliminary CLAS12 Trigger System design was presented and discussed on Friday upgrade meeting | |||
December 15, 2006 ([https://clonwiki0.jlab.org/wiki/clondocs/CLAS12_Trigger/CLAS12_Trigger.ppt PowerPoint], | |||
[https://clonwiki0.jlab.org/wiki/clondocs/CLAS12_Trigger/CLAS12_Trigger.ppt.htm HTML]). | |||
'''Trigger Efficiency Studies''' | |||
Trigger efficiency simulation is very important but was not started yet. | |||
'''Level 1: Forward Calorimeter Cluster Finding''' | |||
Currently we are trying to develop Forward Calorimeter Cluster Finding algorithm which can be used in Level 1. | |||
We started from algorithm used in data analysis, and we hope to develop similar procedure to be loaded into | |||
FPGA. | |||
Ed's mail on FPGA-based look up tables: | |||
Thu, 25 Jan 2007 13:47:39 -0500 (EST) | |||
To: Serguei Boiarinov <boiarino@jlab.org> | |||
CC: Hai Dong <hdong@jlab.org>, "C. Cuevas" <cuevas@jlab.org>, | |||
David Abbott <abbottd@jlab.org> | |||
Subject: FPGA look up tables | |||
Hi Sergey, | |||
I did some investigating on the use of FPGA memory as a look up | |||
table for trigger system applications. For Altera FPGAs, the total | |||
on-chip memory can be up to 9 Mbits. However, the largest single RAM | |||
block is 512 Kbits. This can be organized as 64K x 8, 32K x 16, 16K | |||
x 32, ... , or 4K x 128. Larger chips have multiple 512 Kbit blocks | |||
(along with smaller and faster blocks). Thus, a look up table with as | |||
many as 16 inputs and 8 outputs can be created. Multiple tables can be | |||
created in the larger capacity FPGAs. The downside of using the large | |||
capacity FPGAs is that the pin count and cost also increases with memory | |||
capacity. For example, 9 Mbit Altera chips have pin counts of > 1000 | |||
pins (BGA) and cost ~$3000 each. | |||
To test the performance in an Altera FPGA, I created the following | |||
cascaded (2-level) look up table using 512 Kbit segments: (64K x 8, | |||
64K x 8) => (64K x 8). (i.e. 32 inputs => 8 outputs). The timing | |||
analysis performed by the Altera software indicates that the design will | |||
run at > 250MHz clock frequency. This fits in a 484 pin BGA (with much | |||
spare logic). | |||
I'll check with Hai Dong (Fast Electronics Group) about memory | |||
resources in Xilinx FPGAs. He may also be able to comment on the | |||
performance of such a look up table in a Xilinx target. It is probably | |||
comparable to the Altera's speed. | |||
- Ed J. | |||
Next preliminary CLAS12 Trigger System design was presented and discussed on TWG meeting | |||
February 28, 2007 ([https://clonwiki0.jlab.org/wiki/clondocs/CLAS12_Trigger/CLAS12_Trigger_TWG_Feb_2007.ppt PowerPoint], | |||
[https://clonwiki0.jlab.org/wiki/clondocs/CLAS12_Trigger/CLAS12_Trigger_TWG_Feb_2007.pdf PDF], | |||
[https://clonwiki0.jlab.org/wiki/clondocs/CLAS12_Trigger/CLAS12_Trigger_TWG_Feb_2007.htm HTML]). | |||
'''Trigger Efficiency Studies''' | |||
CLAS trigger efficiency study was completed using e1-6 data, result is here | |||
[https://clonwiki0.jlab.org/wiki/clondocs/CLAS12_Trigger/2007-009.ps PostScript], | |||
[https://clonwiki0.jlab.org/wiki/clondocs/CLAS12_Trigger/2007-009.pdf PDF]. | |||
'''CLAS12 DAQ and Trigger''' | |||
We had several meetings in March, April and May and finally CLAS12 trigger design was completed. Following document was included into CLAS12 TDR2007. It also contains CLAS12 Data Aquisition System description, probably for the first time we have completed DAQ layout in one document. | |||
DAQ/Trigger section from TDR2007 can be found here | |||
[https://clonwiki0.jlab.org/wiki/clondocs/TDR2007/TDR2007_DAQ_TRIGGER.ps PostScript]. | |||
The snapshot of the ''tex'' directory is here [http://clonwiki/wiki/clondocs/TDR2007/tex tex directory], permanent place is ''$CVSROOT/12gev/TDR/TDR2007/main/detector/daq_trigger''. | |||
Supporting slides (all pictures with short text) are here | |||
[https://clonwiki0.jlab.org/wiki/clondocs/TDR2007/TDR2007_DAQ_TRIGGER.ppt Power Point], | |||
[https://clonwiki0.jlab.org/wiki/clondocs/TDR2007/TDR2007_DAQ_TRIGGER.pdf PDF], | |||
[https://clonwiki0.jlab.org/wiki/clondocs/TDR2007/TDR2007_DAQ_TRIGGER.htm HTML]. | |||
[https://clonwiki0.jlab.org/wiki/clondocs/CLAS12_Trigger/clas12_sergey_timeline.pdf Timeline chart October 31, 2007 (pdf)] | |||
Nov 13, 2007: we are resuming project after DVCS Trigger design reached intermediate finish. Following links contains EC-related Level1 materials: | |||
[https://clonwiki0.jlab.org/wiki/clondocs/CLAS12_Trigger/TDR2008_DAQ_TRIGGER.ppt Power Point], | |||
[https://clonwiki0.jlab.org/wiki/clondocs/CLAS12_Trigger/TDR2008_DAQ_TRIGGER.pdf PDF], | |||
[https://clonwiki0.jlab.org/wiki/clondocs/CLAS12_Trigger/TDR2008_DAQ_TRIGGER.htm HTML]. | |||
Feb 1, 2008: first version of ECFinder in vhdl is ready and passed to Hai. Job was done by Sergey B. under Ben Raydo's supervision. Schematics: | |||
[https://clonwiki0.jlab.org/wiki/clondocs/CLAS12_Trigger/CLAS12_TRIGGER_CF1.pdf PeakFinder(pdf)], | |||
[https://clonwiki0.jlab.org/wiki/clondocs/CLAS12_Trigger/CLAS12_TRIGGER_CF1.eps PeakFinder(eps)], | |||
[https://clonwiki0.jlab.org/wiki/clondocs/CLAS12_Trigger/CLAS12_TRIGGER_CF2.pdf ClusterFinder(pdf)], | |||
[https://clonwiki0.jlab.org/wiki/clondocs/CLAS12_Trigger/CLAS12_TRIGGER_CF2.eps ClusterFinder(eps)]. | |||
Feb 13, 2008: first level 2 discussion, see [[February 13, 2008 online meeting minutes]]. | |||
== Trigger Software == | |||
Most trigger boards (v1495, FADC, CTP, SSP) have VME interface (CTP can be accessed through VME using TI board). GTP have to be accessed using ethernet connection. | |||
One way to provide an access to the board registers is tcp server, running on VME controller in vxWorks or Linux OS. There is a standard messaging system implemented as function ''ProcessRemoteMsg(RemoteMsgStruct *pRemoteMsgStruct)''. All GUIs or other controlling programs have to access trigger boards using that function. | |||
Special treatment is provided to the scalers implemented in trigger boards: designated process allows to register scalers to be readout by separate thread on specified timing interval placing results into the memory. All clients will be automatically readdressed to the memory to obtain scalers values. It allows to avoid problem with multiple access to the scalers with reset-on-readout implementation. |
Latest revision as of 15:06, 17 April 2015
Development History
Leader: Sergey Boyarinov
Support: Ben Raydo, David Doughty, Chris Cuevas, Ed Jastrzembski, Konstantin Mikhailov, Alex Vlassov
Goal: CLAS12 Trigger System Design
Status: in progress
Project was planned in June 2006 to be completed during FY07. Actual job started in November 2006. We had several meetings discussing existing CLAS trigger, what can be improved in CLAS12 desing, and new technologies available today. Our work plan was summarized on Wednesday CLON meeting December 13, 2006 (see December 13, 2006 online meeting minutes).
First very preliminary CLAS12 Trigger System design was presented and discussed on Friday upgrade meeting December 15, 2006 (PowerPoint, HTML).
Trigger Efficiency Studies
Trigger efficiency simulation is very important but was not started yet.
Level 1: Forward Calorimeter Cluster Finding
Currently we are trying to develop Forward Calorimeter Cluster Finding algorithm which can be used in Level 1. We started from algorithm used in data analysis, and we hope to develop similar procedure to be loaded into FPGA.
Ed's mail on FPGA-based look up tables:
Thu, 25 Jan 2007 13:47:39 -0500 (EST) To: Serguei Boiarinov <boiarino@jlab.org> CC: Hai Dong <hdong@jlab.org>, "C. Cuevas" <cuevas@jlab.org>, David Abbott <abbottd@jlab.org> Subject: FPGA look up tables Hi Sergey, I did some investigating on the use of FPGA memory as a look up table for trigger system applications. For Altera FPGAs, the total on-chip memory can be up to 9 Mbits. However, the largest single RAM block is 512 Kbits. This can be organized as 64K x 8, 32K x 16, 16K x 32, ... , or 4K x 128. Larger chips have multiple 512 Kbit blocks (along with smaller and faster blocks). Thus, a look up table with as many as 16 inputs and 8 outputs can be created. Multiple tables can be created in the larger capacity FPGAs. The downside of using the large capacity FPGAs is that the pin count and cost also increases with memory capacity. For example, 9 Mbit Altera chips have pin counts of > 1000 pins (BGA) and cost ~$3000 each. To test the performance in an Altera FPGA, I created the following cascaded (2-level) look up table using 512 Kbit segments: (64K x 8, 64K x 8) => (64K x 8). (i.e. 32 inputs => 8 outputs). The timing analysis performed by the Altera software indicates that the design will run at > 250MHz clock frequency. This fits in a 484 pin BGA (with much spare logic). I'll check with Hai Dong (Fast Electronics Group) about memory resources in Xilinx FPGAs. He may also be able to comment on the performance of such a look up table in a Xilinx target. It is probably comparable to the Altera's speed. - Ed J.
Next preliminary CLAS12 Trigger System design was presented and discussed on TWG meeting February 28, 2007 (PowerPoint, PDF, HTML).
Trigger Efficiency Studies
CLAS trigger efficiency study was completed using e1-6 data, result is here PostScript, PDF.
CLAS12 DAQ and Trigger
We had several meetings in March, April and May and finally CLAS12 trigger design was completed. Following document was included into CLAS12 TDR2007. It also contains CLAS12 Data Aquisition System description, probably for the first time we have completed DAQ layout in one document.
DAQ/Trigger section from TDR2007 can be found here PostScript.
The snapshot of the tex directory is here tex directory, permanent place is $CVSROOT/12gev/TDR/TDR2007/main/detector/daq_trigger.
Supporting slides (all pictures with short text) are here Power Point, PDF, HTML.
Timeline chart October 31, 2007 (pdf)
Nov 13, 2007: we are resuming project after DVCS Trigger design reached intermediate finish. Following links contains EC-related Level1 materials: Power Point, PDF, HTML.
Feb 1, 2008: first version of ECFinder in vhdl is ready and passed to Hai. Job was done by Sergey B. under Ben Raydo's supervision. Schematics:
PeakFinder(pdf),
PeakFinder(eps),
ClusterFinder(pdf),
ClusterFinder(eps).
Feb 13, 2008: first level 2 discussion, see February 13, 2008 online meeting minutes.
Trigger Software
Most trigger boards (v1495, FADC, CTP, SSP) have VME interface (CTP can be accessed through VME using TI board). GTP have to be accessed using ethernet connection.
One way to provide an access to the board registers is tcp server, running on VME controller in vxWorks or Linux OS. There is a standard messaging system implemented as function ProcessRemoteMsg(RemoteMsgStruct *pRemoteMsgStruct). All GUIs or other controlling programs have to access trigger boards using that function.
Special treatment is provided to the scalers implemented in trigger boards: designated process allows to register scalers to be readout by separate thread on specified timing interval placing results into the memory. All clients will be automatically readdressed to the memory to obtain scalers values. It allows to avoid problem with multiple access to the scalers with reset-on-readout implementation.