Date: Fri, 3 Jun 2005 15:48:48 -0500 (CDT)
From: Alan L. Stone
To: d0-l1cal2b@fnal.gov
Subject: any shift in time to make trigger decision?
Al Ito has asked me again about this issue. Apparently, the people to
whom I directed his question were not able to give Al a satisfactory
answer.
Will the time between bunch crossing and when the L1CAL and/or terms are
received by the TFW change once the new L1 Cal trigger electronics are
installed? What is it now?
Has anyone produced a timeline for the L1 CAL trigger decision - from
BLS pick-off to ADF, through ADF to TAB, through TAB to GAB, through
GAB to TFW?
Appreciate any information.
Alan
*********************************************************************************
Date: Fri, 03 Jun 2005 17:26:11 -0400
From: Hal Evans
Subject: Re: any shift in time to make trigger decision?
Hi Alan,
We made a latency estimate for the L1Cal system in October of 2004. You
can find it on the web at: Hardware --> Latency
http://www.nevis.columbia.edu/~evans/l1cal/hardware/latency/latency.html
We need to update this with an actual measurement. But that only makes
sense once we have reasonably final firmware in place, including, in
particular the latest EM algorithm.
In the meantime, the estimate shown above can be used. It should be
fairly accurate since the most recent firmware has been designed to stay
within this budget.
Regards - Hal
*********************************************************************************
Date: Fri, 03 Jun 2005 17:03:22 -0400
From: Darien Wood
Subject: Re: any shift in time to make trigger decision?
Hi Alan,
I'm attaching the most recent latency table I have, which is now almost
three years old. It would be great to update some of the numbers in this
table with measurements from the sidewalk. In particular, the ADF filter
algorithm assumed in this table is much more complicated than what we now
plan to use.
http://www-clued0.fnal.gov/~alstone/D0Work/L1Cal/Installation/Notes/2002-06-26_latency.pdf
I think Hal was waiting for the new EM algorithm before redoing these
measurements, but these would affect only the TAB parts.
- Darien
*********************************************************************************
Date: Fri, 03 Jun 2005 19:15:05 -0400 (EDT)
From: Dan Edmunds
Subject: Re: any shift in time to make trigger decision?
Hello Alan,
> Al Ito has asked me again about this issue. Apparently, the
> people to whom I directed his question were not able to give
> Al a satisfactory answer.
I'm sorry, but if you have previously directed a note to me about this
then I missed it. This whole topic is more complicated than your
note indicates. Please read on.
> Will the time between bunch crossing and when the L1CAL and/or
> Terms are received by the TFW change once the new L1 Cal trigger
> electronics are installed ?
As you know the design of the Run II DAQ system requires that the
TFW must issue the L1 Decision for each beam crossing at a fixed delay
after the beam crossing takes place in the center of D-Zero.
To meet this requirement the TFW must demand that all And-Or Terms
that will be used to make the L1 Decision for beam crossing "N"
must have arrived at the TFW by no later than some fixed amount of
time after beam crossing "N" takes place. The systems that send And-Or
Terms to the TFW are free to send the And-Or Term, that represent
their analysis of beam crossing "N", to the TFW at anytime between
when beam crossing "N" actually takes place - up to this maximum allowed
latency.
The issue with the new Cal Trig is not that there will be a change
(compared to the current Cal Trig) in delay between beam crossing "N"
and when it sends its And-Or Terms to the TFW that represent its
analysis of beam crossing "N" but rather that the new Cal Trig will
violate the maximum allowed latency in getting its And-Or Terms to
the TFW.
The only way for the TFW to accommodate these "late" And-Or Terms
is for it to change the timing of when it issues the L1 Decision,
i.e. change the latency between beam crossing "N" and the L1 Decision
for beam crossing "N". Making that change is a big big topic
because it requires ALL of the detector systems in D-Zero to change
their timing. For some detector systems, e.g. systems that use
SVX chips to hold their detector data while awaiting the L1 Decision
this may be impossible if they are already using all the steps in
the SVX pipeline.
I have recently been told that this was discussed with the various
detector system back some years ago when the new Cal Trig was being
designed. I have no recollection of this (but we were not very
involved with the design of this system). If all of the detector
systems are going to be asked to change their front-end timing to
accommodate the new L1 Cal Trig then we need to remind them of this.
There are major things to be thought about, e.g. do we all practice
with the new timing before the shutdown ? Do we come out of the
shutdown with the old timing, make everything work, and then move to
the new timing.
> What is it now?
A good way to see this is to look at the And-Or Term section (the
3rd section down) of the TrgMon display on the web. You can get
there from the DAQ Shifter's page or by going to:
http://www.pa.msu.edu/hep/d0/l1/tcc/trigmon_snapshot_frame.html
The column labeled "FIFO" next to each And-Or Term shows how many
ticks (periods of 132 nsec = 7 RF Buckets) early that And-Or Term
is arriving at the TFW before it is needed to make an L1 Decision.
Big numbers, e.g. 20, mean that the L1 Trigger System that makes
that And-Or Term is very fast and is able to deliver its And-Or Terms
to the TFW with plenty of time to spare. Small numbers e.g. 0 or 1,
mean that that that And-Or Term comes from a L1 Trigger that is just
barely getting its And-Or Terms to the TFW right at the time they are
needed.
Note that from one sweep of TrgMon to the next these FIFO numbers may
change by a count. That is because they are not integers. The
input circuitry of the TFW allows the And-Or Terms to arrive at
anytime up to the maximum latency. Different systems send their
And-Or Terms at different time and the TFW lines up all this data
and then uses it to make the L1 Decisions.
The current L1 Cal Trig has And-Or Terms 1:31 and 128:159.
You can see that it delivers its And-Or Terms to the TFW with
9 or 10 ticks to spare.
In the TrgMon display, a "#" mark next to a given And-Or Term tells
you that at least one of the currently defined L1 Triggers is using
that And-Or Term.
> Has anyone produced a timeline for the L1 CAL trigger decision -
> from BLS pick-off to ADF, through ADF to TAB, through TAB to GAB,
> through GAB to TFW ?
As Darien's note indicates, the filter in the ADF-2 will take less
time than the fancy filters that were designed for 132 nsec running.
I will calculate the time time from the beam crossing until when the
Et values for that beam crossing are sent out from the ADF-2. Right
now I have many other things to do but I will work on this next week.
I want to take the time to make this a correct and well understood
number.
Thank you getting this topic into wider discussion, Dan
*********************************************************************************
Date: Sat, 04 Jun 2005 08:21:34 -0400 (EDT)
From: Dan Edmunds
Subject: More about - any shift in time to make trigger decision ?
Hello,
Friday evening, while we waited for the detector to be closed up
after the Cal Pre-Amp fuse replacement, I asked around the Control
Room if anyone had heard of the impending timing change that is
needed to incorporate the new L1 Cal Trig. Al Ito was the only
person who knew about this. The Fermilab Computer Usage Policy
prevents me from including in this note most of the replies I heard.
Changing the timing, i.e. the latency between the actual beam crossing
and the L1 Decision for that beam crossing, is a big big deal to most
detector systems. SVX based detectors (SMT and CFT) may or may not
be able to make such a change depending on where they currently are
in their pipeline. Many detector system consider this parameter to
be so fixed that its value is buried in their front-end firmware.
This timing is set by the TFW. By design the TFW does not make this a
controllable parameter. Its value is hard wired in firmware to prevent
any possible change.
If you folks have the proper experts at the Summer Workshop then this
would be a good topic to discuss. I do not think that the run
coordinators know about this. Be ready for a somewhat hostile audience.
> It would be great to update some of the numbers in this table with
> measurements from the sidewalk.
From the point of view of the ADF:
- The time between the actual beam crossing in the center of D-Zero
until the peak of the BLS signals has already been well measured.
It is a function of TT Eta (and a weak function of TT Phi).
There is an EM HD dependence. We already needed to know all this
stuff to operate the current L1 Cal Trig.
- The processing time is the ADF-2 does not need to be measured -
it can be calculated. ADF-2 Data Path firmware is not a pile of
asynchronous pulses or vaguely understood VHDL. It is a single
clock domain of fully synchronous logic. One just counts the
steps and multiplies by the clock rate.
- For a large class of ADF Filter algorithms (e.g. those that use
12 raw ADC samples and the reported Et from the previous BX to
calculate the Et value of the current BX) their timing in the
ADF-2 Data Path FPGA are all the same. During my long boring
talk at the production readiness meeting at MSU the filter part
is one of the things that was dropped at the end to save everyone
from another 2 1/2 hours of droning.
- I will be reticent to give a number until I'm certain that it is
correct and will not have to be changed later.
In looking at the latency table in Darien's note I'm trying to
understand what breaks the bank.
- What part of the new system takes the most time to produce
its And-Or Terms ?
- Is it the Cal-Trk Match ?
- If so, who is waiting for whom ?
e.g. is the Cal part ready first and it has to wait for the
Trk information to make the match. If that is the case then
we gain nothing by speeding up the Cal part.
If the Trk information is ready first then we gain by speeding
up the Cal part.
Is the problem just that once both Cal and Trk information are
ready that it takes a long time to do the match logic ?
- I see nothing labeled GAB in the table. GAB is what makes the
L1 Cal Trig And-Or Terms that are sent to the TFW.
- Is this table just the "critical path" and the critical path
is only the Cal-Trk Match ?
I'm sorry for the long note but this is a big change for most people
here. You are going to need to do some work to sell this at the
Workshop. I have no recollection of this issue until Al Ito asked
me about it a month or so ago.
Dan
*********************************************************************************
Date: Sat, 04 Jun 2005 10:33:43 -0400
From: Darien Wood
Subject: Re: More about - any shift in time to make trigger decision ?
Hi Dan,
Thanks for pursuing this.
I've included kj on the email so that he can comment.
A few answers:
- It is cal-track match which breaks the bank. L1cal by itself get to
the TFW earlier than caltrack.
- The table just shows the critical path. The CTT signals get to
caltrack before the L1cal signals.
*********************************************************************************
Date: Sat, 04 Jun 2005 09:27:31 -0700 (MST)
From: Ken Johns
Subject: Re: More about - any shift in time to make trigger decision ?
hi,
i guess i dont have much constructive to add.
many people on the experiment do not want any upgrades and will
throw as many roadblocks up in order to prevent them from going
forward. this includes both l1cal and l1caltrack.
it is correct that we (me) have done a poor job communicating with
the other systems and documenting the changes that would be needed if an
increase in trigger latency is required. it is also correct we should
update all the numbers in the timing table to see where we now stand.
my recollection is i did talk with the smt and cft people and i thought
they were both running on the 396 ns bc clock now instead of the 132 ns bc
clock. this would allow sufficient buffering depth for increased latency.
but yes, all this must be checked and detailed.
as a guide, the numbers in my (very old) spreadsheet show
l1cft info is available at l1caltrack at 1592 ns
l1cal info is available at l1caltrack at 2435 ns
this comes from bc to adf (650 ns), adf processing (1057 ns),
and l1cal processing (728 ns).
so yes, both l1cft and l1cal will arrive at the tf before the 3300
ns deadline (the l1cft info in fact has additional processing to get to
the tf but it is not relevant for this discussion and the l1cal has gab
processing to get to the tf but it is not relevant for this discussion).
both l1cft and l1cal decisions will be at the tf before the 3300 ns
deadline.
this leaves 3300-2435=864ns for l1caltrack processing (assuming
the above numbers).
the conservative l1caltrack estimate for an answer at the tf is
given as 1343 ns. this comes from mtcxx processing (681 ns) and mtm
processing (662 ns). so the balance is a negative 864-1343=-479 ns.
we can't do anything about the bc to adf time and the l1cft time is
irrelevant since the l1cal info arrives much much later at l1caltrack
than it does. that leaves adf processing, l1cal processing, and
l1caltrack processing. yes, these numbers have to be measured but even
if they came out with small positive balance that would be a dangerous
way to run (in my opionion).
also, because l1caltrack is the last in the processing chain it
is always going to be late (or blamed for being late) since people rarely
consider what is upstream.
..kj
*********************************************************************************
Date: Mon, 06 Jun 2005 08:25:27 -0400
From: Hal Evans
Subject: Re: any shift in time to make trigger decision?
Hi Dan,
Thanks for explaining this. Just to clear things up in my own mind -
the latency issue here is related to the Cal-Track match system (not the
L1Cal directly) right? If I understand correctly, the latency of the
L1Cal2b to the TFW should be within the current budget. However, the old
calculations that we did put the latency of the data we (L1Cal) send to
the Cal-Track match system right at the limit of what they can accept,
leaving enough time for them to do their internal matching algorithms
and transmit their results to the TFW. If the ADF latency decreases
substantially (and the TAB latency remain about the same) then we may be
able to avoid this limit.
Again, if I dredge the discussion of two years ago out of the back of my
mind, I seem to remember that of the three types of Front-End systems
that store data waiting for L1Accept (Muon, Cal and SVX-based) - only
the muon sytems needed substantial changes to increase their pipeline
depth if the TFW maximum latency increases.
I've linked the note that Boris, Tom and Sten wrote describing the
proposed changes to the muon FE firmware off the latency part of the
hardware page:
http://www.nevis.columbia.edu/~evans/l1cal/hardware/hardware.html#latency
Once we get new latency numbers for L1Cal - we should quickly revisit
this whole business.
Regards - Hal
*********************************************************************************
Date: Mon, 06 Jun 2005 13:02:26 -0400 (EDT)
From: Dan Edmunds
Subject: Re: More about - any shift in time to make trigger decision ?
Hello Ken and Hal,
Ken thank you for the detailed note Saturday morning.
> many people on the experiment do not want any upgrades and will
> throw as many roadblocks up in order to prevent them from going
> forward. this includes both l1cal and l1caltrack.
I share this concern. Thus I don't thing that it is feasible to give
a Run 2B Cal Trig Installation Talk at this summer's workshop where
step #1 is, "All existing detector and trigger systems must redo
their front-end timing". That is where our project stands right now.
> also, because l1caltrack is the last in the processing chain it
> is always going to be late (or blamed for being late) since people
> rarely consider what is upstream.
That's right, the match electronics are really a victim of the
problem not the cause of the problem but it is hard to get people
(even "scientists") to think about the whole picture.
> i did talk with the smt and cft people and i thought they were both
> running on the 396 ns bc clock now instead of the 132 ns bc clock.
Yes, CFT is clocking their SVX pipeline at 396 nsec. I don't know
about SMT. In any case I don't think that they will be very excited
about making a change.
- Remember for these systems this is controlled by firmware on
the other side of the shield wall.
- This is complicated for them because the gaps are not an integer
number of 396 nsec units.
- I recall problems they had getting all this to fit into the
logic resources that were never sized to do this job.
- Remember the odd/even event problems that they had.
- Remember the issue about, for all the BX's in a given Super Bunch,
some of the L1_Decisions come before the subsequent gap and some
come after the subsequent gap. Thus they have to dance around the
hick-up in their 396 nsec timing.
- Some fraction of the people who did the detailed work to
implement the 396 nsec SVX clocking are now gone from D-Zero.
For Cal precision readout there are similar issues. It's all
controlled by firmware. In this case some of it was done by a
summer student and I don't think that Dean has ever had the time
to go back and figure out how it all works or clean it up. There
were issues of "something being right on the edge" and some channels
being readout twice while others were skipped. Remember the weeks
of data taking that were junked because it took a while to discover
all the problems.
The Numbers
-----------
The following is my understanding of the current numbers. Thank
you Ken and Darien for helping me understand this table.
- All And-Or Terms from a given BX must have reached the TFW
by 3,300 nsec after that BX.
- The Track information reaches the Cal-Trk Match by about
1592 nsec after the BX.
- From the time that Cal-Trk Match has all of its input data
until it delivers its And-Or Terms to the TFW takes 1343 nsec.
So, if the only thing that mattered was the Track input, then
Cal-Trk Match has enough time to do its job and deliver its
And-Or Terms to the TFW within the time budget.
The problem is that the Cal input to Cal-Trk Match takes so long
getting there that it does not leave enough time for the Match
electronics to get its job done.
Comments to Hal's Monday morning note
-------------------------------------
> the latency issue here is related to the Cal-Track match system
> (not the L1Cal directly) right?
I'm pretty sure that out West in the state of Arizona it is legal
to shoot a person on sight for saying such a think :-)
> If I understand correctly, the latency of the L1Cal2b to the TFW
> should be within the current budget.
The table that Darien sent out has no information about when the
And-Or Terms from the GAB will arrive at the TFW so I have no
understanding about how close the And-Or Terms that come directly
from the L1Cal2b are to the time budget.
I hope it is OK, i.e. < 3.3 usec.
> However, the old calculations that we did put the latency of the
> data we (L1Cal) send to the Cal-Track match system right at the
> limit of what they can accept, leaving enough time for them to do
> their internal matching algorithms and transmit their results to
> the TFW.
The problem is that we are not "right at the limit" we are grossly
over the limit. In order to run with things the way that they are now,
we need the whole experiment to move its L1_Acpt Latency by 4 ticks.
That's a lot of work for everyone and I'm worried that people will tell
us to go away.
> I seem to remember that of the three types of Front-End systems that
> store data waiting for L1Accept (Muon, Cal and SVX-based) - only the
> muon sytems needed substantial changes to increase their pipeline
> depth if the TFW maximum latency increases.
- There are different section to the Muon system. I *think* that
they all have to take care of this change independently. For
one of the sections, PDT I *think*, it is major work.
- For Cal Precision readout there is a bunch of tricky stuff that
Dean will need to do that took a long time to get right in the
first place. Luckily I will not have to change the current L1 Cal.
- SVX based systems means the separate CFT and SMT systems and their
related triggers. I *think* these are all independent firmware
based systems with their own sets of experts.
- TFW itself changes both the latency with which it issues the L1
Decisions and (just like all the detector systems) the age of
the data that it reads out with each event. Neither of these
are super big deals but it is work that needs to get done and
tested.
> If the ADF latency decreases substantially (and the TAB latency
> remain about the same) then we may be able to avoid this limit.
The "filter latency" will decrease by *about* 100 nsec just because
with 396 running one does not need to look at a lot of ADC samples
after where the peak of the BLS signal should be for BX #N in order
to tell if the energy deposit is coming from BX #N or #N+1.
We should have talked about this a year ago. When the ADF-2 layout
of the ADF was being done we could have picked a different ADC and
save 120 nsec or so. Instead, ADF-2 uses the same ADC as on the
original ADF. This ADC has a 5 stage pipeline, i.e. we wait 165 nsec
between when the analog input is sampled to when its digital
representation is available at the output. Even the ADCs in the 1987
design Run I Cal Trig did this job in 40 nsec. It's very sad to have
squandered the opportunity to save 120 nsec.
Dan
*********************************************************************************
Date: Mon, 06 Jun 2005 13:56:49 -0400
From: Hal Evans
Subject: Re: More about - any shift in time to make trigger decision ?
Thanks Dan,
By the way - the spreadsheet Darien sent out is not the most recent. You
can find one from Oct. 2004 on the web
http://www.nevis.columbia.edu/~evans/l1cal/hardware/latency/latency.html
The main difference here is that in the Oct 04 spreadsheet we made the
assumption that the Cal-Track system would not need an MTM (saving ~650
ns of latency). This puts us within the latency budget. But perhaps this
is now an incorrect assumption, Ken?
Regards - Hal
*********************************************************************************
Date: Tue, 07 Jun 2005 08:46:00 -0700 (MST)
From: Ken Johns
Subject: Re: Latency estimate
hi,
re mtm. your statement is incorrect. there was never any talk
of removing the mtm (trigger manager) from the l1caltrack system. there
was talk of removing the mtcm from the l1caltrack trigger chain. and
in fact we designed the l1caltrack system not to use the mtcm (as part
of the l1 trigger chain) in order to decrease latency.
the numbers i sent earlier this week reflect that design (sans mtcm).
*********************************************************************************
Date: Tue, 07 Jun 2005 09:23:42 -0400
From: Hal Evans
Subject: Latency estimate
Hi all,
Attached to this mail are two spreadsheets that summarize the
information we have as of now about L1Cal and L1Cal-Track latency. I'm
sending them out to a limited list because the story is still not
complete. It would be good if we could understand this internally before
Vancouver.
The first spreadsheet (latency_v3.xls) is an update of the latency
estimate. I just got new numbers for the TAB part of the latency (thanks
Jaro!). These are a bit less than the previous estimate, which can be
found at:
http://www.nevis.columbia.edu/~evans/l1cal/hardware/latency/latency.html
We still need the following information:
1) new ADF latency estimate
2) clarification on whether the MTM is necessary in L1Cal-Track (in the
last iteration there was some hope that this wouldn't be needed).
The second spreadsheet (pipeline.xls) is a summary (from Darien, I
think) of our discussions in July 2002 with other sub-detector groups on
their readout pipeline depths. As Dean pointed out, we will also have to
talk with the FPD and Luminosity people if we decide any changes are needed.
Please send me any comments you might have on this. The aim is to have a
clear(er) picture by early next week.
Regards - Hal
Attachments:
http://www-clued0.fnal.gov/~alstone/D0Work/L1Cal/Installation/Notes/latency_v3.xls
http://www-clued0.fnal.gov/~alstone/D0Work/L1Cal/Installation/Notes/pipeline.xls
*********************************************************************************
Date: Fri, 10 Jun 2005 18:09:09 -0400 (EDT)
From: Dan Edmunds
Subject: Latency, BX to BLS Peak, ADF-2
Hello,
I have been asked to provide timing information on two parts of the
new L1 Cal Trig system: BX to peak of BLS signals in the MCH-1, and
peak of BLS signal to ADF-2 channel link output. I thought that I
would be able to report two nice crisp numbers but both of these
topics became much more complicated than I expected.
In the case of the latency in receiving the peak of the BLS signal
this is complicated because of the way that things have been measured
in the past and because there are choices that can be made (if saving
50 nsec makes a big difference to the project). In the case of the
ADF-2 specifying its latency is complicated because it can be made to
go faster at the expense of some flexibility.
Executive Summary
-----------------
If you need/want to understand the issues and uncertainties
please read the two following sections. If you just need two
tentative numbers here they are:
BX to Peak of BLS signal at the ADF-2 card: 700 nsec
BLS signal Peak to ADF-2 Et MSBit output: 758 nsec
Note that the latency through the ADF-2 card is independent
of the details of the "Filter" for a large class of filters
that use as input up to 12 ADC samples and the Et output value
from the previous beam crossing. An additional 120 nsec
could have been cut from the ADF-2 by using ADCs with lower
latency. The ADF-2 latency specification is to the end of the
Et value transmission, i.e. through the MSBit transmission.
BX to Peak of BLS signal in MCH-1
-----------------------------------
In the spreadsheet from 26-JUNE-2002 that Darien sent around a week
ago, the latency from the BX to the peak of the BLS signal at the ADF
is shown to be 650 nsec.
This number comes from early Run 2A (August 2001) measurement of the
BLS signals right as they come out of the long blue BLS cables. This
number may or may not contain a 20 nsec error caused by my initial
uncertainty in Run 2A about exactly where the Master Clock was wrt the
BX. This uncertainty was caused by a disagreement between the Level 0
photo-tube signals and the Master Clock beam pickups at the 20 nsec
level. All of this was complicated because the beam pickups had been
moved between Run 1 and Run 2A.
In any case, we must now add to this 650 nsec number the delay in the
new BLS Cable Transition System. I do not have scope measurements
for this. The pleated foil cable itself is 1.51 nsec/ft. It is safe
to say that the delay is not more than 25 nsec.
Since the initial BLS signal latency measurements in 2001 we have made
many hundreds of measurements of the BLS signal timing in the current
L1 Cal Trig. A big study of this was done in July and August 2002
with additional measurements made in December 2002 and January 2003.
I have all of these numbers and I went through them this week.
I did not understand until this week that there is a problem with
directly using this data to specify the delay between the BX and the
BLS signal peak in MCH-1.
- The point of all these measurements was to verify that the
current L1 Cal Trig was sampling the BLS signals at the correct
points in time. That is, that the ADCs were clocked at the
correct time wrt the actual analog input signal to the ADC chip.
- To make these measurements we use the ADC Clock monitor signal
and the ADC Input monitor signals from the CTFE cards. These are
LEMO monitor test points that let us directly measure what we
care about, i.e. that the ADC's are clocked at the right point
in time wrt their analog input signal.
- We know at the nsec level the timing of the BX signal from the
Master Clock wrt the ADC Clock signals. This is not a problem.
- The problem is that the actual analog input to the ADC is not
the raw BLS signal, but rather the BLS signal after it has gone
through considerable analog signal processing and filtering on the
CTFE card. The delay of this analog processing and filtering is
about 50 nsec but it is somewhat waveform dependent.
- In any case, it is this uncertainty in how long the analog signal
processing takes on the CTFE cards that is right now preventing
me from turning the many hundreds of measurements that we have
from July, August, December 2002 and January 2003 into absolute
time measurements of the BLS signal peak arrival in MCH-1.
- When I'm at Fermi next week I will work on this and measure more
raw BLS signals as we did in 2001. We have not directly measured
BX to raw BLS signal timing since 2001 because that is not what
was important to running the current L1 Cal Trig.
In any case the latest BLS signal peaks to arrive at the trigger will
be those from high capacitance Had calorimeter elements. Because they
are very flat at the top one could try to sample them early. How
much loss in HD Et resolution this would imply for these TTs is not
known. But, if 50 nsec would "save the experiment" then this could
be looked at.
In any case, for today I would like to call the BX to BLS signal peak
at the ADF-2 card 700 nsec. This is adding 25 nsec for the BLS
Cable Transition system and 25 nsec of uncertainty to the existing
650 nsec number.
BLS Peak at ADF-2 to Et Output from ADF-2
-------------------------------------------
This topic is very complicated, not because it is hard to calculate
this number, but because there are so many choices available. If by
giving up on most of the potential flexibility in the ADF-2 one could
make the overall system go fast enough to get the Cal-Trk Match And-Or
Terms to the TFW in time (without changing the L1_Acpt Latency) then
that might be the best thing to do.
Examples of choices:
- Allow time for more sample during the long flat peak to be
used in the "filter" with the intent that better low-pass
filtering will improve the Et resolution. Two more samples
costs 66 nsec.
- The BLS signals arrive at different times. All channels are
made isochronous by delaying the earlier signals in digital
shift registers. But there is an advantage in taking enough
time so that you can also delay the slowest channels for a
couple of steps in these shift registers. The advantage is
that you can then prove, for all channels, that you are sampling
them at the correct time. Specifically what you want to be
able to see is that moving a given channel either earlier or
later reduces that channels response wrt Cal Precision Readout.
Giving up this check for the slowest channels would save 66 nsec.
The 758 nsec latency for the ADF-2 card specified above is a middle of
the road compromise on such considerations.
Thanks, Dan