<!-- Title: 10:56:00  Tue Mar 13 2001 -->
<!-- Crewchief: All trigger folks -->
<!-- Op1: ACEs -->
<!-- Op2: COs -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
<pre>Lots of work have been done in the past month.  
for details,see http://www-cdf.fnal.gov/internal/upgrades/daq_trig/trigger/meeting/minutes.html. 
 
time to start a new page!</pre>


<!-- Date: Tue Mar 13 11:08:39 2001 -->
<pre> 
 
           L2 TOP Priorities in the coming weeks:  
 
Hardware:  
 
(1) FULLY establish the following path:  
 
   * L1 decision -> L1 interface -> Magic bus -> alpha ->TS  
   * L2 CAL -> ClusterList -> Magic bus -> alpha -> TS  
 
    the two paths are almost working (not perfect yet), 
    next we should move on and really focus on:  
    HAVING Alpha making decisions based on both the  
    L1 (first) and L2CAL (next) trigger bits ! 
    this will be a major milestone for L2. 
 
(2) finish Jane's interface board preproduction testing 
     
  This is the number 1 top priority this week while Jane is here. 
 
(3) understand and fix alpha hang problem; 
(4) 2 interface boards (L1+CLIST/isoList) + alpha running;   
(5) Magic bus backplane loading test: (4) + other boards   
    plugged in the crate;  
(6) alpha workstation at B0 (generating L2 exe.)  
      alpha code in CVS! 
 
Software:  
(1) alpha code for L2 decision making based on both  
    L1 and L2CAL trigger bits;  
(2) tools to compare TL2D<->TC2D, TL2D<->TFRD banks;  
(3) TRIGMON/TRIGSIM with TL2D;  
 
 - Peter Wilson and Ted Liu</pre>
<!-- Author: Ted -->


<!-- Date: Tue Mar 13 11:14:27 2001 -->
<pre> 
schedule this week (requests so far): 
 
Monday: afternoon (Jane), night(Ted, L2CAL and top L2 crate) 
Tuesday: after 3:00 (Jane), before 3pm (SteveK) 
Wednesday: evening only (Jane, bottom L2 crate), SteveM?  
Thursday: morning and evening (Jane, bottom L2 crate),  
             SteveM, Monica (top L2 crate) 
Friday: evening (tentatively, Jane) 
 
anyone else?</pre>
<!-- Author: Ted -->
<!-- Comment: Tue Mar 13 11;39;20 comment by...Ted -->
<pre>Note that Jane's work has the highest priority this week. 
what that actually means is that if for some reason only
one L2 decision crate is working, she should have it whenever
she needs it. the same for Logical Analyzer, scope, 
as well as XTRP and SVT system access time.</pre>


<!-- Date: Tue Mar 13 15:12:41 2001 -->
<pre>I will use b0de01 for SVT/L2 integration tests.</pre>
<!-- Author: Jane -->
<!-- Comment: Tue Mar 13 21;01;16 comment by...Jane -->
<pre>I am finished with b0l2de01.</pre>
<!-- Date: Tue Mar 13 16:49:38 2001 -->
<pre>bent pins found on bottom L2 decision crate: 
 
 
there are many bent pins on P3 (b0l2de01), esp. slot 8. 
 
besides, the L1 interface board (long) input cables 
(on the top crate) are hanging without any support.  
that will eventually damage the connectors.  
for now, I used a cable tie to support the cables. this 
should be fixed (by Greg?).</pre>
<!-- Author: Ted -->


<!-- Date: Tue Mar 13 16:51:55 2001 -->
<pre>request from Steve Miller: 
 
 
I would like access to the DAQ system this  
Wed. evening and for parts of Thursday.  
Specifically I will need L1 Global, L1Cal and  
L2 decision. Last Wed. L2 was simply included  
in the regular integration tests during the night,  
with the effect that the alpha would  
stop the run on occasion.  
This arrangement seemed to work quite well  
for debugging the alpha. 
               Thanks, 
               Stephen 
 
</pre>
<!-- Author: Ted -->


<!-- Date: Tue Mar 13 18:20:39 2001 -->
It's really ironic that I was thinking a bit that Stefano's 
<a href="http://www.ts.infn.it/~belforte/svt/svtvme/svtvme_010313.html">talk</a> 
this morning was describing a solution in search of a problem,  
because I just inadvertently stopped Jane's L2 test twice in 
the past half hour, by running my little program to exercise the 
SVT coldstart code.  I would never have known, if she hadn't telephoned me.  Stefano was right!  
<!-- Author: Bill -->



<!-- Date: Wed Mar 14 00:02:43 2001 -->
<pre>The crate b0l2cl02 has been inoperational since about 7 pm tonight.  We 
get empty crate maps on VISIONdemo: 
 
    VISIONdemo-> 8 
To abort an operation, use a period (.) 
Experimental:  map crate using geo32 component; offset 0 
------------------------- 
geo32:/slot=1    |  (EMPTY) 
geo32:/slot=2    |  0xffffffff 
geo32:/slot=3    |  (EMPTY) 
geo32:/slot=4    |  (EMPTY) 
geo32:/slot=5    |  (EMPTY) 
geo32:/slot=6    |  (EMPTY) 
geo32:/slot=7    |  (EMPTY) 
geo32:/slot=8    |  (EMPTY) 
geo32:/slot=9    |  (EMPTY) 
geo32:/slot=10   |  (EMPTY) 
geo32:/slot=11   |  (EMPTY) 
geo32:/slot=12   |  (EMPTY) 
geo32:/slot=13   |  (EMPTY) 
geo32:/slot=14   |  (EMPTY) 
geo32:/slot=15   |  (EMPTY) 
geo32:/slot=16   |  (EMPTY) 
geo32:/slot=17   |  (EMPTY) 
geo32:/slot=18   |  (EMPTY) 
geo32:/slot=19   |  (EMPTY) 
geo32:/slot=20   |  (EMPTY) 
geo32:/slot=21   |  (EMPTY) 
------------------------- 
 
This doesn't change no matter what we do with power cycling the crate 
immediately, after waiting a few minutes, or after waiting a while longer. 
Upon Ted's suggestion, I also hot-plugged-in a DCAS board (slot 15), but   
that did not seem to solve the problem after rebooting the crate again. 
 
Mail has been sent to Monica and Steve (who last saw the crate 
alive).</pre>
<!-- Author: Nancy -->

<!-- Date: Wed Mar 14 06:30:07 2001 -->
<b>SVT crates</b> allocation for <b> Wed Mar 14  </b> <BR>
<cite>-- IMPORTANT Note: -- </cite>b0svt02/3/7 and TF 8-11 reserved for integration tests (Bill)<br>
<cite>--- </cite> Marco uses b0svt04/05 for intensive SPY_MON tests<br>
<!-- Author: Stefano -->
<!-- Comment: Thu Mar 15 14;06;49 comment by...Bill -->
Simone uses crate 7 for a while.  Jane plans to use it later
this afternoon.
<!-- Date: Wed Mar 14 16:03:06 2001 -->
I will probably be using parts of b0svt07 now and then for 
the next several hours.  I will try not to do anything that 
would interfere with using b0svt07 to drive data to L2, but 
if strange things happen in that crate, call x5017 to see 
if I am to blame.  If I can't work without stopping progress 
on L2, then I'll find another way to do what I need to do; 
just let me know.  (I'm also going to be using b0svt02, 3, and 
the corresponding Track Fitters in 6.)  
<!-- Author: Bill -->


<!-- Date: Wed Mar 14 21:07:18 2001 -->
<pre>Jane told me she wants to use L2 decision crate tomorrow (Thursday) morning to test XTRP to L2 interface.</pre>
<!-- Author: Ted -->

<!-- Date: Thu Mar 15 06:30:17 2001 -->
<b>SVT crates</b> allocation for <b> Thu Mar 15  </b> <BR>
<cite>-- IMPORTANT Note: -- </cite>b0svt02/3/7 and TF 8-11 reserved for integration tests (Bill)<br>
<cite>--- </cite> Marco uses b0svt04/05 for intensive SPY_MON tests<br>
<!-- Author: Stefano -->
<!-- Comment: Thu Mar 15 18;11;24 comment by...Jane -->
<pre>I am using b0svt07 for L2 integration tests.</pre>
<!-- Comment: Thu Mar 15 21;07;56 comment by...Jane -->
<pre>I am finished with b0svt07.</pre>
<!-- Date: Thu Mar 15 06:36:27 2001 -->
<pre>I spent whole night trying to find out what caused the "non-squentail events" problem for the entire DAQ system 
(this problem first occured a few weeks ago and is causing 
a lots of problem to the entire DAQ). based on what I learned, 
looks like it was due to glitches on the cdf_clk.  
for details(and scope pictures), see today's shift E-log. 
  
/cgi-bin/elog.pl</pre>
<!-- Author: Ted -->


<!-- Date: Thu Mar 15 10:15:50 2001 -->
<pre>I looked at the cause of Alpha hangs during running. 
First running with the L1 interface board, and would easily 
get Alpha hangs every few K events.  
Removing L1 interface board and putting in Clist or Isolist, the 
system seemed stable, but neither Clist or Isolist sent any data 
over the MBus.  
 
Previously I had looked at the MBus signals from the L1 interface 
board and saw that data and address were asserted at the same time as Dstrobe. That means the alpha could be latching the wrong address which might be causing the problems. 
 
It is unclear why the L1 interface board worked so well last Thursday- but it is interesting to note there were no alpha hangs  
when that was happening.</pre>
<!-- Author: Stephen Miller -->


<!-- Date: Thu Mar 15 12:07:30 2001 -->
<pre>I am taking b0l2de01 for XTRP tests.</pre>
<!-- Author: Jane -->
<!-- Comment: Thu Mar 15 13;28;04 comment by...Jane and Nathan -->
We tested the XTRP-Level 2 interface.  We took a run where we read out the data sent to the interface board in the SVTD bank, and can compare that to the XTRD bank.  Also tried to test the alpha interface, and data was sent from the interface board to the alpha and read out with the TL2D bank.  However, we found problems in the firmware (which hasn't been tested with XTRP before) so the correct data was not being sent.  
<!-- Date: Thu Mar 15 13:11:46 2001 -->
<pre>B0SVT00, TF0/1 for Integration until midnight</pre>
<!-- Author: Un-ki -->





<!-- Date: Thu Mar 15 18:12:56 2001 -->
I am taking b0l2de01 (and b0svt07) for SVT/L2 integration tests.  Bill A. changed the oscillator chip in the merger so the data rate going into my board is slower.  I'd like to see if this makes a difference in the problems with the clock lines that I observed the other night.
<!-- Author: Jane -->
<!-- Comment: Thu Mar 15 20;52;21 comment by...Jane -->
<pre>Finished with the crates.</pre>
<!-- Date: Thu Mar 15 20:42:16 2001 -->
Merger did not like slower oscillator.  I think Anna Maria 
or Stefano told me this last fall, so it's not a surprise. 
Instead, we changed .../svt_config/hf_xtrpfake.HF-OSPY to contain Track Fitter 
input format, instead of Track Fitter output format, then 
ran the output of the Merger that had been feeding Jane into 
a spare Track Fitter (now in crate 7 slot 10), into which I 
installed a 4 MHz oscillator, and let the TF feed Jane.  When data were strobed too 
quickly into the L2/track board, its on-board FIFO write clock 
(for the FIFO that feeds the Magic bus transfers) developed a 
sag, whose shape followed the envelope of the packet of hits, 
not the individual hit strobes.  Slowing down the data coming 
into the board made this internal clock signal look much better 
on a scope.  (This is my fuzzy interpretation of what I learned 
by looking over Jane's shoulder.)  The goal here is to get SVT 
data into the L2 processor; the SVTD readout has worked reliably 
for months.
<!-- Author: Bill -->




<!-- Date: Thu Mar 15 22:41:30 2001 -->
We are running test data through wedges 0, 1, 2, 3 (Merger to AMS to HB to TF), both boards and simulation in parallel.  We changed the 
wedge 3 AMS phi sector from 5 to 3 and enabled the HOLD signal 
on the wedge 3 HB.  (The HBs in wedges 0 and 1 still need their 
HOLDs enabled; not done yet.)  We found that data did not flow 
in wedge 3, and traced it to the fact that the AMS output HOLD 
light is on even if the HB road HOLD light is off.  We tried 
replacing the cable, no dice.  So we decided to try swapping 
the AMS: it worked. 
<p> 
We removed AMS 15 from crate 1 slot 17, replaced it with AMS 13 
(in spare cabinet), and moved AMS 15 to the test stand.  The 
output HOLD of AMS 15 should be checked.  We were unable to try 
anything in the test stand, because the power supply has a "do 
not turn on" tag, signed by Fred Lewis. 
  
<!-- Author: Un-ki and Bill -->
<!-- Comment: Fri Mar 16 13;20;22 comment by...Bill -->
Note that the AMS was in Run mode, not Test mode, when 
this Hold condition was observed.
<!-- Date: Fri Mar 16 06:30:35 2001 -->
<b>SVT crates</b> allocation for <b> Fri Mar 16  </b> <BR>
<cite>-- IMPORTANT Note: -- </cite>b0svt02/3/7 and TF 8-11 reserved for integration tests (Bill)<br>
<cite>--- </cite> Marco uses b0svt04/05 for intensive SPY_MON tests<br>
<!-- Author: Stefano -->



<!-- Date: Fri Mar 16 13:18:43 2001 -->
Jane would like us to leave the data path feeding L2 from 
crate 7 (including spare TF with 4.0 MHz osc) in place until 
Sunday morning.
<!-- Author: Bill -->


<!-- Date: Sat Mar 17 06:30:25 2001 -->
<b>SVT crates</b> allocation for <b> Sat Mar 17  </b> <BR>
<cite>-- IMPORTANT Note: -- </cite>b0svt02/3/7 and TF 8-11 reserved for integration tests (Bill)<br>
<cite>--- </cite> Marco uses b0svt04/05 for intensive SPY_MON tests<br>
<!-- Author: Stefano -->



<!-- Date: Sun Mar 18 05:16:43 2001 -->
Integration test with B0svt00/1
<!-- Author: Un-ki -->

<!-- Date: Sun Mar 18 06:30:38 2001 -->
<b>SVT crates</b> allocation for <b> Sun Mar 18  </b> <BR>
<cite>-- IMPORTANT Note: -- </cite>b0svt02/3/7 and TF 8-11 reserved for integration tests (Bill)<br>
<cite>--- </cite> Marco uses b0svt04/05 for intensive SPY_MON tests<br>
<!-- Author: Stefano -->
<!-- Comment: Sun Mar 18 08;45;44 comment by...Jane -->
<pre>I will use b0svt07 this morning.</pre>


<!-- Comment: Sun Mar 18 14;37;35 comment by...Jane -->
I am finished with b0svt07 and am leaving Fermilab later this afternoon so it can be put back in it's former state.
<!-- Date: Sun Mar 18 08:46:20 2001 -->
<pre>I would like to do SVT-L2 tests this morning using b0l2de01 and b0svt07.</pre>
<!-- Author: Jane -->
<!-- Comment: Sun Mar 18 14;56;21 comment by...Jane -->
I am finished with b0l2de01 and b0svt07.  I found a problem with the data input that Bill set up for me from b0svt07 in that the timing on the SVT/L2 interface board assumes a pulse width of 15ns (less than 50ns anyway) and due to the different oscillator, the DS signal was much wider.  The consequence was that the data which would be sent to the Level 2 processors would not be correct.  Nevertheless, because of the improved clock signal due to the slower input rate I was able to send data to the Level 2 processors and try to find the cause of the Level 2 transfers stopping. I 
located a problem in the state machine that controls sending data to the Level 2 processors.  I hope to fix this problem before the next time I am at Fermilab and will test it then, since I have to leave now.   

The next time I will be at Fermilab will be March 25-27th.  I'd like to request a Level 2 decision crate for March 25 (afternoon-evening), March 26(afternoon), and March 27(anytime).  I'd also like to use b0svt07, except for time which I can arrange with Nathan to work on the XTRP tests.  

<!-- Comment: Sun Mar 18 20;25;49 comment by...Bill -->
Note that if this problem arises again (needing words to come
slowly, but without wide data strobe pulses), we can stick a
Merger board between the Track Fitter and the SVT/Track board;
it will send words out as they come in (i.e. slowly) but with
a narrow (~15 nsec) strobe.



<!-- Date: Sun Mar 18 20:26:58 2001 -->
Franco plans to use crates 0, 1, and 2 Monday morning.  
<!-- Author: Bill -->

<!-- Date: Mon Mar 19 06:30:32 2001 -->
<b>SVT crates</b> allocation for <b> Mon Mar 19  </b> <BR>
<cite>-- IMPORTANT Note: -- </cite>b0svt02/3/7 and TF 8-11 reserved for integration tests (Bill)<br>
<cite>--- </cite> Marco uses b0svt04/05 for intensive SPY_MON tests<br>
<!-- Author: Stefano -->



<!-- Date: Mon Mar 19 10:13:42 2001 -->
<pre>email from Steve Kuhlmann: 
 
        I put back the temporary fiber from IsoClique to Isolist 
so it can take cosmics again.  We really need cosmic data to 
make progress now. 
 
--  
        Steve 
 
</pre>
<!-- Author: Ted -->

<!-- Date: Tue Mar 20 06:30:43 2001 -->
<b>SVT crates</b> allocation for <b> Tue Mar 20  </b> <BR>
<cite>-- IMPORTANT Note: -- </cite>b0svt02/3/7 and TF 8-11 reserved for integration tests (Bill)<br>
<cite>--- </cite> Marco uses b0svt04/05 for intensive SPY_MON tests<br>
<!-- Author: Stefano -->
<!-- Comment: Mon Mar 26 13;29;35 comment by...Stefano -->
Jane has b0svt07 all afternoon.
<!-- Date: Tue Mar 20 13:49:25 2001 -->
<pre>Testing the L1 interface board, we found a slot dependence in  
the behaviour. For slots 10 and 11, the board will send 0, 1 or 
2 MBus words per event and the data is wrong. For slot 14, it 
worked perfectly (always sending 1 MBus word and the fred data 
agreeing.) In slot 15 the first 100 events were okay, then it 
sent 2 MBus words for 1 event and then 0 words after that. 
This slot dependence shows up for both the old and new proms. 
The problem in slot 15 is possibly a separate problem from the  
simple slot dependence.</pre>
<!-- Author: Stephen Miller -->

<!-- Date: Wed Mar 21 06:31:06 2001 -->
<b>SVT crates</b> allocation for <b> Wed Mar 21  </b> <BR>
<cite>-- IMPORTANT Note: -- </cite>b0svt02/3/7 and TF 8-11 reserved for integration tests (Bill)<br>
<cite>--- </cite> Marco uses b0svt04/05 for intensive SPY_MON tests<br>
<!-- Author: Stefano -->



<!-- Date: Thu Mar 22 00:47:37 2001 -->
<pre>I committed some significant svtvme cold-start changes to CVS, 
but I haven't yet reloaded the crates, except 2 and 6. 
</pre>
<!-- Author: Bill -->

<!-- Date: Thu Mar 22 06:30:47 2001 -->
<b>SVT crates</b> allocation for <b> Thu Mar 22  </b> <BR>
<cite>-- IMPORTANT Note: -- </cite>b0svt02/3/7 and TF 8-11 reserved for integration tests (Bill)<br>
<cite>--- </cite> Marco uses b0svt04/05 for intensive SPY_MON tests<br>
<!-- Author: Stefano -->
<!-- Comment: Thu Mar 22 07;38;42 comment by...Un-ki -->
B0svt00 and TF0 for TF test (un-ki) 


<!-- Date: Thu Mar 22 14:21:02 2001 -->
<pre>Oops!!  I just used wedges 8 and 9 when I meant to use 
wedge 4 and 5.  Sorry, Marco!</pre>
<!-- Author: Bill -->
<!-- Comment: Thu Mar 22 15;00;18 comment by...Bill -->
<pre>As if that weren't bad enough, I then ran the cold start
with b0svt06's default bank set, which contains the TFs
for wedges 0-7, thereby disrupting Un-ki's test.  :(
But I think it's still running.</pre>

<!-- Comment: Thu Mar 22 20;12;53 comment by...Yanwen -->
<pre>I'd like to use b0svt04 tomorrow morning to test my codes of loading MS RAM
                      </pre>

<!-- Date: Fri Mar 23 06:33:00 2001 -->
<b>SVT crates</b> allocation for <b> Fri Mar 23  </b> <BR>
<cite>-- IMPORTANT Note: -- </cite>b0svt02/3/7 and TF 8-11 reserved for integration tests (Bill)<br>
<cite>--- </cite> Marco uses b0svt04/05 for intensive SPY_MON tests<br>
<!-- Author: Stefano -->


<!-- Date: Fri Mar 23 06:33:00 2001 -->
<b>SVT crates</b> allocation for <b> Fri Mar 23  </b> <BR>
<cite>-- IMPORTANT Note: -- </cite>b0svt02/3/7 and TF 8-11 reserved for integration tests (Bill)<br>
<cite>--- </cite> Marco uses b0svt04/05 for intensive SPY_MON tests<br>
<!-- Author: Stefano -->



<!-- Date: Fri Mar 23 08:11:55 2001 -->
<pre>Then, I am going to play with svt06 this morning... 
if no objections...  </pre>
<!-- Author: Yanwen -->
<!-- Comment: Fri Mar 23 08;59;56 comment by...Yanwen -->
<pre>*b0svt00* instead.. </pre>


<!-- Date: Fri Mar 23 12:35:13 2001 -->
<pre>Fred: 
 
  I just looked at the P3 backplane on B0L2de00,  
there is a bent pin on slot 14,  
VERY bad (this pin is almost damaged).  
almost shorted to the pin on the side.  
 
  I have no idea when this occured. anyone know? 
 
  Ted</pre>
<!-- Author: Ted -->
<!-- Comment: Fri Mar 23 12;44;22 comment by...Ted -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>next time if anyone finds any bent pin, you should post 
on E-log. otherwise, someone else may plug a board in there!
this must have happened in the past few days. DO NOT plug
any board in this slot! (esp. L1 Interface board, it will
short the pins for sure!)</pre></td></tr></td></table>


<!-- Date: Fri Mar 23 13:07:32 2001 -->
<pre>trying to setup things to test L1 Interface board +  
CLIST + ISOList boards. will take a whole system ( 
asked ACEs to run the system with L2 in). 
 
plugged in CLIST and Iso List, L1 interface  
already in there. add one jumper in slot 14. 
 
waiting for ACEs to coldstart...</pre>
<!-- Author: Ted -->
<!-- Comment: Fri Mar 23 13;18;48 comment by...Ted -->
<pre>coldstart finally finished. activated, before the
first event, B0l2de00 timeout, Vision read failed
in slot 3 (alpha slot).

asked ACEs to give another try, with only one L3
subfarm, so I don't have to wait for ages.</pre>

<!-- Comment: Fri Mar 23 13;20;12 comment by...Ted -->
<pre>this is the usal error message:

Error: Alpha in slot 3 is no longer processing at spot 92275480: (null)
</pre>

<!-- Comment: Fri Mar 23 13;46;48 comment by...Ted -->
<pre>tried software evb, didn't want to deal with L3.

start another run, after ~200 events, got:

Error: Alpha in slot 3 is no longer processing at spot -310444032: (null)


run number: 109944. 

looking at LA signals on CLIST, the magicbus handshake
was ok for a few seconds, and Iso-list lights flashed for 
a few seconds. then Cluster hangs... then alpha dies...</pre>


<!-- Date: Fri Mar 23 13:58:17 2001 -->
<pre>try again, from coldstart (note: CCAL+PCAL+WCAL+L1CAL+L2CAL 
+L2de + L1GL are in the partition). this time watched 
the LA right after we started. looks like the CLIST 
magicbus communication only works for the 1st event, 
then lost. but IsoList sel lights flashed all the time 
until CLuster hangs. so at least Steve Kuhlmann will have 
some data... a few hundreas of events. 
run number 109945. 
trigger table: Sumet_2[2,91]. with software evb. 
 
L3 people wants to test their stuff, so I will gave up 
now. but at least we will have some data for Steve Kulhmann, 
he has been waiting for this data for weeks now. hope 
this run helps. 
 
didn't get time to look at the MOD_DONE bits on the backplane. 
still upset with the unreported bent pins... so better not 
look at the backplane now. 
 
will ask ACE to start another run with exact same setting.</pre>
<!-- Author: Ted -->
<!-- Comment: Fri Mar 23 14;08;09 comment by...Ted -->
<pre>started another run, 109946. but this time IsoList
sel light is not flashing, even though CLustering is
going. CLIST lost communication with magic bus right
away as usual.

ask Steve Kuhlmann, he asked me to unplug the CLSIT and
try another run. this time Isolist sel light is flashing,
after a while, then CLUSTER hangs.
for now will leave IsoList in as it works. will need to confirm
this offline.</pre>

<!-- Comment: Fri Mar 23 16;48;34 comment by...Ted -->
<pre>oops, I had a jumper in slot 14 when I had CLIST in slot 14.
that was wrong. this may explain why CLIST magic bus
communication wasn't there... we should do this test again
soon. but this shouldn't affect IsoList data. Thanks 
Steve Miller who read my previous entries carefully
and found that I did put a jumper there....</pre>


<!-- Comment: Fri Mar 23 17;20;14 comment by...Ted -->
<pre>just went to the backplane and checked the jumpers in
the back. turns out there has been a jumper in slot 13
as well. don't know why that one was there in the first 
place as this slot is for IsoList. but the thing is 
I didn't check this before i started the run, since
I was so upset with the bent pin in the backplane at
that time...

but then Steve Kulhmann told me he got his data in TL2D
bank, and the sel light were flashing when we took data.
don't quite understand this. with the jumper in, interface
board shouldn't be able to become the bus master...

in any case, we should do this test again soon.</pre>
<!-- Comment: Fri Mar 23 17;21;24 comment by...Ted -->
<pre>by the way, I just removed the jumper in slot 13.
and IsoList is still plugged in slot 13. so when
ACEs include L2 in the run, SteveK should be able
to get more data.</pre>
<!-- Date: Fri Mar 23 16:58:22 2001 -->
<pre>Summary of work on the L1 interface board in the last 10 days. 
 
There were 2 major problems observed with the L1 interface board. 
1. Multiple dstrobes were sent when only one should ever be sent. 
2. The address and data lines were sent at the same time as dstrobe, 
instead of 10ns earlier. 
 
See http://umaxp1.physics.lsa.umich.edu/~miller/l1interface_dstrobe.gif 
for an example of these problems. 
 
The reason for problem #1, was that the boss was multiply asserted 
(either due to reflections or ??), as was bossreq.  If bossreq is 
asserted while boss is asserted, the arbitration circuit is such that 
boss will be deasserted. Similarly, if boss is deasserted, while 
local_req is still pending, then bossreq will be asserted causing boss 
to be asserted again. Since localboss is used as the OE for the 
buffers driving dstrobe and the address and data lines, the multiple 
assertions of boss would cause dstrobe and address and data lines to 
toggle on and off. 
 
See http://umaxp1.physics.lsa.umich.edu/~miller/l1interface_boss2.gif 
for an example of this behavior. 
 
The Clist and Isolist board have identical MBus arbitration circuits, 
but do not exhibit this behavior on boss. 
 
The L1 interface board would work well sending data in high slots such 
as 14 or 15, but would not work well in slots 10 or 11. 
 
We tested a new L1 interface board, and it showed the same behaviour. 
Bill Haberichter made 2 changes to the new L1 interface board. He 
added a chip to the arbitration circuit so that having a second 
bossreq would not turn off boss. He also added a delay line chip so 
that dstrobe would come after the data and address had been asserted. 
 
See http://umaxp1.physics.lsa.umich.edu/~miller/l1interface_bossfix10.gif 
for an example of the lines on a  fixed board. 
 
This new board consistently sends just 1 MBus word for each event. 
 
 
There are 2 remaining problems observed with data from the L1 interface 
board. 
 
1. Looking at the data, the data is wrong about 20% of the time. The 
wrong data does match previous data sent, and only seems to happen for 
buffer numbers 0 and 1. 
 
2. There is also the problem of the SumEy data from Prefred having its 
bit ordering flipped. (For the short term we can apply a software fix). 
 
</pre>
<!-- Author: Stephen Miller -->


<!-- Date: Fri Mar 23 17:03:05 2001 -->
<pre>On Wed. night, we had a run with the calorimeter trigger (Run# 
109827) and L1 interface, Clist and Isolist in the crate. 
Looking on the backplane, I saw that MOD_DONE was not being  
driven high for L1 interface and Isolist, although it worked 
fine for Clist. 
 
 
(DONE_OUT on each board is mapped to the MOD_DONE(18:0), 
depending on the slot number, where slot 3 is connectd to 
MOD_DONE(0). MOD_DONE should go high when all the data has been 
sent for that event, and should go low once START_LOAD is 
deasserted.) 
 
 
On Thursday, with just L1 interface in the crate, the MOD_DONE 
line was being properly asserted by the L1 interface board. 
Perhaps there is a problem when more than 1 interface board is 
in the crate. e.g.DDONE from another board's transaction is used. 
 
I haven't looked at MOD_DONE when just Isolist is in the crate. 
 
</pre>
<!-- Author: Stephen Miller -->



<!-- Date: Sat Mar 24 06:31:06 2001 -->
<b>SVT crates</b> allocation for <b> Sat Mar 24  </b> <BR>
<cite>-- IMPORTANT Note: -- </cite>b0svt02/3/7 and TF 8-11 reserved for integration tests (Bill)<br>
<cite>--- </cite> Marco uses b0svt04/05 for intensive SPY_MON tests<br>
<!-- Author: Stefano -->


<!-- Date: Sun Mar 25 06:31:44 2001 -->
<b>SVT crates</b> allocation for <b> Sun Mar 25  </b> <BR>
<cite>-- IMPORTANT Note: -- </cite>b0svt02/3/7 and TF 8-11 reserved for integration tests (Bill)<br>
<cite>--- </cite> Marco uses b0svt04/05 for intensive SPY_MON tests<br>
<!-- Author: Stefano -->
<!-- Comment: Sun Mar 25 20;47;32 comment by...Bill -->
<pre>Bill takes whole SVT to test coldstart.  I'm at x5017, if
you want something back, and if I forget to follow up on
this message, it expires at midnight.
</pre>

<!-- Comment: Mon Mar 26 00;54;53 comment by...bill -->
<pre>OK, I'm done.</pre>


<!-- Date: Mon Mar 26 01:03:17 2001 -->
<pre>SVT coldstart now initializes from one "mapset" and one "hwset" 
file.  By default, each one is called "default".  You can use 
your own by typing e.g. "hw=marco map=polo" as svtMode in R_C. 
I think the "hwset" file is a more compact way to maintain the 
various register settings we have been using. 
<p> 
The *.patt, *.ss, and *.ifit files are also used by coldstart, 
as specified in *.mapset. 
<p> 
I tried to do a "whole SVT" test, with data flowing in sync with 
the L1 trigger.  The idea is to have the "XTRP emulator" and the 
final Merger as the two inputs to a "post-final" merger, so the 
entire SVT pipeline would be held until each L1A, with the data 
coming internally from HF spy buffers.  This worked for all 
boards up through Hit Buffers, but the Track Fitters still do 
not seem to obey the Hold signal, even in Run mode, and even 
when the cable is unplugged from the output.  I thought this had 
been cured by a recent firmware update. 
<p> 
Anyway, it is now possible to book all 8 crates and do a  
cold start, and have some initialization take place, most of 
which is sensible.  The Hit Finder cold start still needs some 
work. 
</pre>
<!-- Author: Bill -->
<!-- Comment: Mon Mar 26 01;04;05 comment by...Bill -->
<pre>Also, I still have some memory leaks, so you may need to
reboot after running cold start many times.  I will fix
this ASAP.
</pre>

<!-- Comment: Mon Mar 26 01;05;37 comment by...Bill -->
<pre>Also, I disabled the SVTY readout from crate 0, since
it was making those boards incapable of their normal
function, and I enabled the output hold on Hit Buffers
0, 1, 8, 9, 10, 11 (i.e. all that didn't have it).
</pre>

<!-- Date: Mon Mar 26 06:30:43 2001 -->
<b>SVT crates</b> allocation for <b> Mon Mar 26  </b> <BR>
<cite>-- IMPORTANT Note: -- </cite>b0svt02/3/7 and TF 8-11 reserved for integration tests (Bill)<br>
<cite>--- </cite> Marco uses b0svt04/05 for intensive SPY_MON tests<br>
<!-- Author: Stefano -->




<!-- Date: Mon Mar 26 13:34:32 2001 -->
 <b>SVT crates</b> allocation for <b> Mon Mar 26  </b> <BR> 
<cite>-- IMPORTANT Note: -- </cite>b0svt02/3/7 and TF 8-11 reserved for integration tests (Bill)<br> 
<cite>--- </cite> Marco uses b0svt04/05 for intensive SPY_MON tests<br>
<!-- Author: Stefano -->
<!-- Comment: Mon Mar 26 13;35;07 comment by...Stefano -->
Jane has b0dvt07 all day

<!-- Comment: Mon Mar 26 14;22;21 comment by...Stefano -->
Ynawen Liu is using b0svt00 to test AMS code

<!-- Comment: Mon Mar 26 15;22;02 comment by...Stefano & Jane -->
Alos uisng final merger in slot 19 of b0svt06


<!-- Comment: Mon Mar 26 18;49;18 comment by...Sterfano -->
using b0svt01 for software developmetn until further notice.
<!-- Date: Mon Mar 26 15:47:40 2001 -->
Jane and myslef resurrectd the SVT->Level 2 data flow 
using TRP emulator and fake HB data from one L00 HF. Data 
are loaded from jane.hfospy file and pass through spare 
TF in b0svt07/10 at 4 MHz. The final merger in b0svt06/19 
is used to reshape the DS strobe. 
<b> I modifed final merger switched: enable only input D and 
hold on out 1</b>. 
This swith configuration in jane.hwset config file. Now 
using default.hwset on b0svt06 willk give error. 
I suggest we keep hardware stable and everybody using R_C on crate b0svt06 correct the hwset file to work with current 
switch settings for the rest of the week. So Jane test can 
be run at any time.  
<!-- Author: Stefano -->


<!-- Date: Mon Mar 26 15:57:18 2001 -->
<pre>Bob and I investigated Iso questions.  We took data  
successfully with the Alpha,  seeing no evidence of  
dropped seeds.   But in the summed data itself,  
there was evidence that the first tower was dropped. 
In addition,  racks 25 and 26 had lousy looking signals,  but 
no evidence that data was lost.  Maybe bad termination? 
The most significant problem seen in integration data  
was missing pass=1 and 2,  we could find no reason for 
this and our data worked for all 4 passes.  We need to  
take cosmic triggers and look at Clique signals on the  
backplane.</pre>
<!-- Author: Steve Kuhlmann -->



<!-- Date: Mon Mar 26 19:52:06 2001 -->
<pre>I am finished with SVT/L2 tests for now.  I had many problems with the alphas.   
I tried to use the alpha in b0l2de01, but was never able to get it to work --  
it gave a DONE TIMEOUT on the first event with this error: 
 
===> transfer size too big (TL2D) = -1/1050 
count = 950 alignedBuff = 0xffffffff 0xffffffff 0xffffffff 0xffffffff 
TRIG_readOutFormat(): alignedBuff too small, req 13118424 words, max 1050 
words 
TRACER_enableDone: Front End Fatal Error (-1): Tracer done not set 
Internal buffer too small 
Internal buffer too small 
 
 
Then I moved to b0l2de00, and it took several attempts to get it  
to work.   
Twice the vme processor hung while I was trying to get through partition.   
I also had the same errors as above, and even once it was working 
 I got DONE TIMEOUT's every once in a while, with the usual message: 
 
Alpha in slot 3 is no longer processing at spot 50331648: 
 
Eventually I was able to test my board, but I found what seems 
 like a hardware problem with it, that definitely was not there  
a week ago, the last time I was here.  I need to investigate 
 further, but the alphas are not required until I fix 
 this problem. </pre>
<!-- Author: Jane -->
<!-- Comment: Mon Mar 26 20;59;56 comment by...Stephen Miller -->
<pre>t's hard to say for sure what happened. Were you using L2
processors to make the L2 decision or was it Auto L2A? Also, if 
the time between clicking coldstart and activate was really 
short, then the problem could be that the alpha was still being 
rebooted (by coldstart) when activate occurred. If you had Auto 
L2Accept, then the crate controller would have  tried to readout 
the alpha while it was still being rebooted. If the run
control setting was L2 processors then I'm puzzled as to this 
error.
</pre>
<!-- Comment: Tue Mar 27 16;52;34 comment by...Jane -->
I was using L2 processors to make the L2 decision, and by logging into the processor with minicom I could see that it had booted before I hit activate.
<!-- Date: Mon Mar 26 20:46:43 2001 -->
Will be playing around with TF in slot 6 of b0svt06 for a few minutes.
<!-- Author: Stefano -->
<!-- Comment: Mon Mar 26 22;04;01 comment by...Stefano -->
I am done. That TF may need to be properly reinit though. I still did nto learn how to do it.

<!-- Date: Tue Mar 27 06:31:40 2001 -->
<b>SVT crates</b> allocation for <b> Tue Mar 27  </b> <BR>
<cite>-- IMPORTANT Note: -- </cite>b0svt02/3/7 and TF 8-11 reserved for integration tests (Bill)<br>
<cite>--- </cite> Marco uses b0svt04/05 for intensive SPY_MON tests<br>
<!-- Author: Stefano -->
<!-- Comment: Tue Mar 27 20;05;12 comment by...Jane -->
<pre>I am using crates 6 and 7.</pre>
<!-- Date: Tue Mar 27 12:57:04 2001 -->
After the discussion in this morning's SVT meeting, we decided 
to carry out Luciano's wish to have SVT operate as a whole 
system.  We installed the final cables to/from the 12 wedges. 
We completely rearranged crate 7, as follows: 
<p> 
<ul> 
<li>slot 3 - Spy Control 
<li>slot 4 - unused L00 HF 
<li>slot 5 - unused L00 HF 
<li>slot 6 - HF whose OSPY provides fake XTRP data 
<li>slot 7 - empty 
<li>slot 8 - XTRP emulator (modified Hit Finder) 
<li>slot 9 - empty 
<li>slot 10 - Merger for fake XTRP data (combines 8 and 6) 
<li>slot 11 - TF with 4MHz oscillator, for Jane 
<li>slot 12 - HB for Nathan (XTRP data sink) 
<li>slot 13 - unused L00 HF 
<li>slot 14 - unused L00 HF 
<li>slot 15 - unused L00 HF 
<li>slot 16 - empty 
<li>slot 17 - XTFA 
<li>slot 18 - XTFB (wedges 0-5) 
<li>slot 19 - XTFB (wedges 11-6) 
<li>slot 20 - empty 
<li>slot 21 - empty 
</ul> 
<p> 
The output of Jane's TF feeds input D of the final Merger, 
in crate 6 slot 19; this is to reshape DS pulse.  (It also 
will allow us later this week to select via VME commands whether Jane sees 
the whole SVT's output or the test setup's output.) 
<p> 
The first output of the XTRPemu's Merger feeds Jane's TF; 
the second output feeds XTFA.  We should eventually be 
able to use a Merger to switch between the real and fake 
XTRP data, without switching cables. 
<p> 
We also enabled all inputs on all wedges' Mergers. 
<p> 
We are now deciding whether to cable the Spy Control 
daisy chain in its final configuration; we're leaning toward 
the affirmative.  (A given SC can always be configured via  
VME to ignore the global signals.) 
  
<!-- Author: Bill, Stefano, and Simone -->
<!-- Comment: Tue Mar 27 13;03;39 comment by...Bill -->
We can't find the Spy Control cables, so we will postpone
that job.  There are a few unlabeled cables around that could partially
do the job, but they are much too long.  Stefano is hoping
that cables made to length and labeled are hiding in some
location that will be revealed when Franco returns.


<!-- Date: Tue Mar 27 14:16:16 2001 -->

I will be playing with b0svt00 and TF in slots 4/5 in the next hours.
I am going to reboot b0svt00 as needed.
I will likely need to mess with b0svt06 (TF crate) CPU as well, please
let me know if this is a problem.


<!-- Author: Stefano -->




<!-- Date: Tue Mar 27 19:24:39 2001 -->
XTFA/B are now installed, and we have initialized XTFA by hand. 
We ran the cold start for the rest of SVT, using SVT as its 
own data source for now.  For the first time ever, data are 
flowing through all of SVT, together, in synchrony with the 
Level 1 accept signal.  Fun!  
<!-- Author: Bill, Stefano, Simone -->


<!-- Date: Tue Mar 27 19:26:56 2001 -->
While shuffling boards around this morning, we broke Bill's 
little kludge that allows a full-size oscillator (4 MHz) to be 
plugged into a half-size slot, for Jane's TF.  Thus, when we 
first tried to send Jane data this afternoon, no data flowed 
through the TF.  We fixed the oscillator (after many false 
starts, because we still lack good diagnostic tools), and 
data began to flow. 
<p>  
<!-- Author: Bill, Stefano -->


<!-- Date: Tue Mar 27 19:57:50 2001 -->
I no longer need to have any crates reserved for my own 
use, but when I want now and then to exercise updates to  
the cold 
start code, I will use crate 2 (wedges 4 and 5).  I'll 
use the logbook, like everyone else, to indicate when I 
am using something and for how long.  
<!-- Author: Bill -->


<!-- Date: Tue Mar 27 20:03:36 2001 -->
I will be talking with crate 2 and TF 4 occasionally, 
between now and midnight.
<!-- Author: Bill -->



<!-- Date: Tue Mar 27 22:05:42 2001 -->
I am currently playing around with whole-SVT coldstart, but 
I won't keep any resource allocated past bedtime.  
<!-- Author: Bill -->


<!-- Date: Tue Mar 27 22:37:22 2001 -->
If you use runset "SVTWJA", you get all of SVT, data flowing 
through everything, and a whole bunch of lights blinking.  I 
don't think the data are at all interesting yet, though.  
<!-- Author: Bill -->


<!-- Date: Tue Mar 27 22:56:00 2001 -->
I rebooted all eight SVT crates, to load updated svtvme  
library, which includes a primitive XTFA coldstart.  It 
sets registers, but not yet maps.  It is invoked via a 
kludge in the Spy Control coldstart, because my attempt 
to recompile fer today failed, so it wasn't possible to 
add XTFA properly. 
<p>
<!-- Author: Bill -->


<!-- Date: Wed Mar 28 00:04:09 2001 -->
I forgot to note that I plugged in the spy cables, and 
set the switches so that the fanout crate is the master, 
the chain goes counter-clockwise, and the fitter crate 
is the last, as Stefano suggested.  
<!-- Author: Bill -->

<!-- Date: Wed Mar 28 06:54:17 2001 -->
<b>SVT crates</b> allocation for <b> Wed Mar 28  </b> <BR>
<cite>-- IMPORTANT Note: -- </cite>b0svt02/3/7 and TF 8-11 reserved for integration tests (Bill)<br>
<cite>--- </cite> Marco uses b0svt04/05 for intensive SPY_MON tests<br>
<!-- Author: Stefano -->
<!-- Comment: Wed Mar 28 11;52;52 comment by...Bill -->
I'll take TF #4 for a while.  I'm at x5017.


<!-- Comment: Thu Mar 29 18;09;13 comment by...Jane -->
<pre>I had svt06 and svt07 for the past hour, sorry I forgot to make an entry.  I'm finished now.</pre>
<!-- Date: Wed Mar 28 22:22:23 2001 -->
We are sending data, about 6 tracks / event, through all of 
SVT, and into Jane's board.  We are now trying to figure out 
how to read the output .....  
<!-- Author: Bill and Stefano -->
<!-- Comment: Wed Mar 28 23;22;29 comment by...Bill and Stefano -->
We are still running, run 110430, 40K events so far (at only
about 10Hz), and we have checked that SVTD contains the
expected track data (6 tracks/event) offline.  We have not
checked the whole file; that will be an intersting exercise.
Also, we are sending the same 500 events over and over, so
we should see that in the output; would be interesting to 
see that the structure is preserved.  We leave it running
overnight; kill it if you wish.
<p>
By the way, we devised an ingenious way to get L1A into all
of the Hit Finders, but the explanation is too long to fit
in the margin of this notebook entry....



<!-- Comment: Thu Mar 29 10;30;55 comment by...Stefano -->
The run ended somehow disastrously at 9:30 this morning
<pre>
2001.03.29 09:34:10 Run requested 10000000 events
2001.03.29 09:34:11 Automatically ending run with estimated  336859119 events
2001.03.29 09:34:12 RAP.superReset() called
2001.03.29 09:34:12 Database connection stale, must reopen
</pre>
after which all the crate controllers rebooted.
The collected number events 336 M vs 10M requested is odd because the trigger rate was a bit less then 10 Hz that makes for <1M events in one day, not 336 M in 11 hours...
<!-- Date: Thu Mar 29 01:00:24 2001 -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>In the ongoing effort to solve cluster hanging problem, today I tried two thing: 
1) change buffer energy latching in DCAS FPGA to make it less susceptible to transients in buffer bit decoding logic 
2) change the timing of some clustering protocol signals, generated by FPGA on CLIQUE, so to allow more time for latching of buffer bits + threshold bits + energy-thresholds comaprison results. 
 
First change (downloading VRS3_29_26_NO_HOLD to b0l2cl03/04/05 and VRS3_29_26_NEW_COMP TO B0L2CL00/01/02) has very little effect on hanging rate, if any. Any improvement is wiped out by changing the TAP_IN delay in LOCOS from 80 nsec back to 60 nsec. 
 
But second change (using PROM with clique_032701.mcs bit file) does the trick! Now I can run with no hanging even at rates close to 500Hz (using INTEGRATION_CABLE_1 and no SEVB!).  
 
Offline analysis of sone runs taken with CCAL (namely run 110336 with INTEGRATION_CAL_1 and 110339+110341 with INTEGRATION_DIJET_1) show zero or very few errors in over 1000 clusters produced. All the errors are confined to tower (phi,eta)=(23,13) which the hardware sees as an independent seed while it should be part of a cluster starting at (phi,eta)=(0,13)! 
 
I tried hard to produce a cluster hanging for the whole evening but without success! Hippeee! 
 
I took other runs with INTEGRATION_SUMET_2 (which yields a rate of ~230 Hz w/o SEVB and 3-4 Hz w/SEVB) using 
run 101434: CCAL + PCAL (except PCAL_01) + HCAL 
run 101435: same as above + b0l2de00. 
 
For this last run, both L1_INTERFACE board (slot 10) and CLIST (slot 14) are in the crate. I issued numerous HRR's but CLIST behaviour has a clear pattern: clusters are sent to L2 processor on first event, then CLIST "chokes". It always looks like CLIST get very confised (producing multiple LOC_BOSS signals) at the second STARTLOAD (monitored with MB_DONE_OUT on CLIST).</pre></td></tr></td></table>
<!-- Author: monica -->



<!-- Date: Thu Mar 29 10:37:29 2001 -->
Tried to restart the SVT run. Get error in reading patterns from AM board #1 wedge 0, crate b0svt00 slot 10.
<!-- Author: Stefano -->
<!-- Comment: Thu Mar 29 10;42;33 comment by...Stefano -->
Also b0svt2 rebooted by itself after cold_start

<!-- Comment: Thu Mar 29 11;30;39 comment by...Stefano -->
<pre>The Amboard error is intermittent.
Try to restart R_C anyhow.
Get plagued by a lot of fer failures:

<pre>
data access
Exception current instructino address: 0x002362f4
Data Access Register: 0x72901b5
....
Task: 0xe84738 "Messenger"
</pre>
after which crate does not answer R_C messages anymore until rebooted. Will try later in case is some fer problem.</pre>


<!-- Date: Thu Mar 29 13:01:08 2001 -->
I take TF 4 for a while, to try out Un-Ki's new TF FRAM 
writing function, and to try to integrate it with cold 
start code. 
<p>  
<!-- Author: Bill -->
<!-- Comment: Thu Mar 29 17;15;00 comment by...Bill -->
Done
<!-- Date: Thu Mar 29 13:06:31 2001 -->
Bill Badgett has added a couple of spare Mergers and a couple 
of spare Track Fitters to the hardware database, so that when  
we install spare cards for various tests, we can configure them 
with R_C.  The DB has them in slots 22-25 of crate 6, right next to 
the spare Hit Finder (which the DB has in slot 21). 
<p>  
<!-- Author: Bill -->


<!-- Date: Thu Mar 29 15:34:10 2001 -->
Un-Ki's TF FRAM rewrite code is working well, and has been 
integrated with the cold start code.  I am trying it out 
from the PCs, successfully so far.  I may be running the 
coldstart to several of the TFs for a little while, unless 
someone complains (x5017). 
<p>  
<!-- Author: Bill -->
<!-- Comment: Thu Mar 29 17;15;15 comment by...Bill -->
Done


<!-- Date: Thu Mar 29 17:18:17 2001 -->
Hearing much encouragement and no objections (per discussion at Tuesday's SVT meeting and the e-mail that followed), we decided to 
proceed conservatively toward moving the Track Fitters to 
the wedge crates.  Step one, which we just completed, is 
to move TFs 10 and 11 to crate 5.  These were the closest 
to the final Mergers, so the cable length difference is 
negligible.  We will see how things work out, for a few days, 
with one crate set up in this way before moving more boards. 
<p>  
<!-- Author: Bill & Stefano -->


<!-- Date: Thu Mar 29 17:21:58 2001 -->
I take crate 5, for the rest of today, to see how the software 
feels about having TF together with other boards.  
<!-- Author: Bill -->
<!-- Comment: Fri Mar 30 14;21;38 comment by...Bill -->
I continue today to use crate 5, if nobody objects.



<!-- Comment: Fri Mar 30 23;06;27 comment by...Bill -->
Done.
<!-- Date: Fri Mar 30 23:05:50 2001 -->
I have ported the "random test," which picks a random pattern, 
throws hits in the road, then runs them from HF OSPY all the 
way to TF, and runs the simulation in parallel, to C, then to 
VxWorks, so that it can run on the crate CPU.  I also ported 
the offline (TRGsim++) AMS, HB, and TF simulators (which just 
consisted of compiling them).  On the crate CPU, it flies like 
**** off a shovel, but it leaks memory like a sieve. 
<p> 
This test is a nice way to exercise the cold start code (which 
is executed at the start of the test) and the simulation code, 
e.g. to plug memory leaks. 
<p>  
<!-- Author: Bill -->



<!-- Date: Sat Mar 31 20:10:04 2001 -->
<pre>Bill discovered that Track Fitter (TF) sometimes goes to  
a weired state under HOLD state (e.q. very fast data flow). 
 
Indeed, under this weired HOLD state, the TF keeps sending data. 
This would be a serious problem in the case of high luminosity  
beam collision. Thanks to Bill. 
 
This feature was finally traced down to an asynchronization 
problem of HOLD signal. Now, this problem is fixed.  
All of the Track Fitters in B0 are downloaded with this fixed 
firmware. 
 
PS. I noticed that TF's power LED light was off when I tried 
    to download the firmware. I don't know when this was     
   happened. (Power LED usually fails when ALTERA configuration 
  does after crate power up). Thus, I pulled out the TF and put 
it back couple of times, and power LED never changed. 
Neverthells, I decided to download it. And it fail in downloading 
 (especially, in the verification process).  
After two times failure in downloading, finally, I got success. 
And power LED came up after I reset crate power.</pre>
<!-- Author: Un-ki -->


<!-- Date: Sun Apr 1 17:41:57 2001 -->
I take crate 5 again, for the rest of today.  Call x5017 if 
you'd like to take it back.  
<!-- Author: Bill -->
<!-- Comment: Mon Apr  2 02;46;55 comment by...Bill -->
Done


<!-- Date: Mon Apr 2 02:48:52 2001 -->
svtsim code used on crate CPU for both simulation and  
management of "maps" no longer leaks memory, and is able 
to free memory (if desired) at end of cold start (though 
this slows down the next cold start slightly, if from the 
same maps).  svtvme library itself still seems to leak 
memory, but now we have a tool to track this down.  anyway, 
the leak rate is much, much lower than friday.  
<!-- Author: Bill -->


<!-- Date: Mon Apr 2 13:39:47 2001 -->
<pre>I will play with b0svt00 for the rest of the day. 
send a message to yliu@fnal.gov to stop me if you want.</pre>
<!-- Author: Yanwen -->


<!-- Date: Mon Apr 2 15:14:58 2001 -->
We moved TFs for wedges 4,5,6,7,8,9 from the "fitter" crate to their respective "tracking" crates.  (TFs 10,11 had been moved 
last Friday.)  After some effort to seat properly the TFs for 
wedges 5 and 9, Bill's Python end-event-word-data-flow test 
program succeeds in flowing data through all 12 wedges.  Cables 
look quite a bit nicer now in crate 6.  
<!-- Author: Bill & Stefano -->


<!-- Date: Mon Apr 2 21:56:03 2001 -->
I'm testing various fer and svtvme code on crate 5; 
disregard after 1am.  x5017  
<!-- Author: Bill -->


<!-- Date: Mon Apr 2 22:22:01 2001 -->
Play with TF at slot 4 for a better flash memory writing 
for next one hour
<!-- Author: Un-ki -->

<!-- Date: Mon Apr 2 22:50:23 2001 -->
There is a new "current" version for svtvme.<br>
You get it via "setup svtvme" while "setup svtvme -d" will get the
development version. The current is supposed to be stable, development
may not work at a given time.<br>
SVT cpu's are booting from svtvme current now.<br>
Code developers are encouraged to use -d and report problems,
going back to current when things just do not work.
<!-- Author: Stefano -->



<!-- Date: Tue Apr 3 08:17:44 2001 -->
<pre>using b0svt05</pre>
<!-- Author: marco x3502 -->