Hello!

I apologize that there was some confusion about the recent integration work.  I would like to clear this up, as this is a *major* step forward for this system which should be understood.

Here's what was done:

1) The GAB was configured to send a BC10 and/or term to the trigger framework.  This term is high for BC=10 and low otherwise.

2) This and/or term, sufficiently prescaled, was used to produce L1As that were sent to our test stand, causing the TAB to be readout.

3) While the run was going on, we spied at the data sent to L2 and L3, and verified that it always had BC=10.

This is the first time that we have closed the loop, i.e. been responsible for the trigger that caused us to be read out.  We've sent and/or terms before, and we have been read out before, but we have never used our and/or terms to cause us to be read out.  It's the first time we have used our trigger as a trigger!

This is a stringent test of the core hardware functionality of the system. It also shows that the timing of the TAB/GAB system is internally consistent.  From the hardware perspective, the only difference between this test and generating a physics trigger is merely the choice of algorithm!

To put this in perspective, I see three major verticle-slice integration tests of our system:

1) Comparison of L1Cal2B TTs to precision data (DONE).

2) Generate a BC10 trigger with the GAB and read out our system with it,
   check that the data read out has BC=10 (DONE).

3) Generate a trigger with the GAB which is high any time one of the
   instrumented BLS inputs is high.  Use this to read out our system and
   the precision data.  With this sample, compare the L1Cal2B TTs
   to the precision data.

Please note that with 1 and 2 in hand, it is a very small step to 3, so I expect to do this within a week.

cheers,
mike

Hello!

After many firmware changes, driver fixes, and head scratches, the GAB is now fully timed in with the TAB and ADF in the online environment.

For proof, I bring the "head" of a L2/L3 buffer for a BC=10 L1
accepted event read from diagnostic memory on the GAB:

S30 level 2 output memory:
status:  0
bc:      10
...

As you can see, it is BC=10 as it should be.  Just one number, but it has made it's way from the ADFs into the TAB SWA chips, then to the TAB global chip, then to a GAB LVDS chip, then into the GAB S30 chip, and now it is being sent off to L3.

I also made many cross checks that the parameters behave as they are supposed to when adjusted.  As always, you can see the gory details at:

http://www-clued0.fnal.gov/~mulhearn/log/l1cal/

This means we are ready to make a real latency measurement into the Framework, and that we are ready to start sending our own L1Cal2B triggers!

cheers,
mike