Sphenix-tpc-l mailing list

["Huang, Jin" <jhuang AT bnl.gov>]

Hi, Martin,

Following Takao’s comment on the FEE, here is more considerations on the DAM 
side: 


> I'm in the process of compiling the "trigger latency map", usually
> expressed as the number of beam crossings we can let go by before we
> need a trigger decision.

The diagram as we put together in Jan 2017 has the wavelet sorted into beam 
collision clock (BCO) bucket, like the FVTX/INTT design:
https://docs.google.com/spreadsheets/d/1Q_uYf00_8pushSiYns29T_-ThIOqQaqpKbVS_LDqlAg/edit?usp=sharing
  
The expected depth can also be 64 to accommodate an external trigger delay, 
also to allow data from various parts of FEE to be fully transmitted to DAMs 
and to line them up by BCO clock (let's assume lowest one take 10 BCO to 
clear the pipe lines for now). The step after the BCO buckets would be either 
sub-event building or trigger-based data throttling, which require a trigger 
decision. 

Therefore, on this design, the sum of FEE + DAM delay from collision to 
trigger decision can be  ~6 BCO for mean data transmission time in ADC, FPGA 
and fiber + [0 --192/2] BCO for tunable SAMPA delay + [10 -- 64] BCO for the 
tunable DAM delay = [16 -- 166] BCO, which would be a quite generous range. I 
will be happy to hear suggestions if I have missed any pieces. 


> can we afford the duplication of waveform snippets where they overlap in 
> time?  

I guess you meant " duplication of waveform snippets where the TPC drift 
window overlap in time ". This would depend on the drift time and trigger 
rate. 
* In the case of 8 cm/us drift or 13 us drift time, throttled data rate 
without duplication / sub-event data rate with duplication ~= 87%. Therefore, 
subevent building does not cause too much duplication.
* We are exploring a new design with 3 cm/us drift or 35 us drift time, 
throttled data rate without duplication / sub-event data rate with 
duplication ~= 74%. If this would be the choice of working point, sub-event 
building would cause significant data overhead due to duplication (~30%). I 
would not recommend sub-event building in this case. 

Note: if we choose the 3 cm/us work point, the final data rate would be 
significantly increased when compared to the CDR number, due to the prolonged 
active timing window to match the drift time. 


Hope this would be helpful. I would be looking forward to other suggestion 
too. 

Cheers

Jin

______________________________

Jin HUANG

Associate Physicist
Brookhaven National Laboratory
Physics Department, Bldg 510 C
Upton, NY 11973-5000

Office: 631-344-5898
Cell:   757-604-9946
______________________________

From: Sphenix-tpc-l [mailto:sphenix-tpc-l-bounces AT lists.bnl.gov] On Behalf Of 
Takao Sakaguchi
Sent: Friday, October 20, 2017 2:29 PM
To: Purschke, Martin <purschke AT bnl.gov>
Cc: sphenix-tpc-l AT lists.bnl.gov
Subject: Re: [Sphenix-tpc-l] TPC trigger latency

Hi Martin,
 The brief answer is that SAMPA itself can delay its
data output by 192 samples in terms of ADC clocks
at maximum (it is programmable up to 192).

 This means effectively, ~90 beam crossings since we
will likely operate at 20MHz ADC clock. I would expect
that we also have delays in the FPGA by a few ticks
(I think this is programmable in some way).
 By the way, we may want to see the pre-trigger data
somewhat, so I think 80 ticks is a safe answer for TPC.
Takao


On Fri, Oct 20, 2017 at 1:09 PM, Martin Purschke <purschke AT bnl.gov> wrote:
To the TPC aficionados -

I'm in the process of compiling the "trigger latency map", usually
expressed as the number of beam crossings we can let go by before we
need a trigger decision. For example, the INTT allows for 70 ticks (data
from 64 crossings stored, plus 6 crossings before the data from a given
crossing reaches the FEM).

I'm aware that a number of assumptions will have to be made for the
answer, especially the assumption that we will be able to correlate the
streaming data with triggered events. This is both a matter of technical
feasibility and of the "waveform overlap fraction" for close-by events,
namely, can we afford the duplication of waveform snippets where they
overlap in time?  We believe that the answer to the former is a
tentative "yes" and to the second a "most likely". I recall a 6% data
duplication figure but might not remember it correctly.

JohnK and I started to discuss this and the assorted strategies. I would
ask you guys to toss that around some in the larger group so everyone is
on the same page. If you come up with an answer that is guaranteed to be
larger than about 70 ticks, you will not be constraint and can stop
calculating it more accurately.

Preferably I would like the answer before the end of next week, as we
want to get going polishing the CDR and this is the key number the LL1
triggers need.

        Thanks a bunch,

                Martin

--
Martin L. Purschke, Ph.D.        ;   purschke AT bnl.gov
                                 ;   http://www.phenix.bnl.gov/~purschke
                                 ;
Brookhaven National Laboratory   ;   phone: +1-631-344-5244
Physics Department Bldg 510 C    ;   fax:   +1-631-344-3253
Upton, NY 11973-5000             ;   skype: mpurschke
-----------------------------------------------------------------------
_______________________________________________
Sphenix-tpc-l mailing list
Sphenix-tpc-l AT lists.bnl.gov
https://lists.bnl.gov/mailman/listinfo/sphenix-tpc-l



-- 
Takao Sakaguchi
Brookhaven National Laboratory
Physics Department, Bldg. 510C
takao AT bnl.gov
Office: 1-631-344-3345