<!-- Title: 16:00:12  Mon Nov 12 2001 -->
<!-- Crewchief: L2 -->
<!-- Op1: SVT -->
<!-- Op2: et al. -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
<pre>Last week (or 2?) before collisions</pre>


<!-- Date: Mon Nov 12 16:09:22 2001 -->
<pre>L2 Meeting 11/12/01 
 
Clist - The Clist boards worked fine at Michigan, but don't work 
well at B0. In the lower crate, the board works (at least  
works better) than in the upper crate. Monica will take the  
2nd Clist board to CDF tomorrow to try that one out. 
 
MagicBus - The PO was yet further delayed in the Michigan system 
 contrary to reports given on Friday. 
 
Reces tests - see elog report for details. Problems seem to  
be in the Reces boards and not the SMXR. 
 
Isolation - the other 4 isolation sums are fine. Previous  
 "errors" were simply bugs in offline analysis code. For the 
high rate run from last week, Sum 4 had 5 events with energy  
errors and Sum 5 had 1 event with energy errors. This is 
out of 11K events. 
</pre>
<!-- Author: Stephen -->


<!-- Date: Mon Nov 12 19:57:25 2001 -->
We tried to do integration tests with L1, sVTlist, and XTRPlist, using L2_Torture.  We got DTO's, and it appeared that one of the boards was sending many dstrobes.  But we couldn't see this on the scope.  The alpha was complaining about large numers of svt words, but we didin't see this in trigmon.  We also saw errors about too many clusters, although clist was not there.  We unplugged all the boards, one at a time, but still had problems.  Finally, Fision read errors prevented the crate from working at all.(There were no boards in the crate at this point.)  Power cycling did not help.  
<!-- Author: Matt, Jane, Jeremy -->


<!-- Date: Mon Nov 12 23:46:33 2001 -->
reading the above entry, I am dreading beginning my runs.  So, as an update (I'll summarize work later), I connected pins 1 and 16 on a dip switch with a wire.  this switch was thrown so it should have already connected those two pins, but we thought perhaps the connection was flakey.  I checked very carefully all pins on the switch after the wire fix, and they are all okay.  I didn't do anything bad to the board.  This was at noon today.  When I tried to run with CLIST both in the top and bottom of the crate it now sends out *0* MB words all the time.  But the signal I ran the wire for which was always high (bad) is now fixed and looks beautiful!  ha.  
<!-- Author: hray -->


<!-- Date: Tue Nov 13 07:57:13 2001 -->
First - when I came in last night I opened minicom and vxlogin to de00 and ALPHA and tried to run.  In Vx on CS see VME BERR errors - lots of them.  As Matt said, powercycling, pressing reset on CPU, reset on ALPHA, VME reset on ALPHA didn't help.  I sawpped alpha in top with alpha in bottom.  ALPHA in de00 is now SN D-3.  ALPHA in de01 is SN D-1.  SN D-2 is still the spare D ALPHA.  All runs taken in 00 after the swapping of ALPHA worked fine  
<!-- Author: hray -->


<!-- Date: Tue Nov 13 09:00:10 2001 -->
<ul> 
CLIST SUMMARY FROM SATURDAY AM - MONDAY PM 
<li>sat - for events we think are no MB words events (now directly correlated with no info) we see on LA L1A, EOE, and DDONE*.  RCLK, FIFO_EMPTY*, LOC_REQ, LOC_BOSS, MB_DONE_OUT never seen and held low.  CLIQUE_END (copy of EOE) never seen and held high. 
<li>sun - tried to attach probes to LOC_REQ, LOC_BOSS, BOSS signals in chips on boards.  some pins so small couldn't get probe attached.  Other pins I did get the probes around but LA doesn't ever show these signals present - even if I trigger on them.  This doesn't make sense as we were seeing MB words some of the time. 
<li>mon - came in to system running in cosmics with all cal crates and l2de with CLIST and L1 only in.  CLIST erorrs, sending 0 MB words part of the time  
<li>spent the morning running with COSMICS_NOTRACKS[3,205], calib continuous, only l2de and l2cl crates, cable unplugged in dcas 9 top, crate 01.  (calib cont = no L1 board in de crate) 
<li>tried to fiddle with pin connections again to see LA signals, no success.   
<li>ran and looked at scope on back.  <a href= 
'/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=27&frame=2&anchor=09:03:50'> 
see this pic </a>.  with cable pulled see healthy dstrobe/boss signals.  TrigMon shows 0 MB words part of the time 
<li>on a whim try moving CLIST to bottom crate.  run with iso in slot 6 and clist in slot 13.  iso not cabled.  see scope traces exactly the same as above, but this time TrigMon shows CLIST always sending MB words, and the correct number to boot. 
<li>connect LA.  still no internal signals, but see L1A and EOE 
<br><br> 
SUMMARY TO THIS POINT: seeing CLIST send 0 MB words some portion of the time.  LA shows EOE and L1A but no internal signals.   saw this with : l2cl, l2de, calib cont, dcas cable pulled, only CLIST in de; all cal, l1/l2, CLIST and L1A in de, no dcas cable pulled; l2cl, l2de, calib cont, dcas cable pulled, only CLIST in de in DE01 
<li>consult with MT.  CLIQUE_END always High indicates to her that maybe spurious EOE haven't been cleared (WCLK clears).  connect a wire between pins 1 and 16 on dip switch I16 (switch is thrown so these should be connected, but possible flakey connection) note: I checked all pins on this switch with ohm-meter.  I did not do anything else to this board other than to those two pins.  All connections for the dip switch are showing appropriate resistance.  keep this in mind.... 
<li>put CLIST in 00, don't pull DCAS cable, now see 0 MB words ALL the time.  Running with all ccal, wcal, l1.  L1 sending words just fine.  signals on backplane show only L1 interacting. 
<li>powercycle and reseat CLIST.  same thing.  on LA still see no internal signals but now see 10 - CLIQUE_END signal all the time.  well, at least that's a success. 
<li>try running with only l2cl/l2de/pulled cable/calib cont/CLIST only in crate, as earlier conditions today.  still 0 MB words all the time. scope only sees STARTLOAD 
<li>try moving CLIST to 01 crate.  no difference. 
<li>in 00 try plugging in SVTlist with no cable connection.  doesn't help.  try running with all ccal, wcal, l1, l2, l1 interface board.  doesn't help.  only see one signal on scope for boss/dstrobe (from L1 board) 
<li>checked CLIST/LOCOS/CLIQUE connections - all there 
<li>Tues - resorting to holding my head until MT shows up 
</ul>
<!-- Author: hray -->
<!-- Comment: Tue Nov 13 09;13;16 comment by...h -->
sometime between the soldering of the wire and the holding my head I had gone home and come back.  In that time Matt had VME problems with de00 crate, so when I returned I swapped ALPHA from 00 to 01.  This AM Masa tried a very very short run with de01 to read ReCES - and it worked!  So, it appears the VME problems weren't related to the ALPHA being bad/broken.


<!-- Date: Tue Nov 13 16:29:38 2001 -->
<pre>Reces test: 
 
 Investigated remaining 6 bad channels. I succeeded to read 
out the 3 chennels at West phi=6--8 by swapping the MBus 
adress for the Reces board 0x400 -> 0x500 (changed by  
dip switch on Reces). When I changed the board with original 
adress 0x500 to 0x400, I can still read out the board 
successfully. So it is not Alpha problem, but the Reces board.  
 
 I will swapp the Reces board adress between 0x400 and 0x500, 
and also 0x600 and 0x700. Then we would like to try another  
test with DAQ. 
 
 
 
  
 </pre>
<!-- Author: masa -->


<!-- Date: Wed Nov 14 17:17:47 2001 -->
<pre>Summary of Isolation tests today: 
Took many runs at 20 Khz with L1, xtrp, svt and 
Iso sending data.  Matt looked at a couple 
of the runs and said the xtrp and svt data 
looked fine.  The isolation data at 20Khz  
was 100% perfect in all variables  
if L2 clusters were made by unplugging a 
dcas cable,  but when running with the  
calorimeter itself a hot tower seemed  
to mess up either L2 clustering itself or it's 
transfer of information to the Isolation 
system.  The main symptom was events 
with 3 clusters merging into 2,  but 
also buffer, phi, and pass bits were  
incorrect at the 0.5% level.  </pre>
<!-- Author: Steve Kuhlmann -->


<!-- Date: Thu Nov 15 15:57:33 2001 -->
<pre>Reces test: 
 
(1) After optimizing the board adress setting, I suceeded  
to read all the 48 channels with DAQ. 
 
(2) I took data with XFTlist, SVTlist, Isolist 
in the L2 crate. Alpha gave "no more processing" timeout 
after ~100 events even with few Hz of L1A rate 
 
(2) Then, I took data with only 4 Reces boards are in  
the crate.I took 50K events with L1 rate 2kHz, L2 =L3  
rate = 50 Hz without no time out.  
 
 In summary, SMXR+Reces+Alpha works fine under Run control. 
Needed to test to be together with the other board. 
</pre>
<!-- Author: masa -->


<!-- Date: Fri Nov 16 01:05:06 2001 -->
<pre>Ran with 3 alphas at 20KHz with L1 and SVT boards sending 
data and Reces plugged in. These seem to work just fine. 
I've made a L2nullexe_nonmaster executable which is run in the  
additional alphas. This exe will reject every event. It is  
associated with most common physics tables. 
 
 
The crate configuration is alphas in slots 3, 6, 9 
L1 in slot 10, SVT in slot 13 and Reces in slots 15-18. 
I would suggest the following configuration as the default. 
 
slot   board 
----   ------ 
3      Alpha 
6      Alpha 
9      Alpha 
10     L1 
12     Track 
13     SVT 
14     Clist 
15     Iso 
16-19  Reces 
 
Obviously boards will be moved around for tests, but for  
default crate running, we should use the above configuration.</pre>
<!-- Author: Stephen -->


<!-- Date: Sat Nov 17 00:18:50 2001 -->
<pre>L2 tracking:<p> 
Took 2 runs with SVT06-07, XTRP, and L2 with calib continuous L1 triggers.  L2dec had 1 alpha, L1int, SVTlist07, XTRPlist03, and reces.  One run was at low rate with interval0 = 1m.  The second was at high rate with interal0 = 1k.  Neither run produced any disagreement between either SVTD or XTRD and TL2D.</pre>
<!-- Author: Matt -->


<!-- Date: Sat Nov 17 13:32:28 2001 -->
More L2 tracking:<p> 
Took L2 integration runs with L1int, XTRPlist, and SVTlist.  Trigger table: L2_TORTURE[3,205].  sEVB, XTRP, SVT and L2dec in thr runs.  Extra 1 = 1 with simtracks_check.dat, nosvx = jane.hfospy.<p> 
<b>132554</b>  tagging, L1A = L2A = 60 Hz, 99% dead.  57k events, 0 errors in TrigMon, all 3 interface boards.<p> 
<b>132559</b>  cutting, L1A = 17kHz, L2A = 3 Hz, 1% dead.  50m L1A, 10k L2A.  At the level of 0.5%, we see events in TrigMon with Ntracks in XTRD either 0 or 2,  when we expect only Ntracks 1 from this track pattern.  TL2D always has only 1 track.  Also at the 0.5% level, we see events with bad SVTD info: e.g. Ntracks = 0 when we expect only 3 or 5 and no end event word found in SVTD.  However, the all of the SVT info looks fine in TL2D.  Other than that, we see no errors.<p>
<!-- Author: Matt -->


<!-- Date: Sun Nov 18 09:28:23 2001 -->
<pre>Fixed the last known stuck bit in Isolation system, and 
ran standalone on all crates to confirm this.  
Bring on the beam...</pre>
<!-- Author: SK -->
<!-- Comment: Sun Nov 18 13;41;41 comment by...Matt -->
<pre>Hear hear!</pre>


<!-- Date: Sun Nov 18 18:15:05 2001 -->
L2 entropy tests:<p> 
Trigger table L2_TORTURE[3,205] with boards: L1int, Clist, SVTlist, XTRPlist<br> 
SoftEVB with crates: WCAL, CCAL, L1gl, L2de, L1/L2cal, XTRP, SVT<br> 
nosvx = stephen1; extra1 = 1 with simtracks_check.dat<p> 
<b>132683</b> tagging; L1A = L2A = 3.8 Hz; 99.9% dead.  No errors in any board.  End with 2200 events.<p> 
<b>132684</b> cutting; L1A = 1.3 kHz, L2A = 7 Hz; 94% dead.  Limited by readout deadtime because no HEVB available.  TrigMon shows no errors in Clist or L1int, and the mismatches in SVT and XTRP are consistent with those reported <a href= 
'/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=28&frame=2&anchor=13:32:28'>previously</a>.<p> 
<b>132685</b> cutting; L1A = 1.0 kHz, L2A = 6 Hz; 95% dead.  Added ISOlist to slot 20.  All boards look okay.  The ISOlist and L1int Validation code in L2TriggerMonitor doesn't seem to be working properly.  See the histograms below.<p> 
None of this data was marked 'to disk'.  We are leaving all 5 boards in L2 for the shift crew's cosmic running tonight.
<!-- Author: Heather, Matt -->


<!-- Date: Sun Nov 18 18:18:43 2001 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-440&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-440' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-441&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-441' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-442&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-442' width='300'></a></center>
<!-- Author: Heather, Matt -->
<!-- Comment: Sun Nov 18 18;21;42 comment by...Heather, Matt -->
<pre>Clist validation looks good.  Clist->Isolist comparison plot looks good.  But Isolist validation plot looks bad.  All plots from run 132685.</pre>


<!-- Date: Sun Nov 18 18:28:54 2001 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-443&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-443' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-444&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-444' width='300'></a></center>
<!-- Author: Heather, Matt -->
<!-- Comment: Sun Nov 18 18;32;16 comment by...Heather, Matt -->
Mismatches between TL2D and SVTD.  L2buffer = -1 in SVTD indicates that no end event word was found.  This is also seen in the SVTDMonitor and the SVTD-TFRD bc comparison.  We expect either 1 or 2 tracks from SVT.  However, we occasionally see Ntracks in SVTD = 0.





<!-- Date: Mon Nov 19 08:46:41 2001 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-449&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-449' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-450&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-450' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-451&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-451' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-452&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-452' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-453&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-453' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-454&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-454' width='300'></a></center>
<!-- Author: hray and matt -->
<!-- Comment: Mon Nov 19 09;22;45 comment by...hray mattie w -->
RUN 132704 taken last night with XTRPlist in slot 7, L1 in 10, SVTlist in 11, CLIST in 14, ISOlist in 20.  CLIST/clustering at L2 looks wonderful.  Lower level ISO problems, similar SVT problems seen earlier.  Note the two plots on the RHS.  They both show trigger bits from TL2D and TFRD.  The top one appears to have agreement between the two.  The bottom one seems to show errors in bit 23.  Not sure if this is a problem with how the plots are filled, or real.
<!-- Comment: Tue Nov 20 01;39;20 comment by...Matt -->
<pre>I don't believe that stuck bit 23.  The code in TL2DMonitor doesn't confirm it.  For now I would not use the L1interface monitor code in L2TriggerMonitor until it has been checked.</pre>
<!-- Date: Mon Nov 19 08:49:26 2001 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-456&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-456' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-457&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-457' width='300'></a></center>
<!-- Author: hray and matt -->



<!-- Date: Mon Nov 19 09:27:52 2001 -->
132724 run started this morning with XTRPlist in 7, SVTlist in 11, L1int in 10, CLIST in 14, ISOlist in 20, and ReCES in slots 15 - 18 (not cabled).  TrigMon CLIST and MB plots look good so far.
<!-- Author: hray and matt -->


<!-- Date: Mon Nov 19 13:16:36 2001 -->
<pre>Last Weds the Isolation energy mismatch rate was 2E-5,  last night's run was 0.7%, all coming from b0l2cl04.  The good  
news is that I was able to diagnose and fix the problem  
in an hour today,  the bad news is that it's another  
"DCAS slot 9" problem.   This is where there appears 
to be a weak connection between the DCAS card 
and the backplane, causing signals to be missed. 
Sunday I fixed two bad data bits in crate 2 slot 9,  today 
it was the Iso_Ready handshaking signal in crate 4. 
The fix is to put a jumper between the pin on the back 
of the crate and the same pin in slot 10, so it acts as  
a spring and helps the connection.  Kludgey but so far 
it works.  More worrisome perhaps is that this slot 
had shown no signs of problems until last night.  
 
</pre>
<!-- Author: Steve Kuhlmann -->


<!-- Date: Tue Nov 20 01:37:03 2001 -->
L2 rate tests<p> 
trigger table L2_TORTURE[3,205]<br> 
crates: all CAL, SVT06-07, XTRP, L1gl, L2de, L3<br> 
boards: XTRPlist, L1int, SVTlist, Clist, reces, ISOlist<br> 
Extra 1 = 1 with simtracks_random.dat; nosvx = stephen1<p> 
<b>132819</b> tagging; L1A = L2A = 157 Hz; 99.6% dead; ran for 57k L2A.  TrigMon saw 775 events with no errors in L1, SVT, Clist, or ISO.  XTRPlist sent 0 magic bus words approx. 1/10 events.  However, the board did NOT lose sync with respect to FRED as we would expect from the XTRPlist board itself missing the end event bit.  Also, the track matching between XTRD and TL2D was totally off.  This behavior was observed with both XTRPlist boards (3 and 5).  We also see the yellow "XTRP sync" light come on in SVT.<p> 
<b>132821</b> cutting; L1A = 4.4 kHz, L2A = 20 Hz; 82% dead; ran for 1.9m L1A, 8760 L2A.  TrigMon saw 440 events with no errors in L1, SVTlist, or Clist.  ISO had a few Ncluster, L2buffer and eta,phi errors.  XTRPlist had the same problems as in the previous tagging run.  Also in this run, the XTRP crate itself gave frequent (about 1/min) DONE timeouts.  The low rate/high deadtime was from XTRPlist timing out.  After this run, XTRP was dropped and XTRPlist pulled and its slot jumpered.<p> 
<b>132824</b> cutting; L1A = 21 kHz, L2A = 107 Hz; 9% dead; ran for 5.2m L1A, 26k L2A.  TrigMon saw 600 events with no errors in Clist, L1, or SVT, and the same low rate of L2buffer and eta,phi errors in ISOlist.<p> 
<b>132825</b> cutting; L1A = 7 kHz, L2A = 85 Hz; 2% dead; ran for 1.8m L1A, 19k L2A.  Adjusted L1 prescales: trigger 1 from 101 to 256 and trigger 3 from 1 to 100 to get this rate.  TrigMon saw 500 events with the same results as the previous run.<p> 
<b>132827</b> cutting; L1A = 9.3 kHz, L2A = 98 Hz; 6% dead; ran for 2m L1A, 20k L2A.  Adjusted L1 prescales: trigger 1 from 101 to 250 and trigger 3 from 1 to 2 to get this rate.  TrigMon saw 510 events with the same results as the previous runs.<p> 
<b>132830</b> cutting; L1A = 22 kHz, L2A = 125 Hz; 2% dead; ran for 4.4m L1A, 25k L2A.  For this run, we put new firmware in SVTlist with a 17 us delay (possible because XTRPlist was out), so the max delay in the crate was now 17 us.  TrigMon saw 430 events with the same results as the previous runs.<p> 
<b>132831</b> cutting; L1A = 35.6 kHz, L2A = 80 Hz; 26% dead; ran for 27.6m L1A, 61k L2A.  With 17 us max delay (in SVTlist) Adjusted L1 prescales: trigger 1 from 101 to 50 to get this rate.  TrigMon saw 1900 events with the same results as the previous runs.<p> 
All of this data should have been sent to the look area for expert analysis.
<!-- Author: Matt -->



<!-- Date: Tue Nov 20 01:43:23 2001 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-459&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-459' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-460&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-460' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-461&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-461' width='300'></a></center>
<!-- Author: Matt -->
<!-- Comment: Tue Nov 20 01;46;50 comment by...Matt -->
Representative plots from L2 rate tests.  These plots are taken from 132831 (36 kHz) and show the type of matching seen in TrigMon for runs 824, 825, 827, 830, and 831 above.  SVTlist was in sync and showed only the low rate of missing SVTD data as reported previously for L2 cutting runs.


<!-- Date: Tue Nov 20 02:34:38 2001 -->
Multiple alpha tests<p> 
Plugged 2nd alpha into slot 6.  Marked L2_PROCESSOR_01 online in the hardware db.  The cables were setup as follows: ethernet: L2PR03, Com1: 3, TSI: L2-TS-02.  Checked that L2_PROCESSOR_01 was included in the L2_DECISION crate in run control.  Boards included were SVTlist, L1int, Clist, ISOlist.  Crate included were all CAL, SVT06-07, L1gl, L2de.<p> 
<b>132845</b> tagging; L1A = L2A = 157 Hz; 99% dead; ran for 42k L2A.  TrigMon saw 600 events with no unexpected errors in SVTlist, L1, and Clist.  ISOlist had an error in seed eta.<p> 
<b>132847</b> cutting; L1A = 19 kHz, L2A = 88 Hz; 19% dead; ran for 6.2m L1A, 31k L2A.  TrigMon saw 780 events with no erors in L1, SVTlist or Clist.  ISOlist had Ncluster, L2buffer, and eta,phi mismatches.<p> 
Comparing these multiple alpha runs to similar runs from the L2 rate tests above, the only difference in TrigMon is an increase from 9% deadtime (132824) to 19% deadtime (132847) in the cutting runs.
<!-- Author: Matt -->


<!-- Date: Tue Nov 20 03:28:41 2001 -->
Leave the system in the following configuration:<p> 
1 alpha (all others marked offline)<br> 
XTRPlist03 in slot 7, but not plugged in and that slot jumpered<br> 
L1interface in slot 10<br> 
SVTlist07 in slot 11<br> 
Clist in slot 14<br> 
Reces in slots 15-18<br> 
ISOlist in slot 20<p> 
We may not want to plug in XTRPlist for L2 integration runs until the issues with XTRP are understood.
<!-- Author: Matt -->


<!-- Date: Tue Nov 20 10:22:22 2001 -->
<pre>Ignore, just a test for indentation... 
 
L2CAL trigger is completely unresponsive. No MB words sent every time  
for CLIST SNO. 1</pre>
<!-- Author: monica -->


<!-- Date: Tue Nov 20 10:27:06 2001 -->
<pre>Nov 13.  Monica and Heather in B0 
------ 
L2CAL trigger is completely unresponsive. No MB words sent every time  
for CLIST SNO. 1. 
CLIST SNO 2 exhibits the same behaviour previously observed for SNO 1,  
i.e. erratic CLIQUE_END w.r.t. EOE* coming from CLIQUE. 
 
Test of single optical fiber outputs going into top CLIST fiber receiver 
shows that fiber to LOCOS input 1 is broken. Also visual inspection of  
fiber to LOCOS input 4 shows damaged lastic cover. 
 
While we wait for spare fibers, we start runnig tests with single LOCOS  
0 enabled (see ~jsm/alpha/clistconfig.c). Found two more problems: 
 
1) CLIST SNO 2 sends BOSSREQ but never becomes BOSS. We can see BOSSGRIN  
   arriving at backplane pin. Found that connection between   
   P3 and on board BOSSGRIN is missing. 
   Run wire to fix the problem. 
2) CIST SNO 1 never asserts BOSSREQ. Found that 
   synchronous clock connection into FIFO FPGA is broken. 
   Resoldering it fix the problem. 
 
 
Finally we get to exchange the 2 broken fibers and run a long cosmic run 
with full system (run 131934, with all CCAL and WCAL, Software EVB,  
trigger table COSMICS_NOTRACKS[3]).  
Analysis of run confirms that we got rid completely of  
"No MB words sent from CLIST" (-:   but two new problems show up  )-: 
 
A) all MB words sent from CLIST have BAD_ADDRESS bit set. Scope probing  
   confirms that all CRATE_SEL pins are always high. This explains why 
   (phi,eta) = (28,0) for all found clusters. 
   =&gt;  this is a consequence of latest fix to LOCOS boards. Now the  
       seed coordinates are latched by SEED_SEL which set ONLY when a  
       new seed is found in that particular crate. 
       We need to go back to a signal that is asserted for EVERY cluster. 
       Alternatevely, we need to clear that latch with a signal that 
       is asserted atthe end of each cluster. 
 
B) CLIST loses sync very soon; on LA analyzer we can see LOC_REQ being 
   asseted BEFORE EOE* for a given event, signalling that FIFO* has not 
   completely emptied itself from a previous event. 
   Studied this problem for the rest of the night, triggering on different 
   error conditions like MB_DONE_OUT still low when STARTLOAD* goes back high 
   or EF* still high when LOC_REQ goes back low 
   (see next entry for LA pics). 
   NB. One "empirical" observation is that this problem goes away either when 
   another interface board other then L1_Int is plugged in the crate or 
   when one unused MOD_DONE line is jumpered to ground. Also Having STARTLOAD* 
   low for a very long time, which happens when L1_Int is not plugged in the 
   crate (because of error reporting condition) DOES NOT fix the problem. 
 
 
Nov 14. Heather drives all of LOCOS boards back to Michigan. 
------ 
 
Nov 15-16. Heather and Monica at Michigan. 
--------- 
 
PROBLEM B 
+++++++++ 
Steve understands this new CLIST loss-of-sync condition. At very low rates 
and whenever CLIST or CLIST + L1_Int only are in the crate, Alpha asserts  
a very short STARTLOAD* on the first event because it does not have a  
previous event in the queue to analyze. Only thing that Alpha does  
in this case is to look at status of MOD_DONEs from all boards. If all HIGH, 
it clears STARTLOAD* and eventualy start analizing the event if second 
L1A takes too long to arrive. 
 
CLIST does not drive MOD_DONE low until internally delayed (~500 nsec) copy of 
STARTLOAD* is seen. That is, there is a time interval in which MOD_DONE 
from CLIST is still high even if CLIST has not yet started processing the 
event. STARTLOAD* is therefore deasserted even if CLIST is eventually  
processing the clusters, completely confusing the CLIST FIFO  
synchronous state machine.  
 
This condition is prevented if: 
- another board but L1_Int (whose MOD_DONE is ignored in the Alpha decision) 
  is in the crate because other boards driver MOD_DONE low right away. 
- some MOD_DONE is jumpered to ground 
which are exactly the conditions for which we saw the problem disappearing. 
 
The solution is to force CLIST to clear MOD_DONE whenever STARTLOAD* is 
not asserted, by using START_MB* in place of SREADY on the clearing  
condition for MOD_DONE. 
 
 
PROBLEM A 
+++++++++ 
 
We must find a good signal which can clear the (eta,phi) latches every 
event given that no other signal is available in place of SEED_SEL to clock 
that information in. 
 
We also have to make the whole BRD_HAS_SD -&gt; BRS_SEL logic in LOCOS more robust 
against differences in BRD_HAS_SD lenght due to propagation delays by 
making seed selection enable signal, CRATE_SEL, shorter than any BRD_HAS_SD. 
 
This second task is accomplished by changing the CLIQUE clustering  
protocol state machine so to clear CRATE_SEL as soon as a SEED is found 
(actually as sson as SEED_SEL is propagate thru the system all the way to  
LOCOS). New CLIQUE FPGA is version 5, revision 6, labelled as 111601. 
 
The first task can be solved if a delayed (and inverted) copy of CRSUM_SEND,  
used to latch the cluster info to be sent to CLIST via the HOTLink, is  
used as a clear to the (eta,phi) latching logic. The exact timing 
of CRSUM_SEND and its delay needs to be "fine tuned" because of  
one possible fatal condition: given that finding a cluster can happen 
simultaneously to the summing over the energy plus the cluster 
info transmission to CLIST of a previous cluster,  SEED_SEL for a second 
cluster come BEFORE the clearing of the seed position for the first cluster. 
 
We found that critical delays are: 
 
i) the delay between START_RIPPLE and CRSUM_DONE inside each LOCOS cannot 
   be longer than 100 nsec. 
 
ii) the delay between CRSUM_SEND and the inverted delayed copy that clears 
    the seed postion latches cannot be shorter that 15 nsec. 
 
We finaly settled on a delay for the inverted copy of CRSUM_SEND of 25 nsec, 
provided by a Dallas delay chip DS1005-125 mounted on each LOCOS. 
</pre>
<!-- Author: monica and heather -->


<!-- Date: Tue Nov 20 10:51:30 2001 -->
The time for swapping 2301 cpu with newer/bigger 2304 for the SVT crates has come. We will power cycle every SVT crate in the next 2-3 hours. Please do not rely on SVT crates until further notice.
<!-- Author: Marco r. & Lucia z. -->
<!-- Comment: Tue Nov 20 14;59;01 comment by...marco -->
<pre>5 new cpu installed. 8 2304 in svt crates (3 spares for CDF pool).</pre>
<!-- Date: Tue Nov 20 11:04:01 2001 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-466&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-466  width='300' align='top'></td><td>pod 0 = L1A*, pod 1 = HLINK_LE0, pod 2 = EOE*, pod 3 = FIFO_RCLK, pod 4 = FIFO_EF*, pod 5 = LOC_REQ, pod 6 = DSTROBE*, pod 7 = DDONE*, pod 8 = LOC_BOSS, pod 9 = DONE_OUT, pod 10 = CLIQUE_END,  pod 11/12 = CLIQUE_BUF0/1, pod 13 = FIFO_WCLK, pod 14/15 = END0/1, pod 16 = STARTLOAD*,  pod 17= MOD_DONE(0), pod 18/19 = MB_BUF0/1.  This first picture shows STARTLOAD* getting cleared even if DONE_OUT is still low. </a></td></tr></table>
<!-- Author: monica -->


<!-- Date: Tue Nov 20 11:09:50 2001 -->
<table><tr><td><a href=/elog/notebooks/l2/Tue_Nov_20_2001_110944.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-471  align='top'></td><td>let me try again. This is the picture I meant before,  follwed by a picute that shows the consequence of the condition above, ie. LOC_BOSS asserted before EOE* for the requested buffer.</a></td></tr></table>
<!-- Author: monica -->