**Nov 4 2005, on using Lvl-1 for Heavy-Ions:**

Hi Melynda,

I don\'t know if anyone else replied to you on this, but I think that

we have been mostly thinking about triggering in pp. In HI collisions
the

false trigger rate for displaced vertices from combinatorics is probably

unacceptably high.

Now, having said all this, Vince and I spoke at length at PANIC

about combining the forward upgrade trigger, MuID LL1 and FVTX to
provide a

good trigger for tracks that stop in the MuID - it\'s my understanding
that

the systematics associated with pion punchthrough are a big problem for
the

single muon analysis at the moment. Not clear we need such a complicated

trigger for this, however\...

Regards,

John

\> \-\-\-\--Original Message\-\-\-\--

\> From: Melynda Brooks
\[[mailto:mbrooks@lanl.gov](mailto:mbrooks@lanl.gov)\]

\> Sent: Tuesday, November 01, 2005 4:04 PM

\> To: \'John G. Lajoie\'; \'Craig Ogilvie\'; Brian A. Cole

\> Subject: Question about using silicon for lvl-1

\>

\>

\> Hi all, especially John and Craig,

\>

\> I was working on putting together the numbers that I thought were

\> relevant to start this discussion with Brian on our PHENIX interface

\> board for the silicon, and the question came up of whether we should

\> consider silicon being used for triggering in AuAu events. I thought

\> you Iowa folks would want to weigh in, and the reason why I ask is

\> because our readout latency will not drive the number of readout
lines

\> we have per chip (I think) unless it needs to be read out in a
certain

\> (small) number of clocks in AuAu when the hit rate is more
significant

\> per chip. Anyway, if we should be considering this possibility, let
me

\> know. I initially thought we should since single muon triggers in
AuAu

\> are rather ineffective now, but others said we were only to be

\> considering triggering in pp or other low-occupancy events.

\>

\> Melynda

\>

\> \--

**Nov 21, 2005 on input to Lvl-1 Board**

Hi Melynda,

As it exists for the Phase-I STTR work, the input to the LVL1

trigger was designed with units called a \"formatter\" and \"sorter\"
that can

handle the asynchronous input streams from the FVTX. To make it as
simple as

possible, this could operate on a copy of the data stream coming from
the

FVTX itself.

As for the physical interface (copper, fiber, etc.) we had been

assuming for the full FVTX that this would be fiber. The FPGA interface

design is generic, and in principle (with some interface logic) we can
take

whatever format is most straightforward for you to provide.

We have been working with a model that has a FVTX LVL1 trigger unit

covering either one octant or one-half octant, depending on the

complications in handling the data at later stages in the algorithm.

I guess that this really isn\'t much in the way of answers, other

that to say we\'re pretty flexible. I do like to idea of working with
the

FVTX data stream directly, however, rather than putting it through too
much

intermediate processing. Because the data is coming in asynchronously,
and

we can\'t take more than some occupancy, there is the potential at every

stage to have to drop data. Less stages, less complication, and the
limits

are more clear.

Hope this helps, let me know if there are additional points that

need clarification.

Regards,

John

\> \-\-\-\--Original Message\-\-\-\--

\> From: Melynda Brooks
\[[mailto:mbrooks@lanl.gov](mailto:mbrooks@lanl.gov)\]

\> Sent: Monday, November 21, 2005 12:33 PM

\> To: \'John G. Lajoie\'

\> Subject: Interface requirements for silicon\--\>Lvl-1

\>

\>

\> Hi John,

\>

\> I was trying to summarize all the possible I/O requirements for our

\> \"interface board\" for the FVTX, and was wondering if you could give
me

\> any details about interfacing to Lvl-1 since I realize I know nothing

\> about even current PHENIX lvl-1 data streams. Is it copper interface
(I

\> assume)?, do you anticipate some number of lines (\>\>1 or a few)
going

\> between the silicon and the Lvl-1 board? What would the segmentation
be

\> (all silicon\--\>one lvl-1 board or\...?) Is there any particular

\> formatting you expect to be done by our board before passing data to

\> you?\...

\>

\> Melynda

**Jan 2, 2006, Lvl-1 Brainstorming between Craig O. and John L.**

Hi Craig,\
\
    Some comments on your brainstorming:\
\
    When I started to reply to your message, I implicitly assumed that
we were looking at pp triggers, since that is where we need to largest
rejection factors. However, if we are talking about going into the
RHIC-II era (when all the upgrade systems will be available)  we really
need to address not just AuAu but a gamut of lighter ion species as well
(mass goes down, luminosity goes up\....)\
\
    I believe that the need for improved triggers is primarly driven by
the single-track physics, not by the pairs. The MuID LL1 with a
1-deep/1-shallow requirements had a rejection factor in Run-5 of
something like 6000.  That would easily get you all of the pair physics
(J/Psi,B-\>J/Psi, etc.) up to the highest pp luminosities.  I would need
to dig up rejection numbers for a 2-deep trigger in AuAu but I would bet
it would be such that you would have to consider the the complexity of a
combined LVL1 system trigger vs. the gain in sampled luminosity. So,
offhand, I don\'t think the pair physics drives the trigger
requirements.\
\
    As for the singles, one man\'s background is another man\'s signal.
The forward upgrade muon trigger is designed to include a momentum
measurement so that it can reject those pesky muons from bottom and
charm decay and trigger effectively on very high momentum muons from W
decay.  There are several things to consider here (pp first):\
\
    (1) By the time we get to running the forward muon trigger
(2008-2009) will we already have a large enough sample of low-momentum
single muon physics on tape already?\
    (2) The idea has already been discussed that the forward upgrade
trigger could provide triggers in several momentum regions (say, above
and 2-3 cuts) which could then be prescaled at GL1. This would allow you
to take a prescaled sample of charm, a lower-prescaled (or maybe w/o
prescale?) sample in the momentum region where beauty is more prevalent,
and all the triggers above the W-decay momentum cut. \
\
    As for heavy ions, we haven\'t studied the forward upgrade trigger
in heavy ions yet (I have an undergraduate working on that this spring).
Will it help? Well, it can probably do \*something\* but as usual
combinatorics will rapidly degrade the rejection.\
\
    (As an aside something that this also being looked at is the
possibility of combining and NCC LVL1 with the forward muon trigger. The
NCC LVL1 would be mainly focussed on photons (pi0 and chi-C) but could
be matched with the muon track in the RPC\'s to make an isolation cut.
Not clear if this is really \*necessary\* for any physics, however.)\
\
    One final comment - in principle it\'s always possible to combine
LVL1 systems at the GL1 level, but what you lose is the ability to make
trigger decisions that make exact matches between trigger primitives.
For example, you can as for two displaced tracks in the FVTX and two
deep tracks in the MuID, but you can\'t guarantee a correspondence
between the two. If you want exact matches between trigger primitives,
that\'s much more difficult (more like an LVL1.5) and we need to make
sure that effort (and expense) is justified by the additional
rejection.\
\
Regards,\
John\
\
Craig Ogilvie wrote:

Happy New Year!

 

I spent some time reading the ftvx proposal and doodling with ideas for
what we might really like to do with a \_\_\_forward\_\_ lvl1 trigger
during RHIC-II. I tried to think about possible advantages of combining
information from the not-yet-designed processor that takes the Si hits,
the NSF-funded upgrade to the muon trigger that provides momentum
information, and the existing muid trigger. There are at least two
caveats to this email a) I do not know much about the NSF proposal (I
should know more) and b) these ideas are fresh, possibly flawed, and are
offered here to start a conversation.

 

I started from the following set of guidelines (my mother-in-law's
apple-pie was yummy at Christmas). LVL1 triggers should

 

> a)       be driven by a physics goal
>
> b)      achieve a large rejection factor (RF) so that the scaledown
> can be set to 1. I will not address RFs in this message as I am still
> struggling to run the latest version of PISA.
>
> c)       remove as little signal as possible. Note this is difficult
> in any displaced vertex cut, because placing a lower cut at even one
> times the decay distance of \~ctau\*boost removes \~ 60% of the signal
> (signal has dropped to 1/e)
>
> d)      if possible, meet multiple physics goals with same lvl1
> trigger

 

In this email I outline two strawman forward-lvl1 triggers that may or
may not be feasible: 1) (a displaced ftvx track with p-dependent cuts) &
(muid) and 2) (two ftvx tracks from the same vertex that project back to
mutr-lvl1 tracks) & (2 hits in muid). More details follow

 

Note that I use as a placeholder 1-D cuts on z, the same arguments hold
for 2-D cuts on DCA and 3-D cuts. Eventually we'll have to see which one
works best, but for now I will use 1-D language to keep it simple. I
also presume that we can find the zcollision to a comparable or better
accuracy than one track using all the ftvx hits.

 

Forward LVL1 triggers

 

> 1)       [Displaced single tracks]{.underline}. The physics goals are
> open charm, beauty to muons. This is discussed often in the fvtx
> proposal and was the prime trigger in our SBIR. Consider first placing
> a lower-limit vertex cut, i.e. selecting ftvx tracks that are more
> displaced from the collision vertex than a given value zlow. If you
> increase the value of zlow to 2-3 times the resolution of primary
> tracks then this removes primary hadrons, including those that
> punch-through to the muid. The downside is that zresolution is \~200
> microns, so a 400 micron cut is not so different than ctau of charm
> (with boost). So you do not want to increase zlow too far. Also
> increasing zlow reduces the purity of (charm+beauty muons)/(pion
> muons). To keep the purity as high as possible and to keep as much
> signal as possible, aim for as small a zlow as is consistent with
> resolution and RF.

 

> Many pions, kaons that decay will also satisfy this cut of displaced z
> greater than zlow. As is stated in the ftvx and sbir proposals, many
> of these decays can be removed by placing an upper cut on how far the
> displaced track can be from the collision. The ftvx proposal mentions
> zup\~1cm, i.e. zlow\<(ztrack-zcoll)\<zup. Decreasing zup reduces the
> number of pion decays in the sample, but going too close to beauty
> ctau starts to cut into the signal. In fact I started to worry so much
> about losing high-p charm and beauty decays with a zup cut that I
> thought of making zlow and zup both momentum dependent cuts.
>
>  
>
> Since the designs of the mutr and ftvx lvl1 are still fluid, I am not
> sure what sort of communication of information between them is
> possible, but I think this example makes it desirable to explore. Both
> the proposed ftvx and mutr-lvl1 find tracklets. These could be matched
> so that a momentum-vector was associated with each ftvx track that
> matched to mutr. If this is possible, then zlow could be made smaller
> for high-momentum tracks and zup could be made larger for
> high-momentum tracks. A lvl1 trigger could fire if

           

                        There was one or more (ftvx track that matched
to mutr track) && (matched ftvx track zlow(p) \<(ztrack-zcoll)\<zup(p))
&& (muid\>=1)

 

                  This removes a trigger-bias on high-p charm and beauty
decays.

 

> 2)       [Pair of tracks from same vertex]{.underline} The physics
> goals are J/psi, B=\>J/psi, upsilon, and Drell-Yan. I first started
> thinking about a B=\>J/psi trigger which would be very similar to #1
> above but require two tracks in the event. The downside is this would
> not be useful for other physics, and indeed a J/psi or upsilon trigger
> has exactly the opposite requirement, mainly that the tracks come from
> the primary vertex. So I started to wonder if we could design a
> trigger that satisfies both. A possible solution is a lvl1 could fire
> if
>
>  
>
> (two ftvx tracks matched to two mutr tracks) && (matched ftvx tracks
> have comparable ztrack) && (muid\>=2)
>
>  
>
> These tracks form a vertex that may or may not be displaced from the
> collision vertex and hence such a trigger could be useful for a broad
> range of di-muon observables.

 

Both these ideas are definitely at an early "brainstorm" level. Let me
know what you think

 

Craig

**Apr. 21, 2006---Question to John of do you want to do Lvl-1 with
LDRD**

Hi Melynda,\
\
   I\'ve cc\'d Craig on this email, since he may want to chime in as
well.  My personal feeling is that we should definitely try to preserve
and develop the LDRD configuration so that it can be mated to the
prototype trigger board we are developing as part of the SBIR.\
\
   The total latency of four clock ticks to accumulate the data from the
LDRD (or greater) is not deadly. We currently run with an LL1 latency of
something like 14 clock ticks, and the results from our phase-1
investigations have demonstrated that we can complete the algorithm in a
few RHIC clocks by running the FPGA\'s at much higher multiples of the
RHIC clock. My personal opinion is that even if this grew to eight
clocks (the latency of the BBCLL1 we could still have a shot to get an
in-time LL1 accept back to the experiment within the current latency.\
\
   However, even if we don\'t get an accept back in time with the
current latency, we still have some options. Just the act of setting up
the LL1 trigger (as a sort of chain test) would be enormously valuable,
even if the LDRD setup doesn\'t make the latency - think of everything
we will learn just trying top put all this together. If we are
enormously successful, and this is in and we want to trigger all of
PHENIX with it (!) we could still adjust the LL1 latency for the whole
experiment by a fixed number of clocks. The subsystems would still need
to verify their timing, but this could be done quickly.\
\
   To summarize, I think four clocks is comfortable and we could wait
longer if need be. Hope this helps.\
\
\
Regards,\
John\
\
Melynda Brooks wrote:

Hi John,\
\
  We are busy trying to come to a decision on the silicon configuration
for the LDRD and FVTX projects and are especially looking at whether the
planes should be tilted, to make most tracks incident normal, or not.
There are a lot of advantages to having them vertical but the main
drawback will be that the data sizes, especially for the LDRD which has
a fixed silicon and readout chip geometry, will be larger because we
will have more pixels hit per track.  Long-story-short: for the LDRD
would you like to maintain the option for triggering (even in AuAu
events?) because it is possible that some of the readout times may
become longer than the \<4 clocks that we were trying to maintain
before.  My back of the envelope says that they may still be o.k. but I
wanted to know up front what readout times we \_should\_ be trying to
meet.\
\
Melynda

**Apr. 25, 2006, More questions on latency of data to Lvl-1 (and answers
from John L.)**

Dear Melynda,\
\
   Here are some notes/thoughts on the LL1 requirements for the
FVTX/LDRD detectors.\
\
   The LL1 latency that we are currently running is about twelve clock
ticks (beam clocks). This is the time after a crossing of interest
occurs that the LL1 accept shows up at the FEMs. The spec is a maximum
of forty, but we haven\'t needed a latency that large. We could go to a
longer latency, if necessary, but each subsystem would have to shift
their timing and then check it with data. Not impossible, but relatively
disruptive.\
\
   Of the twelve clock ticks, it breaks down roughly as follows:\
     (1) one clock for data transmission of LL1\
   (2) seven clock ticks for LL1 decision (dominated by BBC LL1, which
takes seven clock ticks. The MuID LL1, a newer system with orders of
magnitude more data, takes three.)\
   (3) three clock ticks for GL1 decision\
   (4) one clock tick for accept flyback to FEMs.\
\
(This is all good to ±1 one clock tick.)\
\
   The relevant number of the FVTX/LDRD is (2), the maximum LL1 latency,
which is currently at seven clocks. This needs to include the time delay
to get the data from the FEM to LL1, or the time we need to wait for all
the chips to \"push\" their data up.  If we plan on 4-5 clock ticks to
get the data from the detector that leaves us with 2-3 clock ticks to
complete the calculation and get the decision data up to GL1. (Note that
I have already included the one clock tick to get the data from the FEM
to LL1 in (1) above.)\
\
   Based on the STTR Phase-1 studies, with enough logic in parallel we
believe the we can complete the LL1 calculation in 1-2 clock ticks, so
let\'s say 2-3 in case we need to buffer an output stage to get data to
GL1. Based on this analysis, everything sort of \"fits\" to within a
clock tick.\
\
   What would we do if it didn\'t fit? I would suggest that at the start
of the run, when we do the detectoring timing in and checks, that we
would extend the LL1 decision time (and hence the overall latency) by
several clock ticks to give ourselves a buffer. This way we would create
minimal disruption when we wanted to include a trigger from the LDRD
detector.\
\
   One comment - each LL1 system must give data for the same clock tick
to GL1, so they have to be synchronized. We do this with a delay buffer
on the output of each LL1 system. Extending the LL1 delay would be just
extending the delay buffer for the LL1\'s by N clocks.\
\
   Finally, a comment on getting the data to LL1. This has been
discussed a lot in the past and is still a somewhat unsolved issue. The
FEM will have to talk to the transmitters on the detector and handle the
demux, etc., so it can see the data. The easiest thing to do at this
point would be to pump a copy of the data back out over optical fiber to
the LL1\'s. As you can see from the above this would have to be done in
such a way that it didn\'t extend the natural latency from the detector
by too much.\
\
   Hope this helps, feel free to send questions\....\
\
Regards,\
John Lajoie

**A little clarification from John on Above:**

Hi Melynda,\
\
   Step (1) is the data transmission from the detector to LL1. In step 4
the GL1 sends an accept to the MTM, which fans it out to all the
appropriate granules (down to the FEMs).\
\
   That would be great if I you would let me know when to call in, I\'ll
keep the afternoon flexible.\
\
Regards,\
John\
\
\
Melynda Brooks wrote:

Hi John,\
\
  This is perfect.  But I\'m not sure if I understand your 1-4 steps
exactly.  The data transmission of LL1 is from where to where?  (from
the LL1 board to GL1 board?)  And the \"fly-back\" is the time to go
from the Gl1 down to the FEMs?\
  It would be great if you could call in when we once again discuss
including sending the data to LL1 and how best to do that.  I would
expect that will happen in the afternoon discussion, which is supposed
to be headed up by Dave W. so if you want to not stay on the phone for 8
hours, that would be the time to call in.  If you want, I can see that
some e-mail gets sent to you during the day to update you on when the
relevant discussion(s) is likely to take place.\
  I\'ll also include a summary of this in the intro talk to put
everything on the table I can think of up front.\
\
Melynda

**May 18, 2006: John's response to splitting the data stream at the FEM
to go to Lvl-1 (rather than the ROC)**

Hi Melynda,\
\
   That does make a great deal of sense - we talked about something
along these lines when we all met at BNL last fall. The LVL1 boards will
sit in the rack room, so the spplit can easily be done at the FEM. This
also make it transparent to couple in LVL1, since all it needs to see is
a copy of the datastream and this LVL1 can be worked on while the FEMs
are being debugged, etc.\
\
John\
\
Melynda Brooks wrote:

Hi John and Craig,\
\
  We\'re trying to get together a draft proposal for our electronics
readout from front-end chip to DCMs and need to include a proposal for
where the data splits off to go to Lvl-1.  After some discussions here,
it seemed that if we have a card at the silicon which does minor data
packaging to go to the FEM (which we are talking about being located in
the rack room) that we should just then split this data stream at the
FEM rather than at the first card.  Does this make sense to you?  Am I
remembering correctly that the Lvl-1 boards sit in the rack room
anyway?\
\
Melynda

**John's comments on segmentation for Lvl-1:**

Hi Melynda:\
\
Some comments:

FEM:\
\
Need more explicit information from Lvl-1 guys about what segmentation
would be desired/required.  May dictate our fiber segmenatation within a
ROC and how we would route fibers from ROC to Lvl-1 boards.  Should
evaluate whether Lvl-1 is putting constraints on the system that we
would prefer to relax.  If no issues than can just plan to ship all data
in all circumstances to Lvl-1.  If there are issues, may want to discuss
whether we can relax any requirements or not.

LL1 needs the data to come to it on an octant (or fraction of an octant)
basis, since the LL1 algorithm needs to get a segment of each plane in
order to do its job. Let me emphasize that there is way too much data to
be cross-stitching between LL1 trigger processors so we do need to get
the data from the FEMs in some rational manner.\
\
So, for example, what we would like to see would be each fiber coming to
LL1 be data from some phi segment of a single plane. Four fibers (one
from each plane) would give sufficient data to process triggers for that
phi segment.\
\
Hope this helps.\
\
John

Hi Melynda,\
\
   No, we don\'t need the data organized in constant opening angle.
Fractions of a plane or \"wedge\" will do nicely.  It\'s OK if data from
more than one plane comes across on one fiber, as long as the data from
different planes come from the same azimuthal segmentation. That may
just complicate things, rather than simplify them, but it may be
necessary to make maximal use of the fiber bandwidth into LVL1.\
\
John\
\
Melynda Brooks wrote:

Hi John,\
\
  Thanks very much for answering as I forgot to follow-up with a
specific e-mail to you.  The main question that came up yesterday is
whether we needed to worry about segmenting things in a given z-path
such that they follow a constant opening angle (as opposed to a constant
number of centimeters at each plane).  Maintaining a constant opening
angle does not match so naturally within any segmentation that we would
imagine, but if you say you just care about per-plane data then I think
that would fit in very well with our current discussions which assume a
fraction of a plane for the LDRD going to one ROC or a \"wedge\" in phi
going to one ROC in the DOED project.  We are imagining in the fvtx
project that we might combined different planes into a ROC/FEM in
addition, but the data from different planes would likely still be
delivered between the two on separate fibers so you could still get
per-plane information for Lvl-1.  If there\'s any other critical
information you think we might be missing, please pass it on.  Hopefully
we\'ll soon be able to present the plan for segmentation taking into
account Lvl-1 as well and you can comment once again then.  Thanks,\
\
Melynda

**Response to input speed to Lvl-1, 6/8/2006:**

Hi Melynda,\
\
   Since nothing is built, anything is possible. Having said this I
would say we would certainly like to iterate on anything that is
proposed. We plan to use Virtex-4/5 FPGA\'s with the encode/decode logic
in Si on the FPGA, and I think you can get versions of this that go up
to 10Gb. However, they very rapidly get very expensive.\
\
John\
\
Melynda Brooks wrote:

Hi John,\
\
  One other question on Lvl-1:  Do you care what speed fiber comes in to
your Lvl-1 board as long as there is a known receiver which can handle
it?  You may have seen the various discussions of 2.5 Gb, 6.35 Gb\...
output data streams (which is far from being decided) but I realized we
should find out from you if you have specific limitations on the lvl-1
board end.  Thanks,\
\
Melynda